| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This checks that the MTD sysfs node we will use actually exists prior
to calling setup code. Although the setup code will eventually catch
such an error, we need to think about the use case before printing a
possibly irrelevant/confusing error message to the terminal.
This patch makes it so that we only print an error message if the
user specifies a non-existent MTD device. Otherwise, the failure is
considered benign and we only print a debug message prior to bailing
out.
Change-Id: I8dc965eecc68cd305a989016869c688fe1a3921f
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/26500
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
|
|
| |
Hopefully also for other non-XP Windows build environments.
Change-Id: I7f856dc4847c4ca9197b1935b7a9b9071b46c70a
Signed-off-by: Miklós Márton <martonmiklosqdev@gmail.com>
Reviewed-on: https://review.coreboot.org/23865
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
|
|
|
| |
This is the low-voltage version of the AT25DF021. Tested with FT2232H
Mini Module
Change-Id: If4990e6856c8b77567ef4218459cf754b9c6bc57
Signed-off-by: Steffen Mauch <steffen.mauch@gmail.com>
Reviewed-on: https://review.coreboot.org/26856
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Kaby Lake "200 Series" PCHs [1,2] share the register layout of their
Skylake "100 Series" siblings.
[1] Intel® 200 Series (including X299) and Intel® Z370 Series
Chipset Families Platform Controller Hub (PCH)
Datasheet - Volume 1 of 2
Revision 003
Document Number 335192
[2] Intel® 200 Series (including X299) Chipset Family Platform
Controller Hub (PCH)
Datasheet - Volume 2 of 2
Revision 003
Document Number 335193
Change-Id: Ida545d69ec998a5d3ae4dc88e76adbb13952bceb
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/26232
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I1a3d900462ad9e7a3b34575d7c98acc7c2df0445
Signed-off-by: Evan Jensen <evan.p.jensen@gmail.com>
Reviewed-on: https://review.coreboot.org/26779
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the `ich_spi_force` logic with more helpful warnings. These can
be hidden later, in case the necessary switches are detected. Also,
demote some warnings about settings that are the default nowadays (e.g.
SPI configuration lock, inaccessible ME region).
Change-Id: I94a5e7074b845c227e43d76d04dd1a71082a1cef
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/26261
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This imports a series of patches from chromiumos for MTD support.
The patches are squashed to ease review and original Change-Ids have
been removed to avoid confusing Gerrit.
There are a few changes to integrate the code:
- Conflict resolution
- Makefile changes
- Remove file library usage from linux_mtd. We may revisit this and use
it for other Linux interfaces later on.
- Switch to using file stream functions for reads and writes.
This consolidated patch is
Signed-off-by: David Hendricks <dhendricks@fb.com>
The first commit's message is:
Initial MTD support
This adds MTD support to flashrom so that we can read, erase, and
write content on a NOR flash chip via MTD.
BUG=chrome-os-partner:40208
BRANCH=none
TEST=read, write, and erase works on Oak
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/272983
Reviewed-by: Shawn N <shawnn@chromium.org>
This is the 2nd commit message:
linux_mtd: Fix compilation errors
This fixes compilation errors from the initial import patch.
Signed-off-by: David Hendricks <dhendricks@fb.com>
This is the 3rd commit message:
linux_mtd: Suppress message if NOR device not found
This just suppresses a message that might cause confusion for
unsuspecting users.
BUG=none
BRANCH=none
TEST=ran on veyron_mickey, "NOR type device not found" message
no longer appears under normal circumstances.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302145
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This is the 4th commit message:
linux_mtd: Support for NO_ERASE type devices
Some mtd devices have the MTD_NO_ERASE flag set. This means
these devices don't require an erase to write and might not have
implemented an erase function. We should be conservative and skip
erasing altogether, falling back to performing writes over the whole
flash.
BUG=b:35104688
TESTED=Zaius flash is now written correctly for the 0xff regions.
Signed-off-by: William A. Kennington III <wak@google.com>
Reviewed-on: https://chromium-review.googlesource.com/472128
Commit-Ready: William Kennington <wak@google.com>
Tested-by: William Kennington <wak@google.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
This is the 5th commit message:
linux_mtd: do reads in eraseblock-sized chunks
It's probably not the best idea to try to do an 8MB read in one syscall.
Theoretically, this should work; but MTD just relies on the SPI driver
to deliver the whole read in one transfer, and many SPI drivers haven't
been tested well with large transfer sizes.
I'd consider this a workaround, but it's still good to have IMO.
BUG=chrome-os-partner:53215
TEST=boot kevin; `flashrom --read ...`
TEST=check for performance regression on oak
BRANCH=none
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/344006
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This is the 6th commit message:
linux_mtd: make read/write loop chunks consistent, and documented
Theoretically, there should be no maximum size for the read() and
write() syscalls on an MTD (well, except for the size of the entire
device). But practical concerns (i.e., bugs) have meant we don't quite
do this.
For reads:
Bug https://b/35573113 shows that some SPI-based MTD drivers don't yet
handle very large transactions. So we artificially limit this to
block-sized chunks.
For writes:
It's not clear there is a hard limit. Some drivers will already split
large writes into smaller chunks automatically. Others don't do any
splitting. At any rate, using *small* chunks can actually be a problem
for some devices (b:35104688), as they get worse performance (doing an
internal read/modify/write). This could be fixed in other ways by
advertizing their true "write chunk size" to user space somehow, but
this isn't so easy.
As a simpler fix, we can just increase the loop increment to match the
read loop. Per David, the original implementation (looping over page
chunks) was just being paranoid.
So this patch:
* clarifies comments in linux_mtd_read(), to note that the chunking is
somewhat of a hack that ideally can be fixed (with bug reference)
* simplifies the linux_mtd_write() looping to match the structure in
linux_mtd_read(), including dropping several unnecessary seeks, and
correcting the error messages (they referred to "reads" and had the
wrong parameters)
* change linux_mtd_write() to align its chunks to eraseblocks, not page
sizes
Note that the "->page_size" parameter is still somewhat ill-defined, and
only set by the upper layers for "opaque" flash. And it's not actually
used in this driver now. If we could figure out what we really want to
use it for, then we could try to set it appropriately.
BRANCH=none
BUG=b:35104688
TEST=various flashrom tests on Kevin
TEST=Reading and writing to flash works on our zaius machines over mtd
Change-Id: I3d6bb282863a5cf69909e28a1fc752b35f1b9599
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/505409
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: William Kennington <wak@google.com>
Reviewed-on: https://review.coreboot.org/25706
Tested-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
libusb 1.0.22 marked libusb_set_debug as deprecated. For such versions
of libusb, use libusb_set_option instead.
Change-Id: Ib71ebe812316eaf49136979a942a946ef9e4d487
Signed-off-by: Alex James <theracermaster@gmail.com>
Reviewed-on: https://review.coreboot.org/25681
Tested-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
Avoid putting 3.3V on IO pins when pullup=on to avoid damage to 1.8V
chips.
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Change-Id: I9ac4c6b7a0079bb1022f2d70030a6eb29996108f
Reviewed-on: https://review.coreboot.org/23864
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Same story as for 25Q80BW/EW, 25Q40EW has a new ID and the only known
chip with the old ID is the BW variant.
Change-Id: Ib610b0d6f3a5561b2ac3505ef15bdee8b0edae25
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/25462
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch seems to have originally been from
https://patchwork.coreboot.org/patch/4126/ . The most recent version
seems to be in OpenEmbedded (commit 503a572) which added support for
16Mbit and 32Mbit variants.
The OpenEmbedded patch also makes changes to linux_spi.c to add some
debug prints which are omitted in this version.
From the original commit message:
Differences between SST26 and SST25:
1. The WREN instruction must be executed prior to WRSR [Section 5.31].
There is no EWSR.
2. Block protection bits are no longer in the status register. There
is a dedicated 144-bit register [Table 5-6]. The device is
write-protected by default. A Global Block-Protection Unlock
command unlocks the entire memory [Section 4.1].
Change-Id: Ib019bed8ce955049703eb3376c32a83ef607c219
Signed-off-by: Wei Hu <wei@aristanetworks.com>
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Signed-off-by: Stefan Tauner <stefan.tauner@student.tuwien.ac.at>
Reviewed-on: https://review.coreboot.org/25962
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
| |
Change-Id: Ibd77c2a99bd839c01ae7ff058365eda7e30db261
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/25824
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
| |
Change-Id: I7bfc339673cbf5ee2d2ff7564c4db04ca088d0a4
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/25381
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
| |
Change-Id: Ic2d3bb9d8581a0471a8568a130f893b34dddf113
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/25380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
| |
Change-Id: I8899bbe06707fe76256539f90f5b670301228d52
Signed-off-by: Luc Verhaegen <libv@skynet.be>
Reviewed-on: https://review.coreboot.org/25396
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for the latest command spec for Dediprog SF100/SF600
programmers. Since we now have more than two protocols to
deal with the is_new_prot() function is replaced with protocol() which
returns an enum specifying which protocol is supported.
The latest spec (FW >= 7.2.30) updates read and write packets. It's
been tested on an SF600 using firmware 7.2.21 and SF600Plus using FW
7.2.30.
The latest command protocol has a few small but important changes:
- Read packets have two more bytes:
11: B4Addr: address len (3 or 4)
12: Dummy cycle /2
- Write packets have four more bytes:
11, 12: 16 HSBs of page size
13, 14: 16 LSBs of page size
(The spec seems to be mistaken, though, as 11 and 12 are actually
LSBs instead of HSBs)
Change-Id: I1a53c143948ec40d40433621891a2871d8815f2f
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/23836
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The W25Q80BW appears to have been succeeded by the W25Q80EW which has a
different manufacturer ID but is otherwise similar. Consequently, W25Q80.W
no longer matches all chips in this family.
This patch makes the original entry specific to W25Q80BW.
Change-Id: I2980272c2691eb62a68056a7a4c308e9b4810347
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/25100
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
| |
Change-Id: Ia9e8f7f23896f7002401c6b1e616c0dc102198e2
Signed-off-by: Stanislav Sedov <ssedov@fb.com>
Reviewed-on: https://review.coreboot.org/25099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
|
|
|
|
|
|
|
| |
Change-Id: I724a99e2493fcbf71c2fc2d9f6a1ad607c737087
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Reviewed-on: https://review.coreboot.org/25260
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The __MINGW_PRINTF_FORMAT constant has been defined back in 2012
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/77bc5d6103b5fb9f59fbddab1583e69549913312/
However older toolchains are still around and some user reported the
following compilation failure:
flash.h:336:1: error: '__MINGW_PRINTF_FORMAT' is an unrecognized format function type [-Werror=format=]
__attribute__((format(__MINGW_PRINTF_FORMAT, 2, 3)));
Fix this by defining the constant when it isn't already; the change does
not affect other compilers because it's guarded by "#ifdef __MINGW32__".
Setting __MINGW_PRINTF_FORMAT to gnu_printf is exactly what newer MinGW
versions do when __USE_MINGW_ANSI_STDIO is defined, which it is in
flashrom Makefile.
Change-Id: I48de3e4303b9a389c515a8ce230282d9210576fd
Tested-by: Miklos Marton <martonmiklosqdev@gmail.com>
Signed-off-by: Antonio Ospite <ao2@ao2.it>
Reviewed-on: https://review.coreboot.org/25130
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turned out that older kernels use a single buffer of `bufsiz` bytes
for combined input and output data. So we have to account for the read
command + max 4 address bytes.
Change-Id: Ide50db38af1004fde09a70b15938e77f5e1285ac
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Tested-by: Julian von Mendel <git@jinvent.de>
Reviewed-on: https://review.coreboot.org/25149
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julian von Mendel <git@jinvent.de>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
probe/erase/read/write/verify hardware-tests were done.
Change-Id: I0be930ff2258300508398e12fbe5abe10400fea2
Signed-off-by: Julian von Mendel <git@jinvent.de>
Signed-off-by: jvm <git@jinvent.de>
Reviewed-on: https://review.coreboot.org/25047
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't print the error "sh: dmidecode: not found" if dmidecode is not there.
Uses stderr redirection to /dev/null (or NUL on Windows).
Change-Id: I3ded8e1bad14b5e809185a79c4e3a17329b1ecb9
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Stefan Tauner <stefan.tauner@student.tuwien.ac.at>
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/23802
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Coreboot uses the subvendor VID/DID of the Thinkpad X220-Tablet for
all X220 variants. Don't specify a dmidecode string so that it can be
used with coreboot on all X220 variants and on X220-Tablet with vendor
firmare.
Change-Id: Idd667da8209a664469c1a909a549d2b625714a78
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/23225
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
|
|
|
|
|
|
|
| |
This adds another Zetta Device chip, the ZD25D20.
Change-Id: Idf805252647be44e28296a161d2e6160710bcc71
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/23702
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are older versions of git-rev-parse that don't understand the
`--git-path` switch. Also, when the install script was written, git-
rev-parse had a bug when it wasn't run from the root directory. They
fixed the behaviour by now. To simplify things and not have to account
for that too, we just bail out when the script is run from a sub-
directory.
Change-Id: I7ee8d4d54db48f7207fe8abf895c7fbba7685ad2
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22971
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces the Zettadevice manufacturer ID and adds support for the
ZD25D40 chip.
Based on PR20 from Github.
Change-Id: I0400b059ddacdf166d1b77f619becec3a250cece
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/23701
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Newly whitelisted laptops include:
* ThinkPad R400
* ThinkPad T500
* ThinkPad W500
* Libiquity Taurinus X200
Change-Id: I772f8e109c56a5fd40f6b1aff0f592b915669c17
Signed-off-by: Leah Rowe <leah@libreboot.org>
Reviewed-on: https://review.coreboot.org/23781
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for W25P80/16/32 chips. Most notably these chips only
have two erase commands - one for 64KiB "sectors" and one for chip
erase.
Change-Id: Ie09ba8e28fee35c42e17ca05219dc673413de93b
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/23700
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When developing software that has to be flashed to a flash chip to be
executed, it often takes a long time to read the current flash contents
(for flashrom to know what pages to erase and reprogram) each time
when writing the new image. However, when the flash was just reprogrammed,
its current state is known to be the previous image that was flashed
(assuming it was verified).
Thus, it makes sense to provide that image as a file for the flash contents
instead of wasting valuable time read the whole flash each time.
Change-Id: Idf153b6955f37779ae9bfb228a434ed10c304947
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23263
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of just "Probing for ENE KB9012 (EDI), 128 kB:", lets print
some debug info - like it is currently being printed for other chips:
Probing for ENE KB9012 (EDI), 128 kB: edi_chip_probe: hwversion 0xc3, ediid 0x04
Found ENE flash chip "KB9012 (EDI)" (128 kB, SPI) on ch341a_spi.
Change-Id: Id8e62bc9f6785b4bf0be0aaf0f74c8120d77c0d4
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23261
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ENE chips enable EDI by detecting a clock frequency between 1 MHz and 8 MHz.
In many cases, the chip won't be able to both detect the clock signal and
serve the associated request at the same time.
Thus, a dummy read has to be added to ensure that EDI is enabled and
operational starting from the next request.
Change-Id: I69ee71674649cd8ba4fc635f889cb39a1cd204b9
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23260
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ENE Embedded Debug Interface (EDI) is a SPI-based interface for
accessing the memory of ENE embedded controllers.
The ENE KB9012 EC is an embedded controller found on various laptops
such as the Lenovo G505s. It features a 8051 microcontroller and
has 128 KiB of internal storage for program data.
EDI can be accessed on the KB9012 through pins 59-62 (CS-CLK-MOSI-MISO)
when flash direct access is not in use. Some firmwares disable EDI at runtime
so it might be necessary to ground pin 42 to reset the 8051 microcontroller
before accessing the KB9012 via EDI.
The example of flashing KB9012 at Lenovo G505S laptop could be found here:
http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate
Change-Id: Ib8b2eb2feeef5c337d725d15ebf994a299897854
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23259
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most flash chips are erased to ones and programmed to zeros. However, some
other chips, such as the ENE KB9012 internal flash, work the opposite way.
Change-Id: Ia7b0de8568e31f9bf263ba0ad6b051e837477b6b
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23258
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default, we want to probe for SPI25 chips only. Other SPI use cases,
like the ENE/EDI protocol, might use commands that can confuse these
common chips.
Now, flashrom will probe for a chip only if one of these conditions is
true:
1) no chip has been specified AND the chip uses the SPI25 commands
2) this chip has been specified by -c | --chip <chipname>
The CLI can later be extended to probe for a specific class of chips.
Change-Id: I89a53ccaef2791a2ac32904d7ab813da7478a6f0
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/23262
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Kocialkowski <contact@paulk.fr>
|
|
|
|
|
|
|
|
|
|
|
|
| |
I can confirm a successful reading and writing of SST49LF080A (LPC) on a
Wyse Cx0 Thin Client (Phoenix BIOS 1.0G).
Change-Id: I8f48b49ccb760f69d676ec6cbb233e532b12fbe8
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-on: https://review.coreboot.org/23158
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 patch sets the default baud rate for communication between
the host device and the Bus Pirate for hardware versions 3.0
and greater to 2M baud.
It also introduces the ability to manually set the baud rate via
the added 'serialspeed' programmer parameter.
This is done in two parts. Firstly, the requested serial speed is looked up
in a table to determine the appropriate clock divisor and the divisor is sent
to the bus pirate. Then, the system's baud rate for the selected serial port
is set using serial.c's 'serialport_config'. This function's prototype had to
be added to programmer.h.
In testing, using the 2M baud rate was able to significantly decrease
flash times (down from 20+ minutes to less than 2 minutes for an 8MB flash).
Change-Id: I3706f17a94fdf056063f2ad4a5f0a219665cdcbf
Signed-off-by: Shawn Anastasio <shawnanastasio@yahoo.com>
Reviewed-on: https://review.coreboot.org/23057
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/23039
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
| |
I can confirm a successful reading and writing of MX25L8005 (SPI) on a HP t5550
Thin Client (AMI BIOS 786R9 v1.04).
Change-Id: I190253b0c1920747b710ed7155e78191cce139eb
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-on: https://review.coreboot.org/23030
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid attempting to read the SPI bases from the location 0x00000000, all
zeroes mean that the chipset's MMIO area is not enabled.
Change-Id: I5d3a1ba695153e854e0979ae634f8ed97e6b6293
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-on: https://review.coreboot.org/23029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Advertise all 4BA features that are currently supported by flashrom,
plus add a new feature flag for the 4BA fast-read instruction. Also,
list all supported 3BA and 4BA erase-block functions.
As this adds a lot of new code paths that could be taken for these
chips, mark them all as untested again.
Change-Id: I0598496ee7058e3b170684d366f58e4014e0e871
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22423
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of arbitrarily deciding whether to enter 4BA mode in the flash
chip's declaration, advertise that entering 4BA mode is supported and
only enter it if the SPI master supports 4-byte addresses. If not, exit
4BA mode (the chip might be in 4BA mode after reset). If we can't assure
the state of 4BA mode, we bail out to simplify the code (we'd have to
ensure that we don't run any instructions that can usually be switched
to 4BA mode otherwise).
Two new feature flags are introduced:
* FEATURE_4BA_ENTER:
Can enter/exit 4BA mode with instructions 0xb7/0xe9 w/o WREN.
* FEATURE_4BA_ENTER_WREN
Can enter/exit 4BA mode with instructions 0xb7/0xe9 after WREN.
FEATURE_4BA_SUPPORT is dropped, it's completely implicit now.
Also, draw the with/without WREN distinction into the enter/exit
functions to reduce code redundancy.
Change-Id: I877fe817f801fc54bd0ee2ce4e3ead324cbb3673
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22422
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a feature flag SPI_MASTER_4BA to `struct spi_master` that advertises
programmer-side support for 4-byte addresses in generic commands (and
read/write commands if the master uses the default implementations). Set
it for all masters that handle commands address-agnostic.
Don't prefer native 4BA instructions if the master doesn't support them.
Change-Id: Ife66e3fc49b9716f9c99cad957095b528135ec2c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22421
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Get rid of the layering violations around ICH's BBAR. Move all the weird
address handling into (surprise, surprise) `ichspi.c`. Might fix writes
for the `BBAR != 0` case by accident.
Background: Some ICHs have a BBAR (BIOS Base Address Configuration
Register) that, if set, limits the valid address range to [BBAR, 2^24).
Current code lifted addresses for REMS, RES and READ operations by BBAR,
now we do it for all addresses in ichspi. Special care has to be taken
if the BBAR is not aligned by the flash chip's size. In this case, the
lower part of the chip (from BBAR aligned down, up to BBAR) is inacces-
sible (this seems to be the original intend behind BBAR) and has to be
left out in the address offset calculation.
Change-Id: Icbac513c5339e8aff624870252133284ef85ab73
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22396
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
| |
Change-Id: If581e24347e45cbb27002ea99ffd70e334c110cf
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22388
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
| |
Change-Id: I1d04448fd1acbfc37b8e17288f497a4292dfd6d6
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22387
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
| |
Change-Id: Idb7c576cb159630da2268813388b497cb5f46b43
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22386
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Prefer the native 4BA instruction when they are supported. In this
case, override our logic to decide to use a 4BA address.
Change-Id: I2f6817ca198bf923671a7aa67e956e5477d71848
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22385
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow 4-byte addresses for instructions usually used with 3-byte
addresses. Decide in which way the 4th byte will be communicated
based on the state of the chip (i.e. have we enabled 4BA mode)
and a new feature bit for an extended address register. If we
are not in 4BA mode and no extended address register is available
or the write to it fails, bail out.
We cache the state of 4BA mode and the extended address register
in the flashctx.
Change-Id: I644600beaab9a571b97b67f7516abe571d3460c1
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22384
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce spi_prepare_address() and spi_write_cmd() and use them in
nbyte_program, nbyte_read and block-erase procedures. The former
abstracts over the address part of a SPI command to make it exten-
sible for 4-byte adressing. spi_write_cmd() implements a WREN + write
operation with address and optionally up to 256 bytes of data. It
provides a common path to reduce overall redundancy.
Also, reduce the polling delay in spi_block_erase_c4() from 500s to
500ms as the comment suggests.
Change-Id: Ibc1ae48acbfbd427a30bcd64bdc080dc3dc20503
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22383
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|