| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note: This patch was backported from the master branch and it was
modified so that it can be applied on the 1.2.x branch.
`ich_hwseq_wait_for_cycle_complete()` drops taking `timeout` as argument
in favor of a fixed timeout of `30 seconds` for any given SPI operation
as recommended by the SPI programming guide.
Document: Alder Lake-P Client Platform SPI Programming Guide
Rev 1.30 (supporting document for multi-master accessing the
SPI Flash device.)
Refer to below section to understand the problem in more detail and SPI
operation timeout recommendation from Intel in multi-master
scenarios.
On Intel Chipsets that support multi-mastering access of the SPI flash
may run into a timeout failure when the operation initiated from a
single master just follows the SPI operational timeout recommendation
as per the vendor datasheet (example: winbond spiflash W25Q256JV-DTR
specification, table 9.7).
In the multi-master SPI accessing scenario using hardware sequencing
operation, it's impossible to know the actual status of the SPI bus
prior to individual master starting the operation (SPI Cycle In Progress
a.k.a SCIP bit represents the status of SPI operation on individual
master).
Thus, any SPI operation triggered in multi-master environment might need
to account a worst case scenario where the most time consuming operation
might have occupied the SPI bus from a master and an operation initiated
by another master just timed out.
Here is the timeout calculation for any hardware sequencing operation:
Worst Case Operational Delay =
(Maximum Time consumed by a SPI operation + Any marginal
adjustment)
Timeout Recommendation for Hardware Sequencing Operation =
((Worst Case Operational Delay) * (#No. Of SPI Master - 1) +
Current Operational latency)
Assume, on Intel platform with 6 SPI master like, Host CPU, CSE, EC,
GbE and other reserved etc, hence, the Timeout Calculation for SPI
erase Operation would look like as below:
Maximum Time consumed by a SPI Operation = 5 seconds
Worst Case Operational Delay = 5 seconds
Timeout Recommendation for Hardware Seq Operation =
5 seconds * (6 - 1) + 5 seconds = 30 seconds
BUG=b:223630977
TEST=Able to perform read/write/erase operation on PCH 600 series
chipset (board name: Brya).
Original-Signed-off-by: Subrata Banik <subratabanik@google.com>
Original-Reviewed-on: https://review.coreboot.org/c/flashrom/+/62867
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Original-Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Change-Id: Ifa910dea794175d8ee2ad277549e5a0d69cba45b
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68691
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note: This patch was backported from the master branch and it was
modified so that it can be applied on the 1.2.x branch.
The developerbox_spi programmer depends on bitbang SPI support. Thus,
fix that.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: Ic0fe589ffdccede0fbf6360c2bebe58a36654f10
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66096
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68064
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The flashrom project no longer uses freenode. To avoid having outdated
man pages in the future, the contact methods are now listed in the wiki.
Change-Id: I75e8f43c50dc4c3feede0250334a877cdaac8103
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56031
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>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68063
|
|
|
|
|
|
|
|
|
|
| |
Change-Id: I5c67b5b3be2f306132d8565539bbf10477222026
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56030
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>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68062
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The parsing of the output of archtest.c produced an unexpected
value on AArch64 NixOS. For example, the make variable ARCH was set to:
```
bit outside of fd_set selected
arm
```
This made the arch and OS checks fail.
This commit simplifies the parsing, making it more robust.
The C files archtest.c, endiantest.c and os.h used to set the
TARGET_OS, ARCH and ENDIAN variables, respectively, output
the result of the test as the final line, so just extracting
the final line and removing double quoting is enough.
This commit also fixes a bug with debug_shell lacking escaping
single quotes, which prevented using the single quote in the
debug_shell calls. It used to work by accident before this fix;
the line in the call happened to contain a balanced pair of double
quotes and lacked other characters that needed escaping, which
didn't break the debug_shell, but this was accidental and very
brittle.
Signed-off-by: Pyry Kontio <pyry.kontio@drasa.eu>
Change-Id: Iaa4477a71e758cf9ecad2c22f3b77bc6508a3510
Reviewed-on: https://review.coreboot.org/c/flashrom/+/43140
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67902
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())
Backported to older versions where pcidev handling was much more
scattered.
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
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67877
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With pciutils 3.7.0, flashrom is unable to match any PCI devices by
vendor/device ID because the vendor_id and device_id fields of struct
pci_dev are not filled in.
Call pci_fill_info() to request these identifiers before trying to match
them against the supported device list.
The pciutils ChangeLog for 3.7.0 mentions that the documentation and
back-end behavior for pci_fill_info() was updated; it seems that a call
to pci_fill_info() was always intended to be required, but some backends
(such as the sysfs one used on Linux) would fill the identifier fields
even when not requested by the user. The pci_fill_info() function and
the PCI_FILL_IDENT flag have been available for all versions of pciutils
since at least 2.0 from 1999, so it should be safe to add without any
version checks.
With this change, reading/writing a nicintel_spi boot ROM is successful.
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Change-Id: Ia011d4d801f8a54160e45a70b14b740e6dcc00ef
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46310
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67876
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the physmap*() functions, NULL is considered valid return value.
Fixes a segmentation fault when DMI tables can't be mapped.
Tested on intel/eblake board with broken coreboot.
Change-Id: Ic403c2940c2b91acbd113f0acfa3ce9ef6c6bb6c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62611
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67875
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the linux_mtd driver treat any negative return value from the
MEMERASE ioctl as an error. Previously it only treated -1 as an error.
BUG=b:213561594,b:210973586,b:182223106
BRANCH=none
TEST=builds
Change-Id: I40cfbdee2ab608fbe6c17d9cac6ec53ff224d9a4
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/60996
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-on: https://review.coreboot.org/c/flashrom/+/67874
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
| |
Change-Id: I64a8200a86329bd26a2069c5dc39430de9f8ba09
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/57807
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67873
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The maximum transfer size is too large for some devices and
results in an USB timeout.
Change-Id: If2c00b1524ec56740bdfe290096c3546cf375d73
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48379
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Miklós Márton <martonmiklosqdev@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67872
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We open the device node for the MTD device with this:
dev_fp = fopen(dev_path, "r+")
In C fopen() is allowed to provide _buffered_ access to the file.
That means that the standard library is allowed to read ahead and/or
return cached data. That's really not what we want for something like
this. Let's turn it off.
This fixes a problem where flashrom would sometimes fail to "verify"
that it erased the flash. The error message would look something like
this:
Erasing and writing flash chip... FAILED at 0x0000e220! Expected=0xff, Found=0xe9, failed byte count from 0x0000e200-0x0000e2ff: 0xdc
failed byte count from 0x0000e000-0x0000efff: 0xffffffff
ERASE_FAILED
FAILED!
Uh oh. Erase/write failed. Checking if anything changed.
After the failure I could read the flash device with a new invocation
of flashrom and I would see that, indeed, the erase had worked.
Tracing in the kernel showed that when the failure happened we saw a
pattern that looked like this:
* Read 0x0b00 bytes starting at 0x0000d000
* Read 0x1000 bytes starting at 0x0000db00
* Erase 0x1000 bytes starting at 0x0000e000
...and then there was _not_ a read after the erase. It can be assumed
that, since userspace had already read 0xdb00 - 0xeaff that it was
looking at old buffered data after the erase.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Change-Id: I989afd83a33013b2756a0090d6b08245613215c6
Reviewed-on: https://review.coreboot.org/c/flashrom/+/50155
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67871
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using strlen() or strdup() inside strndup() is problematic: if the
input string is not null-terminated, these functions can read past the
end of the buffer, which triggers undefined behavior. Rewrite the
function to never read past the provided `maxlen` bound.
Change-Id: Id34127024085879228626fbad59af03268ec5255
Signed-off-by: Xiang Wang <merle@hardenedliux.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49741
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67870
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67869
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Validate the physical mapping in enable_flash_silvermont().
Change-Id: Icc5a799a06b3f310d9a191fa5eb99b255b20d79d
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48225
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67868
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Port from the ChromiumOS fork of flashrom.
Change-Id: I8075fe5f80ac0da5280d2f0de6829ed3a2496476
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46444
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67867
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The memory for the `param` string is aliased by `dualbiosindex_suffix`.
Moreover, `errno` could have been modified by the call to `free()`.
Therefore, only free the former when there are no more uses of either.
Change-Id: I79f18f6077c77c0cbb8bfa431e17f9b079f11c95
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46551
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67866
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When hardware write protect is applied, flashrom crashed and
generate coredump. spi_disable_blockprotect_generic() calls
flash->chip->printlock() method when disable was failed,
but this method is optional, can be NULL depends on type of
flashrom chip. NULL pointer check before call is added to
avoid crash.
BRANCH=none
BUG=b:129083894
TEST=Run on Mistral P2
(On CR50 console, run "wp disable")
flashrom --wp-range 0 0x400000
flashrom --wp-enable
(On CR50 console, run "wp enable")
flashrom -r /tmp/test.bin
Verify "Block protection could not be disabled!" is shown,
but flash read completes.
Signed-off-by: Yuji Sasaki <sasakiy@chromium.org>
Change-Id: I81094ab5f16a85871fc9869a2e285eddbbbdec4e
Reviewed-on: https://chromium-review.googlesource.com/1535140
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: SANTHOSH JANARDHANA HASSAN <sahassan@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/40468
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67865
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change-Id: I08c0612f3fea59add9bde2fb3cc5c4b5c3756516
Found-by: Coverity Scan #1412744
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/40653
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67864
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 92d6a86 ("Refactor Intel Chipset Enables") eliminated a check
to disable SPI when ICH7 has booted from LPC, as the hardware does not
support it. Therefore, when flashrom probes the SPI bus, it times out
waiting for the hardware to react, for each and every SPI flash chip.
This results in very long delays and countless instances of the error:
Error: SCIP never cleared!
To prevent this, bring back part of the lost check. Probing for LPC and
FWH when booted from SPI does not seem to cause any problems on desktop
mainboards with ICH7, so don't disable LPC nor FWH if that is the case.
Tested on ECS 945G-M4 (ICH7, boots from LPC), works without errors.
Change-Id: I5e59e66a2dd16b07f2dca410997fce38ab9c8fd1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/40401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67863
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the transfer failed, the data might be invalid.
Change-Id: I3ad9daa00a54e2a3954983cec91b6685f1a98880
Found-By: Coverity Scan #1405870
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/40970
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67862
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows flashrom to build with GCC 10.
Change-Id: I2166cdf3681452631ef8e980face2924e9a6c81a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/41775
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67861
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of hard coding the test procedure on qa.coreboot.org, allow
running a script in the repo instead. The server is already adapted
to do that, so once there's a test_build.sh file in the toplevel
directory, it's run in place of the default operation.
The content of this change mirrors the default operation exactly so
should serve as a good starting point.
The script is executed in an encapsulate[0] context with the workspace,
/tmp and $HOME/.ccache writable, everything else read-only and
network disabled.
It should return 0 on success, anything else on failure, as is normal
for UNIX processes.
[0] https://review.coreboot.org/cgit/encapsulate.git
(Backported minus the Meson support)
Change-Id: I37a8e925d1b283c3b8f87cb3d0f1ed8920f2cf95
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46894
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62617
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67860
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As found on the Tesla AP2.5 board.
Based on https://mail.coreboot.org/pipermail/flashrom/2013-June/011066.html
Tested with:
flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=512 -r content.bin
Signed-off-by: Bernhard Urban-Forster <lewurm@gmail.com>
Change-Id: Ifa9b7615951125b6bbc1f051370ef54896bf506c
Reviewed-on: https://review.coreboot.org/c/flashrom/+/38596
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Intel Ice Lake systems use an 495 Series Chipset
that behaves compatible to pch300 chips but chip names
are undocumented at this point.
This change was tested in read/write/erase on the Razer
Blade Stealth (late 2019) with intel 1065G7 CPU and
"Ice Lake U Premium PCH".
Change-Id: I6227d32f4476420cf1aeec37ebd4b7648e0b3d15
Signed-off-by: Johanna Schander <git@mimoja.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/37987
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christoph Pomaska <github@slrie.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Change-Id: Iea40da587729f3975a8901d3933e7567805242c5
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/38659
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Intel Kaby Lake U (with the 9d4e device id) support is available but
marked not tested.
Tested reading, writing and erasing both internal flash chips on the
Facebook Monolith system with the Intel i3 7100U SoC. However, since all
ME-enabled chipsets are marked as DEP instead of OK, this one shall follow
suit as well.
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Change-Id: Ie35cc896e29baffa63fe9e37c14770001b54e7ec
Reviewed-on: https://review.coreboot.org/c/flashrom/+/38481
Tested-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Change-Id: Ia5ed00c488b0719b2bdd6c8f304900511684f445
Reviewed-on: https://review.coreboot.org/c/flashrom/+/38477
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit e28d75ed7204d7fac2c0fac13978098530b0574e.
This is broken in multiple ways, e.g. pcidev_init() can only return
NULL.
Change-Id: I06242147ba9d3a062d442f645eb0800ef51af19f
Signed-off-by: Nico Huber <nico.h@gmx.de>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Reported-by: Michael Bishop <cleverca22@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/38319
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC 4.8 wants an explicit `-std=c99` or something for this to work. It
seems easier to keep the common declaration style.
Change-Id: Ic0819f82169df4d66cc949494229b0749c06e8f6
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/38034
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Miklós Márton <martonmiklosqdev@gmail.com>
|
|
|
|
|
|
|
|
| |
Change-Id: Icffab87ac8f2c570187ed753ec70f054541873a4
Signed-off-by: Miklós Márton <martonmiklosqdev@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/34661
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tested reading, writing and erasing the internal flash chip using a
Samsung NP530U3C laptop with an Intel HM76 PCH. However, since all
ME-enabled chipsets are marked as DEP instead of OK, this one shall
follow suit as well.
Change-Id: I1097c5fcf782e7ecf52f05c571ad188456307d00
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/37803
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
|
|
|
|
|
|
|
|
|
|
| |
Something to point users to when SMM_BWP might be causing problems.
Change-Id: I394c033e8d4ff96433162f86aefb428d8acf6349
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/36986
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Change-Id: I88cbe74b716d5fab16133fbf2ce9c35b74c25f32
Reviewed-on: https://review.coreboot.org/c/flashrom/+/35831
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds support for the Adesto AT25SF321 SPI flash chip. Probe
and read operations have been tested via FT2232H interface, but writes
have not been verified.
Datasheet is available at the following URL:
https://www.adestotech.com/wp-content/uploads/DS-AT25SF321_047.pdf
Change-Id: I7410815e063ffe154a97d7ea5881c8eb82025f56
Signed-off-by: Peter Adkins <pete@kernelpicnic.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/36904
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't entagle the code paths for the two NIC classes if it's not necessary.
Only compile tested.
Change-Id: I59164ccf54afbbd64a0598282d13e80ff7fd6fa4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/33637
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 61e16e549a52194ac80ef40504f2dc661d1ff99c.
Obviously throws alignment in the table off and changes output
class from `general` to `programmer` for no visible reason.
Change-Id: I864044b9fac6af9cf6a89c053eccdcb36f17c7bd
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/36909
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Tin Can Tools Flyswatter and Flyswatter 2 have a FT2232H
with a JTAG interface wired to port A. The buffers that drive the
JTAG pins need to be enabled with an nOE signal from the
FT2232H ADBUS6 and ADBUS7 pins.
Flyswatter has an ARM-14 JTAG interface and Flyswatter 2 has
an ARM-20 JTAG interface.
Change-Id: I56b1fb76dcda32bb02980cd54a2853506bfc9dfd
Signed-off-by: Russ Dill <Russ.Dill@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/36896
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
This makes writing unit-tests easier.
Change-Id: Ia2718f1f40851d3122741cd0e50b0c2b647b727a
Signed-off-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/37264
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
|
|
|
|
|
|
|
|
|
| |
Write a pure function for the table validation logic, it is
easier to unit-test.
Change-Id: I07b0f95ec0443fa6a8f54eb93f4a7ea1875cccad
Signed-off-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/37239
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Write a pure function for the header validation logic, it is
easier to unit-test.
Change-Id: Ia288bcbc5c371329952a6efba30ccf0e18965a3d
Signed-off-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/37238
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
|
|
|
|
|
|
| |
Change-Id: I72164323d7ff98fc50cb0c47b69741a4f047e098
Signed-off-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/36905
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
It doesn't like empty initializers.
Change-Id: If2988e60401155f87ee3369c77f00ccf9332012c
Signed-off-by: Evgeny Zinoviev <me@ch1p.io>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/36629
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
|
|
| |
Drop dead USE_YANGTZE_HEURISTICS code and add Promontory support.
Change-Id: I5aa7370025f5c1af56c6cb96194b6f3007d0ede7
Signed-off-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/36426
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
|
| |
Change-Id: I6c722e29b321285bf20fb5ee30c912dcdd83411b
Signed-off-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/36425
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
|
|
|
|
|
|
|
|
|
| |
V.2: Rename 'find_smbus_dev()' -> 'find_smbus_dev_rev()'.
Change-Id: I766b29cc1c7d01aa0bcf6cb9ff5ab73fa1995dcd
Signed-off-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/36420
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
| |
Change-Id: I9477b6f0193bfdf20bbe63421a7fb97b597ec549
Signed-off-by: Miklós Márton <martonmiklosqdev@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/25683
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Port the code from chromeos flashrom
BUG=b:144297264
TEST=Tested using W25Q128JWDTR in SPI mode
Signed-off-by: Peichao.Wang <peichao.wang@bitland.corp-partner.google.com>
Change-Id: Ifc28878b17dc10da2cfd8f82fffbd57adb22799e
Reviewed-on: https://review.coreboot.org/c/flashrom/+/36717
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds missing voltage and capacity variants for N25Q and MT25Q
series devices. This also fixes a typo in some model numbers where the
last letter should have been a G instead of an E. Added devices include:
N25Q256..1E
N25Q512..1G
N25Q00A..1G
N25Q00A..3G
MT25QU128
MT25QL128
MT25QU256
MT25QU512 tested by Jacob Creedon <jcreedon@google.com>
MT25QL01G tested by Konstantin Grudnev <grudnevkv@gmail.com>
MT25QU01G
MT25QL02G
MT25QU02G
Two have been tested as indicated, all other variants added are marked
untested.
Signed-off-by: Jacob Creedon <jcreedon@google.com>
Change-Id: I85630e4f6c0aa3b261f9871b7d363dad278b997e
Reviewed-on: https://review.coreboot.org/c/flashrom/+/34491
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
|