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>
This unit test does not require any additional mocks because init
and shutdown of i2c infra was covered in realtek programmer lifecycle.
Default mocking of i2c is sufficient to run a basic lifecycle.
To run the test, config option for the programmer needs to be
enabled explicitly, since by default this programmer is disabled.
BUG=b:238816884
TEST=meson configure -Dconfig_mediatek_i2c_spi=true
ninja test
Change-Id: I98a12067d165c90013d33ffc45d20dab5c364c83
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66261
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This unit test does not require any additional mocks because init
and shutdown of i2c infra was covered in realtek programmer lifecycle.
Default mocking of i2c is sufficient to run a basic lifecycle.
To run the test, config option for the programmer needs to be
enabled explicitly, since by default this programmer is disabled.
BUG=b:238816889
TEST=meson configure -Dconfig_parade_lspcon=true
ninja test
Change-Id: I0dcfae4a58c64b2e8d56ec51b4b050534cbb4cd2
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66003
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move global singleton states into a struct and store within
the par_master data field for the life-time of the driver.
This is one of the steps on the way to move par_master data
memory management behind the initialisation API, for more
context see other patches under the same topic specified below.
TOPIC=register_master_api
TEST=builds
Change-Id: I58ad1f0222338fc107e7ac2b9cdd361ae7033912
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Ticket: https://ticket.coreboot.org/issues/391
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65970
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Move global singleton states into a struct and store within
the par_master data field for the life-time of the driver.
This patchset also includes stdlib.h to be able to work with
memory allocation.
This is one of the steps on the way to move par_master data
memory management behind the initialisation API, for more
context see other patches under the same topic specified below.
TOPIC=register_master_api
TEST=builds
Change-Id: I63fea00623c149ad304b44aa6265f32ecc1c53eb
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Ticket: https://ticket.coreboot.org/issues/391
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66075
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Move global singleton states into a struct and store within
the par_master data field for the life-time of the driver.
This is one of the steps on the way to move par_master data
memory management behind the initialisation API, for more
context see other patches under the same topic specified below.
TOPIC=register_master_api
TEST=builds
Change-Id: I084cf826a8a594ade80eed43008e286c7bd1b553
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Ticket: https://ticket.coreboot.org/issues/391
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65978
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
