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>
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: I839baad1e6085958a29652f23c9027b6a10edd15
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Ticket: https://ticket.coreboot.org/issues/391
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65974
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>
Instead of printing stderr in each function separately, print all stderr
in the dispatch function.
BUG=None
BRANCH=None
TEST=/usr/bin/flashrom_tester --debug host Lock_top_quad
Change-Id: Id76f83c8c089537aa44aa13533c75900eb6ed175
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65279
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tests can be filtered by providing patterns on the command line. The
pattern is the first argument provided to the test binary, if present.
Only tests matching the string provided are run, wildcards * and ?
match any characters, or one character respectively.
`meson test` or `ninja test` will continue to run all tests, as they do
not provide an argument to the test binary.
https://api.cmocka.org/group__cmocka.html
TEST=tests/flashrom_unit_tests 'layout_*'
Change-Id: I45f4ac5ef0cfb74156408022a19769d6598ad2ea
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65998
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: Felix Singer <felixsinger@posteo.net>
built-0.3 depends on git2-0.9, which is our only user of url-1, which is
our only user of idna-0.1, which depends on rustc-serialize, which
suffers from RUSTSEC-2022-0004. That's a mouthful :)
BUG=b:239449434
TEST=CQ
BRANCH=none
Change-Id: I0d39b417fd2291838e85f91a2af1c8a4fe28a6c2
Signed-off-by: George Burgess IV <gbiv@google.com>
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66140
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Clarify that SWSPI_WDATA_* coincidentally uses the same
commands as specified by JEDEC.
A similar data sheet does not really shed light if these
literally are raw JEDEC command values or 'virtual' ones.
As to avoid confusion, comment but perhaps not use the JEDEC
literals from spi.h until it is certain.
Change-Id: I851319ad4c36baad1e280309a6df8c86d6c4ad3d
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65557
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Currently i2c programmers do not have a safe allow listing
mechanism via board_enable to facilitate fully qualified
chip detection.
Since i2c addresses alone can overlap a user may make the mistake
of using the wrong programmer. Although unlikely, it is within the
realm of possibility that a user could accidently somehow program
another chip on their board.
Change-Id: I819f9a5e0f3102bec8d01dd52a0025a0fbe46970
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65555
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: Thomas Heijligen <src@posteo.de>
Currently i2c programmers do not have a safe allow listing
mechanism via board_enable to facilitate fully qualified
chip detection.
Since i2c addresses alone can overlap a user may make the mistake
of using the wrong programmer. Although unlikely, it is within the
realm of possibility that a user could accidently somehow program
another chip on their board.
Change-Id: I2b8f7a9bfae68354105f3196cc40b9d5e795afdf
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65554
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: Thomas Heijligen <src@posteo.de>
- Make run_command() calls check for failures to fix warnings about
ignoring errors, see https://github.com/mesonbuild/meson/issues/9300.
- Remove `include_directories('../subprojects')` from tests/meson.build.
It isn't necessary and caused build warnings due to referencing files
outside the tests/ directory.
- Fix indent level and formatting in a few places.
BUG=none
BRANCH=none
TEST=meson; ninja; ninja test
Change-Id: I17ae0c51d68ed004772a237641f08345f4893200
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66060
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Introduce the `pickit2_interrupt_transfer()` helper function to simplify
calls to the `libusb_interrupt_transfer()` function, as the last three
arguments are always the same: two constants and an unused output value.
Change-Id: I7ff704243b63a7ea2872fbc6e596190573dc13f6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65915
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Thomas Heijligen <src@posteo.de>
The MAINTAINERS file is a list of people who take special care of
specific things and places of the tree. Also, it gives an overview
about which people are good points for contact in case of questions
appear.
In addition to that, this file is hooked up to Gerrit so that when a
patch is pushed, which touches any of these places, the related people
are added to reviewers or CC. This is done by a tool which looks up the
changed places in the MAINTAINERS file.
To clarify: This MAINTAINERS file does *not* mean that any reviews,
comments or thoughts from other people not listed there aren't welcome
anymore. We just want to make sure that patches don't get lost.
The initial file was copied from the coreboot repository. The format is
the same as the one which is used for coreboot.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: Ic9a302055d941eeb2499a84c62c5fe1d4c9944cf
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65569
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
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: Thomas Heijligen <src@posteo.de>
Use the bool type instead of integer for options, since this represents
the purpose of their variables much better.
Also, use the bool type for the attribute `reset` from the struct
`realtek_mst_i2c_spi_data`, which is used to store the value of
the parameter `reset_mcu`.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: Idffd860e0de0bb82eec6102087e2e19783c32521
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65943
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.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: Edward O'Callaghan <quasisec@chromium.org>
write_file_with_layout test was checking that writing to a region was
failing, and assuming that was because write protect is working as
expected. Other failures are possible, so check that a write to a non
write protected region can succeed.
BUG=b:235916336
BRANCH=None
TEST=/usr/bin/flashrom_tester --debug host Lock_top_quad
Change-Id: I2b220f323e259f5c7bfae06f6cf996b22e264555
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65278
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
