Note: This patch was backported from the master branch and it was
modified so that it can be applied on the 1.0.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/+/68689
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
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/+/68059
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/+/67845
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
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/+/67844
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/+/67842
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
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/+/67841
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
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/+/67840
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
We never read the first 'ret'. Let's check the first 'ret'
and exit if it failed.
Also, print the version only when the command succeeded.
Backported to libusb-v0 version (checking for CMD_LENGTH
instead of 0 return value).
Found-by: scan-build 7.0.1-8
Change-Id: I4aac5e1f3bd0604b079e1fdd9b7f09f1f4fc2d7f
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/34403
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67838
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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/+/62616
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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/+/62614
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The erase (-E) feature is somehow a brute force method, but still, if we
are given a region to erase, we should make sure to restore surrounding
data if the erase block expands beyond the region.
Slight alteration from `master` commit: Guard free() from NULL pointers
to be regression safe even in case of broken libc.
Change-Id: I5fc35310f0b090f218cd1d660e27fb39dd05c3c5
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/31069
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The full verification step was not accounting for sparse layouts.
Instead of the old contents, combine_image_by_layout() implicitly
assumed the new contents for unspecified regions.
Change-Id: I44e0cea621f2a3d4dc70fa7e93c52ed95e54014a
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/30372
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This never was a use case until now but the `--fmap` code makes it
obvious: Unaligned reads that were smaller than the `chunksize` here,
were extended without considering the length of the buffer read into.
With that fixed we run into the next problem: dediprog_spi_bulk_read()
shouldn't report an error when an empty read is unaligned.
Change-Id: Ie12b62499ebfdb467d5126c00d327c76077ddead
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/30051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30380
Reviewed-by: Nico Huber <nico.h@gmx.de>
Leaving the `linux_spi` driver's unknown default is almost never what we
want and resulted in many support requests since Raspbian switched to a
default that is too high for most applications.
Change-Id: I9361b7c1a1ab8900a619b06e1dae14cd87eb56c2
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/30371
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It turned out that older kernels use a single buffer for combined
input and output data. So we have to account for the read command +
max 3 address bytes.
Change-Id: Ide50db38af1004fde09a70b15938e77f5e1285ac
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/25150
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Update the DOS cross-compile documentation,
and workaround issue with valloc() with the
latest DJGPP.
Change-Id: I909c5635aec5076440d2fde73d943f8ad10b8051
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: https://review.coreboot.org/23044
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
By adding more #if guards, fix warnings about unused constants that
are enabled by default in newer GCC versions.
Change-Id: Ib3b6d7c0c2fadc4faeab971673bfadb1a6d25919
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
(cherry picked from commit 97a90497a7d0df5076b4412c3e995a7e4a2ff8cc)
Reviewed-on: https://review.coreboot.org/22800
The interface of spi_read_status_register() is broken and can't return
errors. Let's not return random stack data at least.
Change-Id: I714b20001a5443bba665c2e0061ca14069777581
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22017
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
(cherry picked from commit 1f081530b60ee805532f106f59cc33973e160481)
Reviewed-on: https://review.coreboot.org/22349
Skylake is a mess, especially with coreboot. We have now a present and
configured software sequencing interface with SCGO supposedly being
readonly (Apollo Lake has that feature and a strap documented, Skylake
behaviour might be the same). As we can't easily check if it's read-
only, just enable hardware sequencing by default (even if the software
sequencing interface seems usable).
Change-Id: I8a13fb9c3ca679b3f7d39ad1dc56d5efdc80045b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/22348
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Two occurences of ICH9_REG_OPMENU were overlooked and not replaced,
rendering the software sequencing unusable on Skylake.
Change-Id: I16eebcf37ab8ba39b02f33135535552e380b0b92
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/22273
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
(cherry picked from commit 8b2152d54a67e4139525ce49aefe1a6d0e41b85c)
Reviewed-on: https://review.coreboot.org/22332
Reviewed-by: Nico Huber <nico.h@gmx.de>
TARGET_OS as well as EXEC_SUFFIX were only set when called via the
main makefile and even then __USE_MINGW_ANSI_STDIO was not set
for MinGW.
While at it, also replace the hardcoded gnu_printf printf format
attribute with __MINGW_PRINTF_FORMAT which is set according to
__USE_MINGW_ANSI_STDIO respectively.
Change-Id: Id146f5ba06a0e510397c6f32a2bd7c819a405a25
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21838
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22336
Tarballs on download.flashrom.org are generally packaged using bzip2, so
we may as well be internally consistent.
Change-Id: Ib9fb1ea6d5994cd0285ce8db9675640fae992773
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/22116
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-on: https://review.coreboot.org/22335
The (old) ST (now Micron) M25P05 does only support RES for identification.
Unfortunately, the vendor datasheet states the same ID as for the M25P10
(0x10) and thus flashrom has treated these two as evil twins in the past.
However, real hardware confirmed that the real ID of this chip is 0x05.
Change-Id: Idc75f8cb98e7ef0c47c4527cedcc4da3723bd779
Signed-off-by: Serge Vasilugin <vasilugin@yandex.ru>
Tested-by: Serge Vasilugin <vasilugin@yandex.ru>
Reviewed-on: https://review.coreboot.org/21920
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-on: https://review.coreboot.org/22333
without the upcache there is no "offline" version (yet).
Change-Id: Iac3bf11fbd55cfa034ef8af04ef90fe57182ee2b
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21836
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
refine the pre-push hook:
- get rid of the concept of precious brances - all of them on the
upstream repos are precious (this is a change in the face of
using gerrit instead of a native git repository for staging purposes)
- likewise, only allow new versioned stable branches and no feature
branches there
Change-Id: I1d4b4a7ef2673cabee980ec4a7d7d5fbebdcaed1
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21834
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
- update the commit-msg hook to the latest one provided by Gerrit.
However, disable the (new) code that would avoid adding Change-IDs
to fixup/squash commits as needed on the staging branch
Change-Id: I2f2d7ae58dcd7d3e55959e18fe664df10bc3cc41
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21832
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- wrap a line in the hook installer. The line still exceeds our
maximum limit by two chars but it makes no sense to break
apart the one long argument IMHO
Change-Id: I0e931fbb5902d2714d5399c1d1bfac0de35523bb
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21831
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- exploit Make's -include statement to simplify execution flow
- expand and refine respective comment to better describe and
match the new behavior
Change-Id: I0c66f2508cc754cf9219211a06d6f305a32c422d
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21830
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rename getrevision's local_revision function to just revision.
All revisions are local in git and we certainly wont go back to
a non-distributed VCS :)
Change-Id: I6689ac24077b3981b471ed69de7cc3ef79d435b1
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21829
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
- make version string generation independent of the actual VCS
used by not generating "unknown" in the makefile but letting
getrevision do that
- make hook installation independent of version string generation
since they have nothing to do with each other and there are no
synergies anymore
Change-Id: Iedc9df4c033a70447b8b1b65c83764c769b02c3f
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21827
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Use a more generic file name for the exported VCS data.
Change-Id: Ie57b20dc014ba44ded5783bdb432eb7d0e0e28ad
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21826
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Fix broken/one-off loop to restore file dates.
Explain what the sed program actually does because it is non-trivial.
Change-Id: Iff4021be49a9fab208b619c555b9f9e81f671ab8
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21825
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
"System Manager's Manual" or similar is way less interesting.
Change-Id: I45c5d6a2316c51a57a49fd010682dc3f0f915382
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21822
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A couple of C99-style variable declarations within loops are causing
compilation failures on some systems (gcc 4.9.2-10 on Raspbian). This
moves them to make gcc happy.
Change-Id: Ib7ad5a69244e462f84eae93df9e841716e089b31
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/21702
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Replace bit shits with BIT() macro. This improves the readability of the
code.
Change-Id: I30315891f18d4d5bfbc247bb9012560479afab90
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-on: https://review.coreboot.org/21432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Implements I210 "raw" flash access as detailed in:
http://www.intel.com/content/www/us/en/embedded/products/networking/i210-ethernet-controller-datasheet.html
Unfortunately, most of the time the card is in Secure Mode, which means
that the raw access is not available. But his should be pretty useful
for bringing up boards.
Change-Id: I8598ab21297b85dcae1e650a168043aa4cc15c10
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-on: https://review.coreboot.org/21430
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
On the I210 family there is no MAC EEprom, instead there is a big flash
(typically around 16Mb) with contents of the old MAC plus other stuff.
There is an interface to program the whole flash, but once it is
programmed it enters a "Secure Mode" that disables the interface.
Luckily, the section with the MAC can still be updated via the EEprom
interface. This patch adds support for this interface.
root@qt5022-fglrx:~# ./flashrom -p nicintel_eeprom:pci=01:0.0 -w kk.raw -V
flashrom v0.9.9-unknown on Linux 4.10.0-qtec-standard (x86_64)
flashrom is free software, get the source code at https://flashrom.org
flashrom was built with libpci 3.4.1, GCC 5.3.0, little endian
Command line (5 args): ./flashrom -p nicintel_eeprom:pci=01:0.0 -w kk.raw -V
Calibrating delay loop... OS timer resolution is 1 usecs, 1856M loops per second, 10 myus = 10 us,
100 myus = 102 us, 1000 myus = 1017 us, 10000 myus = 10044 us, 4 myus = 4 us, OK.
Initializing nicintel_eeprom programmer
Found "Intel I210 Gigabit Network Connection" (8086:1533, BDF 01:00.0).
Requested BAR is of type MEM, 32bit, not prefetchable
Requested BAR is of type MEM, 32bit, not prefetchable
The following protocols are supported: Programmer-specific.
Probing for Programmer Opaque flash chip, 0 kB: Found Programmer flash chip "Opaque flash chip"
(4 kB, Programmer-specific) on nicintel_eeprom.
Found Programmer flash chip "Opaque flash chip" (4 kB, Programmer-specific).
Reading old flash chip contents... done.
Erasing and writing flash chip... Trying erase function 0... 0x000000-0x000fff:W
Erase/write done.
Verifying flash... VERIFIED.
Change-Id: I553f33e5dcb4412d682fc93095b29bcfed11713c
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-on: https://review.coreboot.org/21431
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
