aboutsummaryrefslogtreecommitdiffstats
path: root/include/chipdrivers.h
Commit message (Collapse)AuthorAgeFilesLines
* spi25.c: Add function to return opcode of passed erase fucntion pointerAarya Chaumal2022-06-271-0/+1
| | | | | | | | | | | | | There is a function, spi_get_erasefn_from_opcode, which returns the erase function for given opcode. Add a function which does the opposite i.e. returns the opcode for given erase function. Change-Id: Ia3aefc9b9465efdd16b1678bb2ada9a23f00d316 Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/65355 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Thomas Heijligen <src@posteo.de>
* flashchips: Add Spansion (today Infineon) S25FL128L and S25FL256LNico Huber2022-06-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | These chips seem to be rather regular, supporting 2.7V..3.6V, the common erase block sizes 4KiB, 32KiB, 64KiB and the usual block- protection bits. Status/configuration register naming differs from other vendors, though. These chips have 2 status registers plus 3 configuration registers. Configuration registers 1 & 2 match status registers 2 & 3 of what we are used from other vendors. Read opcodes match too, however writes are always done through the WRSR instruction which can write up to 4 bytes (SR1, CR1, CR2, CR3). S25FL256L supports native 4BA commands and entering a 4BA mode. However, it uses an unusual opcode (0x53) for the 32KiB 4BA block erase. Signed-off-by: Nico Huber <nico.h@gmx.de> Change-Id: I356df6649f29e50879a4da4183f1164a81cb0a09 Reviewed-on: https://review.coreboot.org/c/flashrom/+/64747 Reviewed-by: Thomas Heijligen <src@posteo.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* dummyflasher: Wire variable size feature via opaque infraAnastasia Klimchuk2022-06-161-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Wire "variable size" feature in dummy programmer via opaque infra. This patch fixes the broken build with CONFIG_DUMMY=no. Dummyflasher registers opaque master for the case when it is initialised with EMULATE_VARIABLE_SIZE. Dummy opaque master emulates read/write/erase as simple memory operations over `data->flashchip_contents`. The feature works via "Opaque flash chip" in flashchips.c which has one block eraser at the moment. If this changes in future, each block eraser needs to be updated in `probe_variable_size`. Fixes: https://ticket.coreboot.org/issues/365 TEST=the following scenarious run successfully Testing build $ make clean && make CONFIG_DUMMY=no $ flashrom -h : dummy is not in the list $ make clean && make CONFIG_EVERYTHING=yes $ flashrom -h : dummy is in the list Testing "variable size" feature $ flashrom -p dummy:size=8388608,emulate=VARIABLE_SIZE -V $ flashrom -p dummy:size=8388608,emulate=VARIABLE_SIZE -r /tmp/dump.bin -V $ head -c 8388608 </dev/urandom >/tmp/image.bin $ flashrom -p dummy:image=/tmp/image.bin,size=8388608,emulate=VARIABLE_SIZE -w /tmp/dump.bin -V also same as above with erase_to_zero=yes Testing standard flow $ flashrom -p dummy:emulate=W25Q128FV -V $ flashrom -p dummy:emulate=W25Q128FV -r /tmp/dump.bin -V $ head -c 16777216 </dev/urandom >/tmp/image.bin $ flashrom -p dummy:image=/tmp/image.bin,emulate=W25Q128FV -w /tmp/dump.bin -V Testing invalid combination of programmer params (`init_data` fails and prints error message which is WAI) $ flashrom -p dummy:size=8388608 -V -> init_data: size parameter is only valid for VARIABLE_SIZE chip. $ flashrom -p dummy:emulate=VARIABLE_SIZE -V -> init_data: the size parameter is not given. $ flashrom -p dummy:emulate=W25Q128FV,erase_to_zero=yes -V -> init_data: erase_to_zero parameter is not valid for real chip. Change-Id: I76402bfdf8b1a75489e4509fec92c9a777d0cf58 Signed-off-by: Anastasia Klimchuk <aklm@chromium.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/64488 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
* Introduce an `include` directory for header filesThomas Heijligen2022-04-291-0/+220
Move all header files to the new `include` directory. Adapt include directives and build systems to the new directory. Change-Id: Iaddd6bbfa0624b166d422f665877f096983bf4cf Signed-off-by: Felix Singer <felix.singer@secunet.com> Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/58622 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>