flashrom_tester 'flashrom' crate was implemented using the flashrom
commandline. Add a second implementation using the libflashrom interface
via the libflashrom and libflashrom-sys rust bindings.
BUG=b:230545739
BRANCH=None
TEST=cargo test
TEST=on grunt (AMD)
TEST=/usr/bin/flashrom_tester --libflashrom host
TEST=/usr/bin/flashrom_tester --flashrom_binary /usr/sbin/flashrom host
Change-Id: Ic4db6c829d7e8dc707a10c10e1ca0d9b8abccdec
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65282
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This is analogous to spi.c and opaque.c however parallel
logic was previously never consoldiated.
This free's up flashrom.c from namespace pollution.
BUG=b:242246291
TEST=builds with both make and meson.
Change-Id: Ie08e2e6c51ccef5281386bf7e3df439b91573974
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66651
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Constructing a written file from a buffer is auxiliary
functionality to the core flashrom algorithms. Move
aside to decrease the overall complexity of flashrom.c
BUG=b:242246291
TEST=builds
Change-Id: Ib613e74597d4bdd689043ba93aeb6a87ec80cc14
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66646
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Evan Benn <evanbenn@google.com>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
The hwseq_data struct remains to be a stack allocated
instance for now however it is referenced in the opaque_master
data field of the flash ctx. This allows for worker functions
that leverage hwseq_data state to derive state indirectly via
the flash ctx instead of directly upon the global state.
This allows for unblocking further work to finally dispense
with the stack allocation in favour of a heap allocation with
a defined life-time of the driver.
BUG=b:237839418
TEST=builds
Change-Id: I2ad57d496176cf26edcd0ba40154cc6250846e33
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65205
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Provide the meson option `-Dich_descriptors_tool=auto/enable/disabled`
to determin if the ich_descriptors_tool should be build or not. On
`auto` or `enabled` it will be, on `disabled` it will not be build.
This is usefull for environments where the ich_descriptors_tool is not
needed.
Change-Id: Ief65a914019f72536d563eda36bd7f2f5330bea8
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66704
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
crossystem uses flashrom to gather data on some platforms. To avoid
firmware lock deadlock, call crossystem before initialising libflashrom.
When querying hardware write protect status, provide an argument to
crossystem so that only that field is queried. This also avoids the
deadlock, and improves performance.
BUG=b:239496316
BRANCH=None
TEST=on trogdor(arm), grunt(amd), hatch(intel):
TEST=flashrom_tester --libflashrom /usr/sbin/flashrom host Coreboot_ELOG_sanity
TEST=flashrom_tester /usr/sbin/flashrom host Coreboot_ELOG_sanity
Change-Id: I7d94cfc6ccbfbec91f12151eb0004724ccfc4e00
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65962
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Instead of using reversible write (rpci_write_word) that relies on
global state, do it manually. Save original PCI config space
register contents to programmer's structure during initialization
and restore it in programmer's shutdown.
TOPIC=reduce_global_pci_state
TEST=builds
Change-Id: Ie99a7cb3e049b29e6838dd4af587eee8c3b18919
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Ticket: https://ticket.coreboot.org/issues/389
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66838
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Add an explanation of the two rust libraries, and instructions for
building. Note that the bindings are not included in the tarball.
BUG=None
BRANCH=None
TEST=None
Change-Id: I05b1b5821554f8faee7728f899d51b6e8e9bf5be
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66618
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Write a newline after the hardware write protect prompt. Automated tests
read stdout and wait for this message, and split on newline, so write a
newline.
Also modify the function to not be recursive. Try to handle a closed
input correctly - panicing in that case. Behaviour is now to wait for
a newline instead of for 1 character.
BUG=b:240512896
BRANCH=None
TEST=tast run localhost:2222 firmware.FlashromTester
TEST=flashrom_tester < /dev/null
TEST=flashrom_tester; type some things, hold enter, then close stdin
Change-Id: I07ec242ca0d41787030d5d27fc88d78ed884d746
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/flashrom/+/3809595
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66587
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Depend exclusive on the cmocka package provided by the build
environment. Cmocka is widely available in Linux distributions and BSD
systems. Besides that, it is suboptimal to fetch own dependencies in the
build process. Most packaging systems even forbid fetching additional
assets at build time.
Change-Id: I751c85d5f72e47356113cf55dfbaec73cbd8028c
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66696
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
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: Ib4ebc0e6354aad007145e1b0a761d9011c59ff7c
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66571
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
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: I31e0baa2c5800c722a9ba853bcd40d71ed343f6d
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66568
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
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: I548bb2e0786be0af20114e6bf1450c5fedb83d23
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65910
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
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: I48502161add9b59d97f5eeb46f5984c075ad924a
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65909
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Peter Marheine <pmarheine@chromium.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: I247012523c5e864ddb9e1e635df51e4311e5d5c5
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65908
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
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>
Use the bool type instead of integer in the main function where
possible, since this represents the purpose of some variables much
better. Also, then we don't have to use the "!!" operator to turn any
number into one or zero, which is used as an equivalent to true and
false.
Also, since we have booleans and integers now, slightly change the
ordering of the variable declarations, so that the integers come before
the booleans.
Tested some parameters using the following commands:
flashrom -L
flashrom -p dummy
flashrom -p dummy:emulate=SST25VF040.REMS,image=foo2 -c "SST25LF040A" --progress -v foo1
flashrom -p dummy:emulate=SST25VF040.REMS,image=foo2 -c "SST25LF040A" --progress -w foo1
flashrom -p dummy:emulate=SST25VF040.REMS,image=foo2 -c "SST25LF040A" --progress -r foo1
flashrom -p dummy:emulate=SST25VF040.REMS,image=foo2 -c "SST25LF040A" --progress -E
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: I06572da040e12ac88f8e5fc39f60a9e212b86bd7
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64564
Reviewed-by: Evan Benn <evanbenn@google.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Add tests for i2c programmers that assert that initialisation fails
when allow_brick parameter is not provided.
Example of logs from test run:
[ RUN ] parade_lspcon_no_allow_brick_test_success
Testing init error path for programmer=parade_lspcon with params: bus=254 ...
... init failed with error code -1 as expected
[ OK ] parade_lspcon_no_allow_brick_test_success
BUG=b:181803212
TEST=ninja test
Change-Id: I382f563016502f3342131d5f9c0de41dc665b03a
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66508
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
While testing CB:63724, which reworks the Meson build system, it showed
that some programmers have dependency issues, which were invisible since
test_build.sh builds flashrom with all programmers enabled and thus all
sources are included. Building flashrom with each programmer
individually made these issues visible.
However, as commit 877b7741fc and commit b6a439e45e show, the Make
build system also had some similar issues, which were invisible for the
same reason.
Thus, in addition to building all programmers at once using the Make
build system, build each programmer individually.
Also, when clang analyzer is used, it's not needed to run it on each
programmer individually. Just return after flashrom was built with all
programmers enabled in this case.
An equivalent patch for the Meson build system is made separately.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: I3bacb3ba9c6708f1e7ef5a111290d0ea3af36f1d
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66094
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
