The Raiden debug external spi programmer need only depend
on libusb and is unrelated to libpci. Correct meson and gnu make
builds where meson had configuration in the incorrect section
and gnu make artifactually disabled the build on Windows/MinGW
which doesn't have libpci.
BUG=none
TEST=still continues to build.
Change-Id: I2d6a8c33a2228abf006a9b278bcb7133765c7074
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/51930
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This matches the build flags that are correctly explicitly defined in
meson.build where-as the Makefile is randomly picking up whatever the
system toolchain happens to default to.
Fix dmi.c while we are here to avoid a re-define of _GNU_SOURCE.
BUG=none
TEST=`make` with both gcc and clang.
Change-Id: I4f973927fc018510a3beaa6c4fa2f356c77c7a6e
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/47908
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Allows to force-disable the use of clock_gettime() at build time,
falling back to busy-looping for udelay. This is useful when building
for systems which are known to lie about the resolution of
clock_gettime(), such as Linux guests running under the Muen Separation
Kernel.
Change-Id: I645a5d3f29ffdbd24a58127ab73d7d8755304f45
Signed-off-by: Martin Lucina <martin@lucina.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48796
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds support for Spansion 25Fxxxxx chips. These chips
require their own probing logic because the first 6 bytes
returned by RDID must be examined to identify the chip.
New erase functions are required as the chips support multiple
sector layouts, and the default layout must be changed to be
able to erase the entire flash.
Adapted from cros flashrom at
`9c4c9a56b6a0370b383df9c75d71b3bd469e672d`.
BUG=b:153800073
TEST=builds
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Change-Id: I2d23f9c36ce8b2959807fbeee7f60e02444e3763
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46140
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Unfortantly raiden_debug was upstreamed with a misnaming
of the CONFIG_ make param that introduces unnecessary divergence.
Rename to 'CONFIG_RAIDEN_DEBUG_SPI' as-is downstream.
Change-Id: I07c03647c329286bb223e4dae4665704e508db2c
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48105
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Both requires PCI port I/O and hence works only on x86.
TEST=builds on Ubuntu for Raspberry Pi
Signed-off-by: Victor Ding <victording@google.com>
Change-Id: I69e1fbd87819b0b6370f31e9ee4c474500fb3759
Reviewed-on: https://review.coreboot.org/c/flashrom/+/47394
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
LSPCON and MST do not depend on libusb.
Signed-off-by: Shiyu Sun <sshiyu@chromium.org>
Change-Id: If6db3a318aca349fc1ccd343d3d6d47b809eac8e
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46870
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Both depend on functions from chipset_enable.c and board_enable.c, which
require libpci.
Signed-off-by: Victor Ding <victording@google.com>
Change-Id: I9505d7f18f4781a264e29e9667b717c061ba33b8
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46812
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Both use INB/OUTB and hence should be marked as NEED_RAW_ACCESS in the
makefile.
Signed-off-by: Victor Ding <victording@google.com>
Change-Id: I6fafd9f59d06f60e9491e3e059c1205d48d8232e
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46811
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The following just lays out the structure for write protect
manipulation of SPI flash chips in Flashrom. We later follow
up with adding support for each manufacturer group.
BUG=b:153800563
BRANCH=none
TEST=builds
Change-Id: Id93b5a1cb2da476fa8a7dde41d7b963024117474
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/40325
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
Since lspcon talks over i2c I doubt libusb is a build
requirement, remove it.
Change-Id: Ic4d71c10d2d8c0c881aa5732daed35c20d905a5e
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/41020
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
This adds support for the Parade lspcon usb-c to HDMI protocol
translater part that is i2c-controlled. The support allows the
host to reach the SPI ROM that hangs off the part where it
stores its firmware.
Usage is as follows:
flashrom -p lspcon_i2c_spi:bus=X
where X is the bus number.
BUG=b:148746232
BRANCH=none
TEST=tested with following commands, read/write/erase works good.
flashrom -p lspcon_i2c_spi:bus=7 -r /tmp/foo;
flashrom -p lspcon_i2c_spi:bus=7 -E;
flashrom -p lspcon_i2c_spi:bus=7 -w /tmp/foo;
Change-Id: I039e683252cfaf1ffef8694a3e8081b1b6b944f7
Signed-off-by: Shiyu Sun <sshiyu@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/39687
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
See https://www.kernel.org/doc/Documentation/i2c/ for details.
This creates common interface for I2C access functions, and adds
implementation for linux I2C functions.
BUG=b:148746232
BRANCH=none
TEST=build success
Signed-off-by: Shiyu Sun <sshiyu@chromium.org>
Change-Id: Ie0487824dfb71970bede17f617dbbb30ddf78c12
Reviewed-on: https://review.coreboot.org/c/flashrom/+/39686
Tested-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Turns out CONFIG_RAIDEN was missing in the LIBUSB1
as no overrides. Credit to HAOUAS Elyes for spotting this.
Change-Id: I7dd26665a0133175949c11717837e9de68a1bf71
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/39896
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
These are helpful usb device accessors and helpers that
are later used for the so-called Raiden debugger programmer.
BUG=b:143389556
BRANCH=none
TEST=builds
Change-Id: Ic928220fc919fe4958c8150e61e11470dac88f13
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/38936
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Enable all -Wextra warnings but -Wunused-parameter. Nobody seems to
miss warnings about unused parameters and we have a lot unavoidable
occurrences in flashrom because of common interfaces.
Change-Id: Id2ece264c2d483e34019985dd3a7631c4889abe6
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/30411
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
Automotive 2 Mbit (256KiB) serial SPI bus EEPROM
PREW tested successfully with use of ch341a programmer
on Linux host 5.2.0-1-MANJARO x86_64
Signed-off-by: Konstantin Grudnev <grudnevkv@gmail.com>
Change-Id: Ic29cd9051c7eac4822d620c299834134f987f01b
Reviewed-on: https://review.coreboot.org/c/flashrom/+/34496
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
When compiling, this warning gives string literals the type const char[]
to help catch accidental modification (which is undefined behaviour).
There currently aren't any instances of this in flashrom, so let's
enable this warning to keep it that way. This requires adding const
qualifiers to the declarations of several variables that work with
string literals.
Change-Id: I62d9bc194938a0c9a0e4cdff7ced8ea2e14cc1bc
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/34577
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Flashmap, or simply fmap, is a binary data format for describing
region offsets, sizes, and certain attributes and is widely used by
coreboot. This patch adds support for the fmap data format version 1.1
and adds --fmap and --fmap-file arguments.
Using --fmap will make flashrom to search the ROM content for fmap
data. Using --fmap-file will make flashrom search a supplied file
for fmap data.
An example of how to update the COREBOOT region of a ROM:
flashrom -p programmer --fmap -w coreboot.rom -i COREBOOT
flashrom -p programmer --fmap-file coreboot.rom -w coreboot.rom -i COREBOOT
The fmap functions are mostly copied from cbfstool.
Currently it is made mutually exclusive with other layout options until
we are more clever about this input.
Change-Id: I0e7fad38ed79a84d41358e1f175c36d255786c12
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/23203
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Currently there is a TODO-like comment in the dediprog driver: "Might be
useful for other USB devices as well". Act on this comment by collecting
all the device discovery code for libusb1 devices into a separate file.
Change-Id: Idfcc79371241c2c1dea97faf5e532aa971546a79
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-on: https://review.coreboot.org/27443
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The 96Boards Developerbox (a.k.a. Synquacer E-series) provides a CP2102
debug UART with its GPIO pins hooked up to the SPI NOR FLASH. The
circuit is intended to provide emergency recovery functions without
requiring any additional tools (such as a JTAG or SPI programmer). This
was expected to be very slow (and it is) but CP2102 is much cheaper than
a full dual channel USB comms chip.
Read performance is roughly on par with a 2400 baud modem (between 60
and 70 minutes per megabyte if you prefer) and write performance is 50%
slower still. The full recovery process, with backup and verification of
4MB data written takes between 14 and 15 hours. Thus it is only really
practical as an emergency recovery tool, firmware developers will need
to use an alternative programmer.
Change-Id: I2547a96c1a2259ad0d52cd4b6ef42261b37cccf3
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/26948
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This is driver that supports the Lattice iCE40 evaluation kits. On the
board is a SPI flash memory chip labeled ST 25P10VP.
Tested to work read/write/erase with "-p digilent_spi -c M25P10" or
with a patch that resets the part beforehands (in which case it gets
detected as a M25P10-A and is way faster due to paged writes).
Change-Id: I7ffcd9a2db4395816f0e8b6ce6c3b0d8e930c9e6
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-on: https://review.coreboot.org/23338
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 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>
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>
internal_init() explicitly fails on everything but x86 and mipsel.
Instead, we can just never build the internal programmer on other
architectures and drop a lot of #if boilerplate.
Change-Id: I672ddab0415df3baa49ff39a1c9db1b41d8143a4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22671
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>
Add an `endiantest.c` similar to `archtest.c` to provide the endianness
inside the Makefile. The __FLASHROM_(LITTLE|BIG)_ENDIAN__ definitions
had to move from `hwaccess.h` into `platform.h`, therefor. This will
be used to decide whether to build the internal programmer in a follow-
up.
Change-Id: I55dcf5a88da48f885cda9ad89ab87395d895a891
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22670
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
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>
The function to do this is contained in custom_baud.c because
of broken include stuff.
Change-Id: I2a20f9182cb85e7bce5d6654a2caf20e6202b195
Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Reviewed-on: https://review.coreboot.org/20224
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If flash chip is switched to 4-bytes addressing mode then all
read/erase/program instructions will be switched from 3-bytes mode
to 4-bytes mode. Then well known instructions like 03h (Read),
02h (Program) and 20h,52h,D8h (Erase) will become one byte longer
and accept 4-bytes address instead of 3-bytes.
This patch provides support for well known instructions in 4-bytes
addressing mode. Also here is the code to enter 4-bytes addressing
mode by execute the instruction B7h (Enter 4-bytes mode).
Patched files
-------------
chipdrivers.h
+ added functions declarations for spi4ba.c
flash.h
+ feature definitions added
Makefile
+ added spi4ba.c
Added files
-----------
spi4ba.h
+ definitions for 4-bytes addressing JEDEC commands
+ functions declarations from spi4ba.c (same as in chipdrivers.h, just to see)
spi4ba.c
+ functions for enter 4-bytes addressing mode
+ functions for read/write/erase in 4-bytes addressing mode
Change-Id: Ie72e2a89cd75fb4d09f48e81c4c1d927c317b7a7
Signed-off-by: Boris Baykov <dev@borisbaykov.com>, Russia, Jan 2014
[clg: ported from
https://www.flashrom.org/pipermail/flashrom/2015-January/013199.html ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-on: https://review.coreboot.org/20513
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
- 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>
