Modify the `programmer_delay` function signature to allow passing
the flashrom context. Programmers that depend on internal delay
should provide NULL as a context. The use of this function parameter
will be introduced in CB:67393.
TOPIC=programmer_handle_global
TEST=builds
Change-Id: Ibb0bce26ce2052853ee52158d7ba742967a9e229
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66373
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Dummy doesn't need a custom mapper on opaque_master; the returned
address is not used and the mapper has no side effects.
This is the only remaining opaque master with a custom mapper, so this
permits removing custom mapper support from opaque masters.
Change-Id: I76ae3e0c2e91ecba4fd320941bd1eff038050731
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68091
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Move (un)map_flash_region function pointers from programmer_entry to
par_master, spi_master, and opaque_master. This enables programmers to
specify a different mapper per bus, which is needed for the internal
programmer. Mapping is closely tied to the way the memory is accessed
using the other functions in the bus master structs.
Validate that FWH/LPC programmers provide specialized mapping in
register_par_master(); this is needed for chips with
FEATURE_REGISTERMAP, which only exist on FWH or LPC buses.
programmer.c: Update comment in fallback_map(), NULL return is the
desired behavior.
Test: Read firmware on SB600 Promontory mainboard (requires physmap)
Test: Read firmware externally with ft2232_spi
Test: Read firmware on ICH hwseq, verify physmap still occurs
Change-Id: I9c3df6ae260bcdb246dfb0cd8e043919609b014b
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Co-Authored-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67695
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop the explicit need to specify the default 'internal_delay'
callback function pointer in the programmer_entry struct.
This is a reasonable default for every other driver in the
tree with only the two exceptions of ch341a_spi.c and serprog.c.
Thus this simplifies driver development.
Change-Id: I17460bc2c0aebcbb48c8dfa052b260991525cc49
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67391
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the bool type instead of an integer for appropriate variables and
attributes, since this represents their purpose much better.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: I712b1ef7e1ad74d3e004dcf36c82898c88072c63
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66901
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Ran;
```
$ find -name '*.c' -exec sed -i 's/extract_programmer_param_str(NULL/extract_programmer_param_str(cfg/g' '{}' \;
```
Manually fix i2c_helper_linux.c and other cases after.
Treat cases of;
- pcidev.c , and
- usb_device.c
as exceptional to be dealt with in later patches.
Change-Id: If7b7987e803d35582dda219652a6fc3ed5729b47
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66656
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Modify the type signature of the programmer get_param
helper functions to allow for the consumption of the
programmer parameterisation string data.
Change-Id: Ic5b35a7324b1c5a8ca9b8b16ee0b95036737ef47
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66663
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Results can be reproduced with the following invocation;
```
$ find -name '*.c' -exec sed -i 's/extract_programmer_param_str(/extract_programmer_param_str(NULL, /g' '{}' \;
```
This allows for a pointer to the actual programmer parameters
to be passed instead of a global.
Change-Id: I781a328fa280e0a9601050dd99a75af72c39c899
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66654
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Add a field, probe_opcode, to struct spi_master which points to a
function returning a bool by checking if a given command is supported by
the programmer in use. This is used for getting a whitelist of commands
supported by the programmer, as some programmers like ichspi don't
support all opcodes.
Most programmers use the default function, which just returns true.
ICHSPI and dummyflasher use their specialized function.
Change-Id: I6852ef92788221f471a859c879f8aff42558d36d
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65183
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that the VARIABLE_SIZE emulation doesn't use SPI paths anymore,
we can drop these initializations.
Change-Id: I43b3667303498b6cc40310c6123bd5c39024645a
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65458
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch changes the function name of extract_programmer_param() to
extract_programmer_param_str() as this function name will clearly
specify that it returns the value of the given parameter as a string.
Signed-off-by: Chinmay Lonkar <chinmay20220@gmail.com>
Change-Id: Id7b9fff4d3e1de22abd31b8123a1d237cd0f5c97
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65521
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Use `<tab>.key<tab>*= <value>,`
TEST: `make VERSION=0 MAN_DATE=0` returns the same flashrom binary
before and after the patch
Change-Id: I1c45ea9804ca09e040d7ac98255042f58b01f8ef
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65363
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
0 is an invalid value for freq parameter and caused floating point
exception. This patch checks that freq is not 0 during
initialisation.
Fixes: https://ticket.coreboot.org/issues/366
TEST=the following scenarios
1) error
$ ./flashrom -p dummy:emulate=W25Q128FV,freq=0 -V
<...>
init_data: invalid value 0 for freq parameter
Unhandled programmer parameters (possibly due to another failure): emulate=W25Q128FV,
Error: Programmer initialization failed.
2) successful
$ ./flashrom -p dummy:emulate=W25Q128FV,freq=10 -V
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI).
3) default is also successful
$ ./flashrom -p dummy:emulate=W25Q128FV -V
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI).
Change-Id: I0a95495de0a677f0d4d7f4c2fc61dcbc00d6ad4c
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65240
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Spansion flash chips S25FL128L and S25FL256L use the WRSR instruction to
write more than 2 registers. So align SR2 and SR3 support: The current
FEATURE_WRSR_EXT is renamed to FEATURE_WRSR_EXT2 and FEATURE_WRSR_EXT3
is added. Also, WRSR3 needs a separate flag now.
Verified that FEATURE_WRSR_EXT2 still works using the `dummy_flasher`.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: Ibdfc6eb3d2cfecbf8da0493d067031ddb079a094
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64746
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Thomas Heijligen <src@posteo.de>
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>
Start taking bits related to write protection into account.
Also add "hwwp" parameter for dummy programmer that sets state of WP
pin (not inverted value).
TEST=use command-line interface to run WP-related commands
dummyflasher doesn't store state of the chip between runs and flashrom
allows running only one command, so testing WP in this way is limited.
However, WP options can be combined with other operations and are
executed prior to them, so certain scenarios can be checked.
List possible ranges:
flashrom -p dummy:emulate=W25Q128FV,hwwp=yes --wp-list
Set a particular range and check status is correct:
flashrom -p dummy:emulate=W25Q128FV,hwwp=yes \
--wp-enable \
--wp-range=0x00100000,0x00f00000 \
--wp-status
Enable write protection and try erasing/writing (erasing here):
# this fails
flashrom -p dummy:emulate=W25Q128FV,hwwp=yes \
--wp-range=0,0x00c00000 \
--wp-enable \
--erase
Write protecting empty range has no effect:
# this succeeds
flashrom -p dummy:emulate=W25Q128FV,hwwp=yes \
--wp-range=0,0 \
--wp-enable \
--erase
Disabling WP is possible if hwwp is off:
# this fails
flashrom -p dummy:emulate=W25Q128FV,spi_status=0x80,hwwp=yes \
--wp-disable
# this succeeds
flashrom -p dummy:emulate=W25Q128FV,spi_status=0x80,hwwp=no \
--wp-disable
Change-Id: I9fd1417f941186391bd213bd355530143c8f04a0
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Enable emulation of SR2 and SR3 for W25Q128FV and provide logic for
updating them (masks of read-only bits that can't be set from outside).
TEST=check how input value affects status registers of emulated chip
flashrom -V -p dummy:emulate=W25Q128FV,spi_status=0x12 |
grep -A3 'Initial status registers'
flashrom -V -p dummy:emulate=W25Q128FV,spi_status=0x1234 |
grep -A3 'Initial status registers'
flashrom -V -p dummy:emulate=W25Q128FV,spi_status=0x123456 |
grep -A3 'Initial status registers'
Change-Id: I79f9b4a0b604663d3288ad70dcbe3ea4075dede5
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59073
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Prepare everything for emulating SR2 and SR3 for chips that have it.
This is needed for accessing SRP1 and WPS bits which are involved in
write protection. The emulated register doesn't affect anything yet
and will be tested by write-protection tests.
TEST=check how input value affects status registers of emulated chip
flashrom -V -p dummy:emulate=W25Q128FV,spi_status=0x12 |
grep 'Initial status register'
flashrom -V -p dummy:emulate=W25Q128FV,spi_status=0x1234 |
grep 'Initial status register'
flashrom -V -p dummy:emulate=W25Q128FV,spi_status=0x123456 |
grep 'Initial status register'
Mind that at this point there are no chips that emulate more than one
status register.
Change-Id: I177ae3f068f03380f5b3941d9996a07205672e59
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59072
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
This patch prepares spi masters to use new API which allows to
register shutdown function in spi_master struct. See also later
patch in this chain, where spi masters are converted to new API.
BUG=b:185191942
TEST=builds and ninja test
Comparing flashrom binary before and after the patch,
make clean && make CONFIG_EVERYTHING=yes VERSION=none
binary is the same
Change-Id: I50716686552b4ddcc6089d5afadb19ef59d9f9b4
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56101
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Using the pointer's type instead ensures that we get the right size even
if code changes in the future.
Change-Id: If88ba394095f86c598dcc5cf1751e1c23b132d04
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/55358
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The `EMULATE_CHIP` and `EMULATE_SPI_CHIP` macros are unconditionally
defined as `1`, with no way to change their values. Since this means
that the code never gets build-tested using other values, drop these
noisy macros.
TEST=Build with `make distclean && make VERSION=none -j` with and
without this patch, the flashrom executable does not change.
Change-Id: If46e1c37c3b04b28b4ba1f82c9b3def1e549368f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/55265
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>
Reviewed-by: Namyoon Woo <namyoon@google.com>
This patch extracts params processing into a separate function. Now
all error paths of params processing return 1 back to init function
which frees data.
And there was just one more error path in init function where
free(data) needed to be added.
This is a follow up on commit 3b8fe0f8e907c0ba9f7c7935e950f3e1538d427f
which moves global state into spi_master data.
A good side-effect of the change is: init function becomes easier
to read.
BUG=b:185191942
TEST=ninja test
Change-Id: I04f55f77bb4703f1d88b2191c45a22be3c97bf87
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54748
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The memory for the `status` string is aliased by the `endptr` pointer.
Moreover, `errno` could have been modified by the call to `free()`.
Therefore, only free the former when there are no more uses of either.
Change-Id: I1b56834004fe18918213a7df0a09a8a7ecb56985
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54909
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Place `flashchip_contents` allocation next to the code that initialises
the newly-allocated buffer. This also avoids leaking it if the handling
of `spi_status` fails.
Change-Id: Ie907ac88dfe4ca018c97d9ce6ce042b4ffacf36a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54908
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Relying on the global state 'dummy_buses_supported' to
determine the member master struct [mst.par or mst.spi]
is both buggy and ultimately unnecessary. It became
apparent after commit 4eef651ff503f81b77 just how fragile
this really was as the 'defaults' simultaneously selected
both buses causing get_data_from_context() to fall-though
however memory happened to workout by chance due to the
union. With the member master structs now being struct
fields the subtle bug is more apparent.
BUG=none
BRANCH=none
TEST=`./flashrom -r /tmp/fwupdater.apnSQQ -p dummy:emulate=VARIABLE_SIZE,image=test_update.sh.tmp.emu,size=8388608`
Change-Id: I07a34faf50ff0679cb3d6bc683142f82160010b1
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54907
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The spi callbacks do not need par logic to fetch the
data field. Instead of going though get_data_from_context()
just fetch 'data' directly out of mst.spi.
This leads us towards a path of removing dummy_buses_supported
from global state.
BUG=none
BRANCH=none
TEST=`./flashrom -r /tmp/fwupdater.apnSQQ -p dummy:emulate=VARIABLE_SIZE,image=test_update.sh.tmp.emu,size=8388608`
Change-Id: I63b8d8861df75f52f241f09614146990fdfe59ed
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54906
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Move 'spi_write_256_chunksize' out of global scope and
into the emu_data reentrent struct.
BUG=none
BRANCH=none
TEST=builds
Change-Id: I633f4df4bd47e661cd69801f21910b667899d505
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54721
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Pass pointers to dynamically allocated data to register_par_master().
This way we can avoid a mutable global.
BUG=b:185191942
TEST=builds
Change-Id: I76572e43d01f8a5e1aa73b1b9e8a187465ed8fef
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54172
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
It was impossible to register a const struct par_master that would
point to dynamically allocated `data`. Fix that so that we won't
have to create more mutable globals.
BUG=b:185191942
TEST=builds
Change-Id: I95bc92f6c54c5bcdac1c522ca87054aaffed0f40
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54169
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
The BUS_NONSPI is short-hand and is intended to be
the collection, therefore use it.
BUG=none
BRANCH=none
TEST=builds
Change-Id: I368e8865c446d9b9ffd580c90eac034850dd53d8
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54356
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Sam McNally <sammc@google.com>
Pass pointers to dynamically allocated data to register_spi_master().
This way we can avoid some mutable globals.
Change-Id: Id7821f1db3284b7b5b3d0abfd878b979c53870a1
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
It was impossible to register a const struct spi_master that would
point to dynamically allocated `data`. Fix that so that we won't
have to create more mutable globals.
Change-Id: I0c753b3db050fb87d4bbe2301a7ead854f28456f
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54066
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
emu_data *data is allocated in init function and needs
to be freed in shutdown function.
BUG=b:181803212
TEST=builds and ninja test
Change-Id: I36f76d84d3547d081c64857e06da23ee63cc5594
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/52557
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This upstreams a ChromiumOS feature that allows the user
of the dummyflasher spi master to either fill with 0x00
or 0xff in the fake flash content by way of a spi master
param.
BUG=b:140394053
BRANCH=none
TEST=none
Change-Id: I37c6dee932e449201d8bbfb03ca6d139da3cb6a2
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/47859
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
This patch fixes a few bugs that two patches ( `3149822cd45cb2e5841e15d648783748ba1b2ec6` && `3b8fe0f8e907c0ba9f7c7935e950f3e1538d427f`) brought:
* Check the presence of 'size' param only if the emulate is VARIABLE_SIZE.
* Initialize 'flash->st->par.data' in dummy_init() so that it can probe the VARIABLE_SIZE emulator correct in probe_variable_size().
* Replace atoi() with strtol().
* Revise man page to describe how to use the VARIABLE_SIZE emulation target.
TEST:
$ flashrom -p dummy:image=dummy.bin,emulate=VARIABLE_SIZE,size=16777216 \
-w ${IMG} -V -f
...
Verifying flash... VERIFIED.
Writing dummy.bin
$ flashrom -p dummy:image=dummy.bin,emulate=VARIABLE_SIZE -w ${IMG} -V -f
...
dummy_init: the size parameter is not given.
Unhandled programmer parameters (possibly due to another failure): image=dummy.bin,
Error: Programmer initialization failed
$ flashrom -p dummy:image=dummy.bin,emulate=SST25VF040.REMS -c SST25LF040A -w ${IMG}
...
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.
$ man flashrom
...
* Dummy vendor VARIABLE_SIZE SPI flash chip (configurable size, page write)
Example: flashrom -p dummy:emulate=SST25VF040.REMS
To use VARIABLE_SIZE chip, size must be specified to configure the size of the flash chip as a power of two.
Example: flashrom -p dummy:emulate=VARIABLE_SIZE,size=16777216,image=dummy.bin
...
Signed-off-by: Namyoon Woo <namyoon@google.com>
Change-Id: Ie6481943a831b946a91b643b4d79e684c27e48b8
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46536
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This line gets printed even when not using dummyflasher at all. Drop it.
TEST=Check that no spurious error message appears with ft2232_spi.
Change-Id: I1a81a735db391357d1b6ee6f3e9844255efd0e19
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46524
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This allows the dummyflasher to emulate a bus/chip frequency
by passing a delay parameter.
BUG=b:140394053
BRANCH=none
TEST=builds and ran with freq passed,
```
└──╼ dd if=/dev/urandom of=/tmp/bar bs=2K count=1
1+0 records in
1+0 records out
2048 bytes (2.0 kB, 2.0 KiB) copied, 0.000583308 s, 3.5 MB/s
└──╼ ./flashrom -p dummy:image=/tmp/foo,bus=spi,freq=100Hz,size=2048,emulate=VARIABLE_SIZE -w /tmp/bar
flashrom v1.2-105-g702c58a-dirty on Linux 5.7.10-1rodete2-amd64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Generic flash chip "Variable Size SPI chip" (2 kB, SPI) on dummy.
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.
```
Change-Id: I1c2702b9e0cae860f5f03114e307707d4d3219af
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/45461
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
