As a consecuence, some of the files that used to include flash.h no
longer need to do so. For this reason, flash.h includes are also deleted
in this commit.
Change-Id: I794a71536a3b85fde39f83c802fa0f5dd8d428e0
Signed-off-by: Antonio Vázquez Blanco <antoniovazquezblanco@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/85539
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: David Reguera Garcia (Dreg) <regueragarciadavid@gmail.com>
Reviewed-by: Matti Finder <matti.finder@gmail.com>
This is a simple refactor that aims to simplify maintenance and to
clarify file dependency inside the project.
Currently, most of the declarations reside in programmer.h making it
difficult to really understand file dependency.
Change-Id: I9d819ea1c5bd51289d02189c1dff367ce6d25617
Signed-off-by: Antonio Vázquez Blanco <antoniovazquezblanco@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84982
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Miklós Márton <martonmiklosqdev@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Original progress reporting implemented in CB:49643 and it has some
issues, for example:
size_t start_address = start;
size_t end_address = len - start;
End address is anything but length minus start address.
update_progress(flash,
FLASHROM_PROGRESS_READ,
/*current*/ start - start_address + to_read,
/*total*/ end_address);
Total should just be length if that's how current value is computed.
---
libflashrom needs to know total size ahead of time.
That's init_progress() and changed update_progress().
It also needs to store the last current value to be able to update it.
That's stage_progress in flashrom_flashctx.
Measuring accurately amount of data which will be read/erased/written
isn't easy because things can be skipped as optimizations. The next
patch in the chain aims to address this, there are TODO/FIXME
comments there.
---
CLI shares terminal with the rest of the code and has to maintain more
state to handle that reasonably well.
Similar to CB:64668, an effort is made to keep the progress on a
single line. Non-progress output is kept track of to know when
moving to a new line cannot be avoided.
---
A script to test the CLI:
\#!/bin/bash
t=${1:-rewW}
shift
if [[ $t =~ r ]]; then
echo ">>> READ"
./flashrom -p dummy:emulate=W25Q128FV,freq=64mhz -r dump.rom --progress "$@"
echo
fi
if [[ $t =~ e ]]; then
echo ">>> ERASE"
./flashrom -p dummy:emulate=W25Q128FV,freq=64mhz -E --progress "$@"
echo
fi
if [[ $t =~ w ]]; then
echo ">>> WRITE (without erase)"
dd if=/dev/zero of=zero.rom bs=1M count=16 2> /dev/null
./flashrom -p dummy:emulate=W25Q128FV,freq=64mhz -w zero.rom --progress "$@"
echo
fi
if [[ $t =~ W ]]; then
echo ">>> WRITE (with erase)"
dd if=/dev/zero of=zero.rom bs=1M count=16 2> /dev/null
dd if=/dev/random of=random.rom bs=1M count=16 2> /dev/null
./flashrom -p dummy:emulate=W25Q128FV,freq=64mhz,image=random.rom -w zero.rom --progress "$@"
echo
fi
Co-developed-by: Anastasia Klimchuk <aklm@flashrom.org>
Co-developed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Change-Id: If1e40fc97f443c4f0c0501cef11cff1f3f84c051
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84102
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
A NULL func pointer is necessary and sufficient for the
condition `NULL func pointer => true' as to not need this
boilerplate as it implies default behaviour of a supported
opcode within the `check_block_eraser()` match supported loop.
Ran;
```
$ find . -name '*.[c,h]' -exec sed -i '/.probe_opcode = default_spi_probe_opcode,/d' '{}' \;
```
Change-Id: Id502c5d2596ad1db52faf05723083620e4c52c12
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70264
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
A NULL func pointer is necessary and sufficient for the
condition `NULL func pointer => default_spi_send_multicommand' as to not
need this explicit specification of 'default'.
Therefore drop the explicit need to specify the
'default_spi_send_multicommand' callback function pointer in the
spi_master struct. This is a reasonable default for every other driver
in the tree with only a few exceptions.
This simplifies the code and driver development.
Change-Id: I6cc24bf982da3d5251d391eb397db43dd10280e8
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67481
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
The non-custom driver programmer delay implementation
'internal_delay()' is unrelated specifically to the
'internal' programmer. The delay implementation is
simply a platform-agnostic host delay implementation.
Therefore, rename to simply default_delay().
Change-Id: I5e04adf16812ceb1480992c92bca25ed80f8897a
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68855
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Replace `programmer_delay(NULL, [..])` calls with direct
`internal_delay([..])` dispatches explicitly. Custom driver
delays remain hooked as well as core flashrom logic. The
NULL base case of 'programmer_delay()' then becomes a condition
to validate for layering violations or invalid flash contexts.
Change-Id: I1da230804d5e8f47a6e281feb66f381514dc6861
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68434
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
Drop the explicit need to specify the default 'fallback_{un}map'
callback function pointer from the 'programmer_entry' struct.
This is a reasonable default for every other driver in the tree
with only a select few exceptions [atavia, serprog, dummyflasher
and internal].
Thus this simplifies driver development and paves way
to remove the 'programmer' global handle.
Change-Id: I5ea7bd68f7ae2cd4af9902ef07255ab6ce0bfdb3
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67404
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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>
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>
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>
The dediprog, developerbox_spi and stlinkv3_spi programmers only check
if the libusb_context is not NULL after the initialization. But
following the API documentation from libusb, the context is undefined
unless the init function returns 0. Fix this by checking the return
value instead of the libusb_context to see if the initialization was
successful.
https://libusb.sourceforge.io/api-1.0/group__libusb__lib.html
Change-Id: Ia45ccd3fa2239dfccd821be46a09c86426cb22e5
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66460
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, each programmer parameter has their own temp variable to
store their raw value into it. That's not needed since these variables
are only used for a short time to do some configuration and stay unused
then. Thus, use only one variable for all of them.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: I198c0da88bfc01fe15280cbd58d2ef27564c1dbc
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65886
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
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>
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>
There are two competing sets of instructions to access the extended
address register of 4BA SPI chips. Some chips even support both sets.
So far, we assumed the 0xc5/0xc8 instructions by default and allowed
to override the write instructions with the `.wrea_override` field.
This has some disadvantages:
* The additional field is easily overlooked. So when adding a new
flash chip, one might assume only 0xc5/0xc8 are supported.
* We cannot describe flash chips completely that allow both
instructions (and some programmers may be picky about which
instructions can be used).
Therefore, replace the `.wrea_override` field with a feature flag.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: I6d82f24898acd0789203516a7456fd785907bc10
Ticket: https://ticket.coreboot.org/issues/357
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64636
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
There are two competing sets of instructions to access the extended
address register of 4BA SPI chips. Some chips even support both sets.
To prepare for other instructions than the default 0xc5/0xc8, rename
the original feature flag.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: Iacb7b68a9e3444fe28873ff0fe5e3fab16643c8c
Ticket: https://ticket.coreboot.org/issues/357
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64635
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Projects using libflashrom like fwupd expect the user to wait for the
operation to complete. To avoid the user thinking the process has
"hung" or "got stuck" report back the progress complete of the erase,
write and read operations.
Add a new --progress flag to the CLI to report progress of operations.
Include a test for the dummy spi25 device.
TEST=./test_build.sh; ./flashrom -p lspcon_i2c_spi:bus=7 -r /dev/null --progress
Change-Id: I7197572bb7f19e3bdb2bde855d70a0f50fd3854c
Signed-off-by: Richard Hughes <richard@hughsie.com>
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
dediprog_bulk_read_poll()'s finish argument allows it to be used in two
distinct cases: where dediprog_bulk_read_poll will be called as part of
a loop (finish=0) and where dediprog_bulk_read_poll should wait for all
outstanding transfers to finish (finish=1). In both cases,
dediprog_bulk_read_poll() calls libusb to process events with a 10
second timeout.
After dediprog_spi_bulk_read() has queued the last transfers, it calls
dediprog_bulk_read_poll() with finish=0 when it should be finish=1.
finish=0 just happens to work because frequently the transfers finish in
the 10 second timeout.
Signed-off-by: Rick Altherr <rick@oxidecomputer.com>
Change-Id: If7cb541742c8620358c8e04275d8316131b2d1ab
Reviewed-on: https://review.coreboot.org/c/flashrom/+/60087
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
register_spi_master now becomes the last operation in init function,
which is consistent with other spi masters.
In addition, the patch fixes propagation of register_spi_master return
values, which is also consistent with other spi masters.
TEST=ninja test
Change-Id: Ib7e0179da39279e32a8497466b044b69ec836da8
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/51706
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The name of the struct type already contains dp_ prefix, so
prefix doesn't need to be repeated in members name.
BUG=b:185191942
TEST=builds and ninja test
Change-Id: I688d50926b78a6c3f1c5a8ba4ef88a0d5b495bd0
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56415
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Move global singleton states into a struct and store within
the spi_master data field for the life-time of the driver.
This is one of the steps on the way to move spi_master data
memory management behind the initialisation API, for more
context see other patches under the same topic "register_master_api".
BUG=b:185191942
TEST=builds and ninja test
Change-Id: I72085e750af97b94dfa94f2ebf2a134e41a2ec8d
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56414
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This allows spi masters to register shutdown function in spi_master
struct, which means there is no need to call register_shutdown in init
function, since this call is now a part of register_spi_master.
As a consequence of using new API, two things are happening here:
1) No resource leakage anymore in case register_shutdown() would fail,
2) Fixed propagation of register_spi_master() return values.
Basic testing: when I comment out free(data) in linux_spi_shutdown, test
fails with error
../linux_spi.c:235: note: block 0x55a4db276510 allocated here
ERROR: linux_spi_init_and_shutdown_test_success leaked 1 block(s)
Means, shutdown function is invoked.
BUG=b:185191942
TEST= 1) builds and ninja test including CB:56911
2) On ARMv7 device
flashrom -p linux_spi -V
-> using linux_spi, chip found
3) On x86_64 AMD device
flashrom -p internal -V
-> this is actually using sb600spi, chip found
Change-Id: Ib60300f9ddb295a255d5ef3f8da0e07064207140
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56103
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
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>
Shutdown function was covering two different jobs here: 1) the actual
shutdown which is run at the end of the driver's lifecycle and
2) cleanup in cases when initialisation failed. Now, shutdown is only
doing its main job (#1), and the driver itself is doing cleanup
when init fails (#2).
The good thing is that now resources are released/closed immediately
in cases when init fails (vs shutdown function which was run at some
point later), and the driver leaves clean space after itself if init
fails.
And very importantly this unlocks API change which plans to move
register_shutdown inside register master API, see
https://review.coreboot.org/c/flashrom/+/51761
BUG=b:185191942
TEST=builds
Change-Id: I3273da907614a042d50090338c337dfd64695354
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/55887
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
The SPI_MASTER_NO_4BA_MODES is for SPI master not keeping the flash
powered between programming commands. Tests on the following devices
showed that the power is stable accross commands:
* SF100 protocol 2 V:6.5.03
* SF600 protocol 3 V:7.2.45
Change-Id: Iee0ba972245b9317ef86345432fec5fc32614888
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/44776
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
libusb_exit() call is done by dediprog_open() under the
ret == 1 condition. Removing this line has no impact on
any flow and side effect of the program.
Change-Id: I38b3f3ee3f9d46845df1404791f4a4782320aa7c
Signed-off-by: Medicine Yeh <medicinehy@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48688
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
default_spi_read() calls spi_read_chunked() with the correct
max_read value of 16 set in the spi master struct.
Change-Id: Ic0897f74056e3d723a33c063ed0bd8cb6e88ba45
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46232
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It's not used anywhere, but it should be correct if we continue to
keep it in.
Change-Id: I8a6941c2906dda2c5aac5e0af3364fd2ac5773f3
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/42763
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The ChromiumOS flashrom fork has since const'ify flashctx
in a few places. This aligns the function signatures to
match with downstream to ease forward porting patches
out of downstream back into mainline flashrom.
This patch is minimum viable alignment and so feedback is
welcome.
Change-Id: Iff6dbda13cb0d941481c0d204b9c30895630fbd1
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/40324
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When multiple dediprog programmers are connected, the 'id' parameter
allows you to specify which one to use. The id is a string like SF012345
or DP012345. The value is printed on a sticker on the back of the dediprog.
This is an improvement over the 'device' parameter which is based on
enumeration order and changes when you plug/unplug devices or reboot the
machine.
To find the id without the sticker, run flashrom with the -V option.
This prints the ids as they are enumerated. Alternatively, with dpcmd,
you can use the --list-device-id and --fix-device commands to list and
write device ids respectively.
Note this only supports SF100 at the moment, but SF600 support is
possible with more work.
Change-Id: I4281213ab02131feb5d47bf66118a001cec0d219
Signed-off-by: Ryan O'Leary <ryanoleary@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/34160
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The one in the `dummyflasher` is a little peculiar. We actually never
knew the type of the `st_size` field in `struct stat`. It happens to
be `signed` in some systems (e.g. DJGPP).
Change-Id: If36ba22606021400b385ea6083eacc7b360c20c5
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/35800
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Mostly by changing to `unsigned` types where applicable, sometimes
`signed` types, and casting as a last resort.
Change-Id: I08895543ffb7a48058bcf91ef6500ca113f2d305
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/30409
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
Not needed anymore. Drop it fast before it encourages anyone to
violate layers again!
Change-Id: I8eda93b429e3ebaef79e22aba76be62987e496f4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/33651
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
All these variables are only used in the files they are defined in, so
they can be made static.
Change-Id: I1e55138adef540e9d3a2237aa5b289cb338c0608
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/33747
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
With an SF100 and protocol version 1, using the extended address
register of the flash chip seems safe. Make use of that and remove
the broken 4BA modes flag.
Tested with SF100 V:5.1.9 and W25Q256FV.
Change-Id: If926cf3cbbebf88231116c4d65bafc19d23646f6
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/32016
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
The only combination we could successfully test so far is the SF600 with
protocol version V2 (firmware 7.2.21) and native 4BA commands. Let's
enable that at least.
Change-Id: I665d0806aec469a3509620a760815861fbe22841
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/28804
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
This is an interim solution. We'll have to enable 4BA step-by-step for
each dediprog protocol version.
Change-Id: I08efcbb09ab3499ef6902a698e9ce3d6232237c4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/30386
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
This never was a use case until now but the `--fmap` code makes it
obvious: Unaligned reads that were smaller than the `chunksize` here,
were extended without considering the length of the buffer read into.
With that fixed we run into the next problem: dediprog_spi_bulk_read()
shouldn't report an error when an empty read is unaligned.
Change-Id: Ie12b62499ebfdb467d5126c00d327c76077ddead
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/30051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
