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: Ifb303989fdb67f7267002bd0425f3d050450ec93
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65545
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The chip targeted by the `lspcon_i2c_spi` programmer is a Parade PS175.
Rename the programmer to match the chips vendor / family instead of the
generic LSPCON protocol. Remove the `_i2c_spi` ending in preparation to
become an opaque master. The chip is visible on an Acer Chromebox CXI4.
https://www.paradetech.com/products/ps175/https://www.acer.com/ac/en/US/content/series/acerchromeboxcxi4
TEST: `make CONFIG_PARADE_LSPCON=yes` and
`meson build -Dconfig_parade_lspcon=true` produces flashrom
binaries with the parade_lspcon programmer included.
Change-Id: I9148be6d9162c1722ff739929ca5e181b628dd57
Signed-off-by: Thomas Heijligen <src@posteo.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65547
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This allows programmer 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, this patch also fixes resource
leakage in case register_shutdown() would fail.
TEST=builds
Change-Id: Iab03b8f51d7ec4e20cdae4406896d57903404dd0
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Ticket: https://ticket.coreboot.org/issues/391
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65746
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This patch prepares the programmer to use new API which allows to
register shutdown function in spi_master struct.
TEST=builds
Comparing flashrom binary before and after the patch,
make clean && make CONFIG_EVERYTHING=yes VERSION=none
binary is the same
Change-Id: I56d7273edfc8d323792b110aed1736f94043acb4
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Ticket: https://ticket.coreboot.org/issues/391
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65747
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: Felix Singer <felixsinger@posteo.net>
The name of the struct type already contains nvidia_ prefix, so
prefix doesn't need to be repeated in members name
TEST=builds
Change-Id: If122734c0816b78fd614a31123bbb5e0659d6518
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65744
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
This patch calls into `ich_hwseq_set_addr` function by passing
flash address `0` while performing Read and Write status operation
as Intel SPI BWG recommends that "SW should program the FADDR every
time before any transaction as FADDR is used to determine which Chip Select, CS0 if FADDR <= device 0 size, else CS1".
The reason behind setting the flash address in this patch is to adhere
to the Intel recommended reference implementation that programs FADDR.
Additionally, the followup patch will factor out `hwseq_xfer` logic
to create a helper function that ensures all SPI related operational
APIs could leverage the common `hwseq_xfer` logic.
BUG=b:223630977
TEST=Able to perform read-status/write-status operation on PCH
600 series chipset (board name: google/kano).
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ib1d85ebdde99a31728f404d66a1eb4e3599b9054
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65468
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.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>
Enable probing for IT8686E allowing to use the `dualbiosindex`
parameter. Dumped and verified both firmwares. Tested on GIGABYTE
GA-H270N-WIFI.
Signed-off-by: Pete Smith <zailawee@protonmail.com>
Change-Id: I5a1780275a92089c2d91c5da1c472f6d8bc39a56
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64254
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Unit tests had an unconditional dependency on libusb and this was
a) strictly speaking not needed, b) blocking one build system effort.
This patch is a temporary solution to unblock one build system effort,
specifically CB:63724. It creates a condition so that libusb is only
included when it is required, not always.
This workaround is based on the fact that at the moment only
2 lifecycle unit tests are using libusb symbols: dediprog and
raiden_debug.
BUG=b:237606255
TEST=the following scenarios run tests successfully
1) dediprog and raiden_debug programmers enabled, libusb.h present
result:
all test run and pass
2) dediprog disabled, libusb.h present
result:
dediprog test skipped, all other tests run and pass
3) dediprog and raiden_debug both disabled,
libusb.h changed to libusbabcd.h
result:
dediprog and raiden_debug tests are skipped,
all other tests run and pass
Change-Id: Iec8a1826951fd6ae586e90fde1a55170e7de41a8
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65627
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
This patch creates individual files for each programmer's lifecycle
tests. Common functions that are reusable for all tests are
gathered in lifecycle.c. Each individual file needs to include
lifecycle.h
BUG=b:237606255
TEST=ninja test
Change-Id: If2307699dcbb3a085b91a2dcd41156e6fd07f812
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65543
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Lifecycle functions will be used in all lifecycle tests and need to
be available by including lifecycle.h
BUG=b:237606255
TEST=ninja test
Change-Id: Ic4e9defe16c535c9384c1304c1cad2f5b84294c9
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65542
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
New header file lifecycle.h need to gather all things shared among
lifecycle tests.
This is one step to the goal of splitting lifecycle tests into
separate per-programmer file.
BUG=b:237606255
TEST=ninja test
Change-Id: I93d0db943d9c96e2c36e9f7dce5c885c959745a0
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
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 "register_master_api".
BUG=b:185191942
TEST=builds
Change-Id: I00877e3cc359996e3aa59649f62c76e521ab119b
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Ticket: https://ticket.coreboot.org/issues/391
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65342
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
The name of the struct type already contains drkaiser_ prefix, so
prefix doesn't need to be repeated in members name
TEST=builds
Change-Id: Ice3883b5171bdd2b4814ba4c5a7668c800ee7492
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Avoid confusion from the comment. While technically a GPIO
can do anything, like drive a LED. The GPIO pin 88 *is*
meant to drive the WP line of the SPI flash, that is its
purpose.
Change-Id: If718d41a27931380e5f7ebdb75b9863da0c61559
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65546
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
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>
As reported by Charles Parent on the mailing list.
Change-Id: I9d8b0038673185103ba08c9797ff94f2f7639d6c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62664
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This code was originally introduced by ITE for now exceedingly old
Chromebooks. The code has had very little attention to maintain it,
unlikely tested for a long time and now seems to be just a technical
burden to the flashrom project.
If someone is later interested it could be resurrected for reference
from git history. However, it needs quite a bit of work to bring it back
into maintainable order.
BUG=b:156143896,b:170689483
TEST=tree builds under meson+make and unit tests pass.
Change-Id: I5e8cafd73db837941c518f0e2d72d8192274fd79
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65378
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
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 "register_master_api".
Implements: https://ticket.coreboot.org/issues/391
BUG=b:185191942
TEST=builds
Change-Id: I3dd35eceadb9dbca8e526705b7be977564ed7318
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65194
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Lifecycle tests had local struct declared with static keyword, but
static was not necessary for them. So, removing.
BUG=b:233816068
TEST=ninja test
Change-Id: If844d07ec42b878bd0da8460655be45e865f089f
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65323
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Evan Benn <evanbenn@google.com>
Reviewed-by: Joursoir <chat@joursoir.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
In commit a721181a08 dummyflasher became an opaque master too, and
now registers prog bus by default. This patch upgrades a dummy unit
test which uses all buses as programmer param, and adds a unit test
which covers specific use case for opaque programmer.
BUG=b:233816068
TEST=ninja test
Change-Id: I61a5333b61ea84fb91c7f8310d52b64213c62f83
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65236
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Joursoir <chat@joursoir.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>
There is a function, spi_get_erasefn_from_opcode, which returns the
erase function for given opcode. Add a function which does the opposite
i.e. returns the opcode for given erase function.
Change-Id: Ia3aefc9b9465efdd16b1678bb2ada9a23f00d316
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Add a list (erasefn, opcode) which maps opcodes to erase functions.
Modify the spi_get_opcode_from_erasefn to use this list.
Change-Id: I126f88c313ad309b509b367f9087235b87df6136
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65351
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Simon Buhrow
Reviewed-by: Thomas Heijligen <src@posteo.de>
Simplify ich9_handle_frap() to do the translation to the logical
representation of the ich_access_protection enum in one place and
work from there. This removes some unnecessary branch complexity
and the possibility of out of bounds array accesses.
Change-Id: I1eda067c44a84d662713475d13902c85534a59fe
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65189
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
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>
Now that we can make use of the extended-address register, we can also
advertise the `d8` eraser that can take 3- or 4-byte addresses.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Ticket: https://ticket.coreboot.org/issues/357
Change-Id: I8708294d42f5da80c0ca07ccdae627f13fd5c645
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64637
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
According to its datasheet, Spansion S25FL512S supports writing/
reading its extended address register via 0x17/0x16 opcodes. With
that enabled, we can also enable the EAR7 feature, i.e. toggling
4BA mode via bit 7 of that register.
S25FL512S did not advertise EAR support at all, so we set it to
TEST_UNTESTED again.
Change-Id: Ib214e509a5c294ab60460a2b5d00a713a119ab3f
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65265
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
According to their datasheets, ISSI IS25LP256 and IS25WP256 support
both 0xc5/0xc8 and 0x17/0x16 opcodes to write / read their extended
address register. Flashrom will use 0xc5 by default if available,
so adding the FEATURE_4BA_EAR_1716 flag makes no difference for now
(FEATURE_4BA_EAR_C5C8 is included in the already selected FEATURE_4BA
set). It's better to have a comprehensive description of the chips,
though, in case somebody wants to use them in the future with a
master that restricts available opcodes.
Change-Id: I03e4ff825c7742e7ff79b51b75293d53a091d4d4
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65264
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.
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>
4BA support is implemented by now. So drop these obsolete comments.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: I28c5d1de052c28735d5f07874874068ee744b77f
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64600
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
The W25Q256JV supports the full set of 4BA instructions, including two
native-4BA block erasers.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: I1a68121ff40d2b1769632d8e5151c2cd972c23ef
Ticket: https://ticket.coreboot.org/issues/362
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64599
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
As discovered earlier[1], the `vendor_id` and `device_id` fields are not
always automatically set. However, we use these fields throughout flash-
rom. To not lose track when we actually fetched them, let's always call
pci_fill_info(PCI_FILL_IDENT) before returning a `pci_dev` handle.
[1] Commit ca2e3bce0 (pcidev.c: populate IDs with pci_fill_info())
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: Iae2511178bec44343cbe902722fdca9eda036059
Ticket: https://ticket.coreboot.org/issues/367
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64573
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
The ichspi hwseq path has a opaque master specialisation that
allows for reading and writing STATUS1 registers. Hook the callbacks
with a implementation to allow for this so that writeprotect maybe
supported though this path.
BUG=none
BRANCH=none
TEST=flashrom --wp-status on AMD and Intel DUTs
Change-Id: I7ecbe8491ecea3697922c91af26ca62276e86317
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64540
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Allow specialisation in opaque masters, such as ichspi hwseq, to
write to status registers.
Also update the dispatch logic in libflashrom to call wp code when
status register access functions are provided by an opaque master.
BUG=none
BRANCH=none
TEST=flashrom --wp-status on AMD and Intel DUTs
Change-Id: I3ab0d7f5f48338c8ecb118a69651c203fbc516ac
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Co-Authored-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64375
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
hwaccess functions used to be static inline functions and needed
a special treatment so that they could be mocked for unit tests.
This has changed, see include/hwaccess_x86_io.h now the functions
are not static inline anymore, and it is possible to use regular
cmocka wraps.
Fixes https://ticket.coreboot.org/issues/385
BUG=b:181803212
TEST=ninja test
Change-Id: Iafce071ea7ad5bcfdebbba968699d5743705f8e0
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64881
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joursoir <chat@joursoir.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
These chips seem to be rather regular, supporting 2.7V..3.6V, the
common erase block sizes 4KiB, 32KiB, 64KiB and the usual block-
protection bits.
Status/configuration register naming differs from other vendors,
though. These chips have 2 status registers plus 3 configuration
registers. Configuration registers 1 & 2 match status registers
2 & 3 of what we are used from other vendors. Read opcodes match
too, however writes are always done through the WRSR instruction
which can write up to 4 bytes (SR1, CR1, CR2, CR3).
S25FL256L supports native 4BA commands and entering a 4BA mode.
However, it uses an unusual opcode (0x53) for the 32KiB 4BA block
erase.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: I356df6649f29e50879a4da4183f1164a81cb0a09
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64747
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
Add a check so that the erase functions for all flashchips are in
increasing order of their respective eraseblock sizes. This is required
for the implentation of the improved erasing algorithm. The patch uses
the count of eraseblocks in each erase function to determine the order
(More eraseblocks means that the function has smaller eraseblock size).
Also fix the structs in flashchips.c which were found to be not
conforming to this test.
TEST = make && ./flashrom
Change-Id: I137cb40483fa690ecc6c7eaece2d9d3f7a851bb4
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64961
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 "register_master_api".
Implements: https://ticket.coreboot.org/issues/391
BUG=b:185191942
TEST=builds
Change-Id: I82e4c82916dc835e9462b80750b06f9d78701edf
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64963
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>
A macro value has to use a correct argument name.
Change-Id: I666204ec92c6df625b34ca721b3e1af78772bccf
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65193
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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>
Some functions were not being defined, namely flashrom_wp_*. Thus, add
all missing functions from libflashrom.h header file.
Change-Id: Ic90b3c20780d3a07b00bfca82d23d44c4fa6f22f
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64851
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
