| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
address (well, it could if the chipset implementation was not broken)
Since exploiting the broken implementation is harder than conforming to the
address restrictions wherever possible, conform to the address restrictions
instead. This patch eliminates a lot of transaction errors people were seeing
on chip probe.
Corresponding to flashrom svn r1016.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- x86/x86_64 (little endian)
- PowerPC (big endian)
- MIPS (big+little endian)
No changes to programmer specific code. This means any drivers with MMIO
access will _not_ suddenly start working on big endian systems, but with
this patch everything is in place to fix them.
Compilation should work on all architectures listed above for all
drivers except nic3com and nicrealtek which require PCI Port IO which is
x86-only for now.
To compile without nic3com and nicrealtek, run
make distclean
make CONFIG_NIC3COM=no CONFIG_NICREALTEK=no
Thanks to Misha Manulis for testing early versions of this patch on
PowerPC (big endian) with the satasii programmer.
Thanks to Segher Boessenkool for design review and for helping out with
compiler tricks and pointing out that we need eieio on PowerPC.
Thanks to Vladimir Serbinenko for compile testing on MIPS (little
endian) and PowerPC (big endian) and for runtime testing on MIPS (little
endian).
Thanks to David Daney for compile testing on MIPS (big endian).
Thanks to Uwe Hermann for compile and runtime testing on x86_64.
DO NOT RUN FLASHROM ON NON-X86 AFTER APPLYING THIS PATCH!
This patch only provides the infrastructure, but does not convert any
drivers, so flashrom will compile, but it won't do the right thing on
non-x86 platforms.
Binary file (standard input) matches
Corresponding to flashrom svn r1013.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Misha Manulis <misha@manulis.com>
|
|
|
|
|
|
|
|
|
|
|
| |
to msg_g*
A few fixes as suggested by Carl-Daniel
Corresponding to flashrom svn r997.
Signed-off-by: Sean Nelson <audiohacked@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
|
|
|
|
|
|
|
| |
Corresponding to flashrom svn r964.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Sean Nelson <audiohacked@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
flash.h
Some of the spi programmer drivers required chipdrivers.h, needs fixing later:
it87spi.c ichspi.c sb600spi.c wbsio_spi.c buspirate_spi.c ft2232spi.c
bitbang_spi.c dediprog.c
Corresponding to flashrom svn r914.
Signed-off-by: Sean Nelson <audiohacked@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a 1-byte ID for most chips
For every given ID out there, probably a dozen incompatible flash chips
match it. We already refuse to identify a chip with RES if that chip responds
to RDID (3 bytes, good match), and with this patch we additionally refuse RES
if the chip responds to REMS (2 bytes, still a good match). This increases
matching accuracy a lot. Besides that, the RDID/REMS response checking has
been cleaned up for better readability.
Corresponding to flashrom svn r899.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Sean Nelson <audiohacked@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Speed up reads by a factor of 4 by switching block size from 4 to 16.
Add support for 4 byte RDID.
Add USB error decoding via usb_strerror.
Corresponding to flashrom svn r879.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reverse engineered from USB logs. I never touched that programmer nor
did I ever see the associated software.
Disabled by default until it is complete. The driver needs to be hooked
up to the SPI core before it will do anything besides init and
diagnostics.
I successfully reverse engineered all commands, but some are still
somewhat magic.
Logs from "flashrom -p dediprog -V" are appreciated.
Probe and read should work, erase/write is expected to explode.
The programmer will set voltage to 0 on exit.
Thanks a lot to Stefan Reinauer and Patrick Georgi for providing USB
logs and for testing the result.
Corresponding to flashrom svn r870.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Convert chips to block_erasers:
ST_M25PE10
ST_M25PE20
ST_M25PE40
ST_M25PE80
ST_M25PE16
PMC_25LV010
PMC_25LV016B
PMC_25LV020
PMC_25LV040
PMC_25LV080B
PMC_25LV512
PMC_39F010
PMC_49FL002
PMC_49FL004
SANYO_LE25FW203A
SPANSION_S25FL016A
Added spi_block_erase_d7 for PMC chips.
Corresponding to flashrom svn r867.
Signed-off-by: Sean Nelson <audiohacked@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
|
|
|
|
|
|
|
|
|
|
| |
Some mingw declares a global identifier "byte", causing -Werror -Wshadow
to break compilation. This patch renames all identifiers called "byte".
Corresponding to flashrom svn r861.
Signed-off-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
|
|
|
|
|
|
|
| |
Corresponding to flashrom svn r814.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make various pieces of code conditional on support for internal programming.
Code shared between PCI device programmers and onboard programming is now
conditional as well. It is now possible to build only with dummy support:
make CONFIG_INTERNAL=no CONFIG_NIC3COM=no CONFIG_SATASII=no CONFIG_DRKAISER=no
CONFIG_SERPROG=no CONFIG_FT2232SPI=no This allows building for a specific use
case only, and it also facilitates porting to a new architecture because it
is possible to focus on highlevel code only. Note: Either internal or dummy
programmer needs to be compiled in due to the current behaviour of always
picking a default programmer if -p is not specified. Picking an arbitrary
external programmer as default wouldn't make sense. Build and runtime tested
in all 1024 possible build combinations. The only failures are by design
as mentioned above.
Corresponding to flashrom svn r797.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Sean Nelson <audiohacked@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example usage:
flashrom -p buspiratespi:spispeed=2.6MHz,dev=/dev/foo
flashrom -p buspiratespi:dev=/dev/foo,spispeed=2.6M
Refactor programmer option parsing (this allows cleanups in other
programmers as well).
Increase SPI read size from 8 to 12 bytes (current single-transaction
limit of the Bus Pirate raw SPI protocol).
Add Bus Pirate to the list of programmers supporting 4 byte RDID.
Add Bus Pirate syntax to the man page.
Tested-by: Sean Nelson <audiohacked@gmail.com>
Corresponding to flashrom svn r776.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Sean Nelson <audiohacked@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code should work on Linux/*BSD/MacOSX and relies on the serial code
implementation in serial.c. Support for additional platforms (Windows)
will have to be added to serial.c for this to work. For tests without a
Bus Pirate (or with non-functional serial code) it is possible to
#define FAKE_COMMUNICATION in buspirate_spi.c.
Thanks to Sean Nelson for the SPI mode settings code. I tweaked it a bit
to make configuration from a commandline easier should anybody want that
feature.
Tested-by: Sean Nelson <audiohacked@gmail.com>
Corresponding to flashrom svn r772.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Sean Nelson <audiohacked@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
list, flashrom will claim that no chip is there
Handle these cases gracefully. flashrom will ignore generic matches if a
specific chip was found, so this will have no impact on supported chips,
but help a lot for a first quick analysis by the user or developer. The only
drawback is that unknown chips may be recognized multiple times until they
are added to flashchips.[ch].
Corresponding to flashrom svn r767.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Marc Jones <marcj303@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
for easier debugging
Vincent wrote: This patch provided help to debug the partial write on ICH
in descriptor mode.
Corresponding to flashrom svn r764.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Vincent S. Cojot <openlook@cojot.name>
|
|
|
|
|
|
|
| |
Corresponding to flashrom svn r739.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
but still yields correct results
With the multicommand infrastructure I introduced in r645, it became possible
to integrate ICH SPI preopcodes cleanly into the flashrom design. The new
code checks for every opcode in a multicommand array if it is a preopcode.
If yes, it checks if the next opcode is associated with that preopcode and
in that case it simply runs the opcode because the correct preopcode will be
run automatically before the opcode.
Corresponding to flashrom svn r727.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: FENG Yu Ning <fengyuning1984@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example make commandline if you want only internal programmers: make
CONFIG_FT2232SPI=no CONFIG_SERPROG=no CONFIG_NIC3COM=no CONFIG_SATASII=no
CONFIG_DRKAISER=no CONFIG_DUMMY=no Of course, all of the CONFIG_* symbols can
be mixed and matched as needed. CONFIG_FT2232SPI is special because even if it
is enabled, make will check if the headers are available and skip it otherwise.
Corresponding to flashrom svn r724.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functions in struct flashchip
I decided to fill in the info for a few chips to illustrate how this works
both for uniform and non-uniform sector sizes. struct eraseblock{ int size;
/* Eraseblock size */ int count; /* Number of contiguous blocks with that
size */ }; struct eraseblock doesn't correspond with a single erase block,
but with a group of contiguous erase blocks having the same size. Given a
(top boot block) flash chip with the following weird, but real-life structure:
top 16384 8192 8192 32768 65536 65536 65536 65536 65536 65536 65536 bottom we
get the following encoding: {65536,7},{32768,1},{8192,2},{16384,1} Although
the number of blocks is bigger than 4, the number of block groups is only 4.
If you ever add some flash chips with more than 4 contiguous block groups,
the definition will not fit into the 4-member array anymore and gcc will
recognize that and error out. No undetected overflow possible. In that case,
you simply increase array size a bit. For modern flash chips with uniform
erase block size, you only need one array member anyway. Of course data types
will need to be changed if you ever get flash chips with more than 2^30
erase blocks, but even with the lowest known erase granularity of 256 bytes,
these flash chips will have to have a size of a quarter Terabyte. I'm pretty
confident we won't see such big EEPROMs in the near future (or at least not
attached in a way that makes flashrom usable). For SPI chips, we even have
a guaranteed safety factor of 4096 over the maximum SPI chip size (which is
2^24). And if such a big flash chip has uniform erase block size, you could
even split it among the 4 array members. If you change int count to unsigned
int count, the storable size doubles. So with a split and a slight change
of data type, the maximum ROM chip size is 2 Terabytes. Since many chips
have multiple block erase functions where the eraseblock layout depends on
the block erase function, this patch couples the block erase functions with
their eraseblock layouts. struct block_eraser { struct eraseblock{ unsigned
int size; /* Eraseblock size */ unsigned int count; /* Number of contiguous
blocks with that size */ } eraseblocks[NUM_ERASEREGIONS]; int (*block_erase)
(struct flashchip *flash, unsigned int blockaddr, unsigned int blocklen);
} block_erasers[NUM_ERASEFUNCTIONS];
Corresponding to flashrom svn r719.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The __func__ variant is standardized in C99 and recommended to be
used instead of __FUNCTION__ in the gcc info page.
Only _very_ old versions of gcc did not know about __func__, but we've
been using both __func__ and __FUNCTION__ for a long while now, and
nobody complained about this, so all our users seem to use recent
enough compilers.
Corresponding to flashrom svn r711.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
|
| |
We can't remove ft2232_spi.o from unconditional OBJS yet due to our makefile
structure (make features), but this patch adds #ifdefs around all FT2232H code,
so the net effect is the same.
Corresponding to flashrom svn r691.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
include the automatic erase present in other chip drivers
Since the majority is definitely auto-erase, change the remaining
explicit-erase cases to be auto-erase as well.
Corresponding to flashrom svn r673.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Carlos Arnau Perez <cemede@gmail.com>
|
|
|
|
|
|
|
| |
Corresponding to flashrom svn r670.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we only send an opcode and no additional data/address, the SPI controller
will read one byte too few from the chip. Basically, the last byte of the chip
response is discarded and will not end up in the FIFO. It is unclear if the
CS# line is set high too early as well. That hardware bug is undocumented as
of now, but I'm working with AMD to add a detailed description of it to the
errata. Add loads of additional debugging to SB600/SB700 init. Add explanatory
comments for unintuitive code flow. Thanks go to Uwe for testing quite a few
iterations of the patch. Kill the SB600 flash chip status register special
case, which was a somewhat misguided workaround for that hardware erratum.
Note for future added features in the SB600 SPI driver: It may be possible to
read up to 15 bytes of command response with overlapping reads due to the ring
buffer design of the FIFO if the command can be repeated without ill effects.
Same for skipping up to 7 bytes between command and response.
Corresponding to flashrom svn r661.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes visual inspection and grepping a lot harder than necessary.
Remove line breaks where appropriate. Some error messages should end up on
stderr instead of just being displayed in verbose mode. Thanks to Maciej
Pijanka for testing.
Corresponding to flashrom svn r660.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
| |
Corresponding to flashrom svn r658.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This brings the SPI code in line with the generic programmer infrastructure.
This patch is a reworked version of a patch by Jakob Bornecrantz.
Corresponding to flashrom svn r657.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Signed-off-by: Jakob Bornecrantz <wallbraker@gmail.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Jakob Bornecrantz <wallbraker@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
|
|
|
|
|
|
|
|
|
|
| |
Tested it on Epia-m700 worked okay.
Tested-by: Jakob Bornecrantz <wallbraker@gmail.com>
Corresponding to flashrom svn r651.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Jakob Bornecrantz <wallbraker@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Jakob writes:
Tested it on my EPIA-m700 and it worked nice. Also double checked that
one of the changed functions actually ran.
Tested-by: Jakob Bornecrantz <wallbraker@gmail.com>
Corresponding to flashrom svn r650.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Jakob Bornecrantz <wallbraker@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Once the ICH/VIA SPI driver is converted to multicommand, a lot of hacks
can disappear.
Tested-by: Jakob Bornecrantz <wallbraker@gmail.com>
Corresponding to flashrom svn r647.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Jakob Bornecrantz <wallbraker@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some SPI opcodes need to be sent in direct succession after each other
without any chip deselect happening in between. A prominent example is
WREN (Write Enable) directly before PP (Page Program). Intel calls the
first opcode in such a row "preopcode".
Right now, we ignore the direct succession requirement completely and it
works pretty well because most onboard SPI masters have a timing or
heuristics which make the problem disappear.
The FT2232 SPI flasher is different. Since it is an external flasher,
timing is very different to what we can expect from onboard flashers and
this leads to failure at slow speeds.
This patch allows any function to submit multiple SPI commands in a
stream to any flasher. Support in the individual flashers isn't
implemented yet, so there is one generic function which passes the each
command in the stream one-by-one to the command functions of the
selected SPI flash driver.
Tested-by: Jakob Bornecrantz <wallbraker@gmail.com>
Corresponding to flashrom svn r645.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Jakob Bornecrantz <wallbraker@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since block erase functions do not know the block length (it's not
specified in any standard), block erase functions now get an additional
parameter blocklen. This enables flashrom to verify the erase result for
block erase functions at correct boundaries.
Tested by Uwe on SB600.
Corresponding to flashrom svn r630.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
chip from FTDI
FTDI support is autodetected during compilation. Paul writes: There are
certainly possible improvements: The code has hard-coded values for which
interface of the ftdi chip to use (interface B was chosen because libftdi seems
to have trouble with A right now), what clock rate use for the SPI interface
(I've been running at 30Mhz, but the patch sets it to 10Mhz), and possibly
others. I think this means that per-programmer options might be a good idea
at some point. Carl-Daniel writes: There is one additional FIXME comment in
the code, but AFAICS that problem is not solvable with current libftdi.
Corresponding to flashrom svn r598.
Signed-off-by: Paul Fox <pgf@laptop.org>
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
single chip supported by flashrom
That means you can tell flashrom to read exactly bytes 12345-56789 (start
12345, length 44445) and it will not fetch a single byte more. Uwe tested
this on one LPC, one SPI, and one parallel flash board.
Corresponding to flashrom svn r596.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
has a huge chunk of chip and vendor IDs in the middle
Split them out into a separate flashchips.h and adjust #include wherever needed.
Corresponding to flashrom svn r594.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Urja Rannikko <urjaman@gmail.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was partly due to a design problem in the abstraction layer.
There should be exactly two different functions for reading SPI chips:
- memory mapped reads
- SPI command reads.
Each of them should be contained in a separate function, optionally
taking parameters where needed.
This patch solves the problems mentioned above, shortens the code and
makes the code logic a lot more obvious.
Since open-coding the min() function leads to errors, include it in this
patch as well.
Corresponding to flashrom svn r589.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
|
|
|
|
|
| |
Corresponding to flashrom svn r583.
Signed-off-by: Paul Fox <pgf@laptop.org>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
|
|
|
|
|
|
|
|
|
|
| |
the delay on their own if needed
Corresponding to flashrom svn r578.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Urja Rannikko <urjaman@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now, the annotation only differentiates between SPI and non-SPI. Anyone
who knows more about a specific flash chip should feel free to update it.
The existing flashbus variable was abused to denote the SPI controller type.
Use an aptly named variable for that purpose. Once this patch is merged,
the chipset/programmer init functions can set supported flash chip types
and flashrom can automatically select only matching probe/read/erase/write
functions. A side benefit of that will be the elimination of the Winbond
W29EE011 vs. AMIC A49LF040A conflict.
Corresponding to flashrom svn r556.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|
|
|
|
|
|
|
|
|
|
|
| |
Every chip besides SPI and w39v080fa uses id1/id2 as local variable names to
store ID responses from the flash chip. This eases grepping a lot. As a bonus,
it also frees up some names to be used as parameters.
Corresponding to flashrom svn r551.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
|
|
|
|
|
|
|
|
|
| |
Build-tested on 32bit x86.
Corresponding to flashrom svn r521.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
should handle such special opcode failure gracefully on ICH and
Compatible chipsets. This fixes status register writes on almost all
ICH+VIA SPI masters. The fix is almost identical to r484, but this time
it affects the EWSR (Enable Write Status Register) opcode instead of the
WREN (Write Enable) opcode. With the differentiated return codes introduced
in r500, the workaround is more precise this time. The old WREN workaround
was updated as well.
Corresponding to flashrom svn r514.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: FENG Yu Ning <fengyuning1984@gmail.com>
Acked-by: Cristi Magherusan <cristi.magherusan@net.utcluj.ro>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
flasher driver
Does not support reading or writing the fake chip yet. flashrom--programmer
dummy also enables the dummy SPI controller driver. Testing the dummy SPI
driver revealed a RDID debug printing bug in the SPI core. Fix that as well.
Corresponding to flashrom svn r507.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even if we don't tell the user about the areas the block locking bits
correspond to, printing a detailed list of which lock bits are set is a
definite improvement. Sample output: [...] Probing for SST SST25VF032B, 4096
KB: RDID returned bf 25 4a. probe_spi_rdid_generic: id1 0xbf, id2 0x254a Chip
status register is 1c Chip status register: Block Protect Write Disable (BPL)
is not set Chip status register: Auto Address Increment Programming (AAI)
is not set Chip status register: Bit 5 / Block Protect 3 (BP3) is not set Chip
status register: Bit 4 / Block Protect 2 (BP2) is set Chip status register:
Bit 3 / Block Protect 1 (BP1) is set Chip status register: Bit 2 / Block
Protect 0 (BP0) is set Chip status register: Write Enable Latch (WEL) is not
set Chip status register: Write In Progress (WIP/BUSY) is not set Found chip
"SST SST25VF032B" (4096 KB) at physical address 0xffc00000.
Corresponding to flashrom svn r505.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Cristi Magherusan <cristi.magherusan@net.utcluj.ro>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Among others, I have seen the following problems: - The SPI opcode is not
supported by the controller. ICH-style controllers exhibit this if SPI config
is locked down. - The address in in a prohibited area. This can happen on ICH
for any access (BBAR) and for writes in chipset write protected areas. - There
is no SPI controller. Introduce separate error codes for unsupported opcode
and prohibited address. Add the ability to adjust REMS and RES addresses to
the minium supported read address with the help of spi_get_valid_read_addr().
That function needs to call SPI controller specific functions like reading
BBAR on ICH.
Corresponding to flashrom svn r500.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
by default
Change the flashchips entry for SST SST25VF080B to 1-byte writing. Tested-by:
Ali Nadalizadeh.
Corresponding to flashrom svn r486.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AAI mode
Change SPI architecture to handle 1-byte chunk chip writing differently from
256-byte chunk chip writing. Annotate SPI chip write functions with _256
or _1 suffix denoting the number of bytes they write at maximum. The 1-byte
chunk writing is cut-n-pasted to different SPI drivers right now. A later
patch can move them to the generic spi_chip_write_1.
Corresponding to flashrom svn r485.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
|
|
|
|
|
|
|
|
|
|
|
|
| |
should handle such special opcode failure gracefully on ICH and
Compatible chipsets. This fixes chip erase on almost all ICH+VIA SPI masters.
Thanks to Ali Nadalizadeh for helping track down this bug!
Corresponding to flashrom svn r484.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Using a 4-bit index into an array with 8 elements leads to
out-of-bounds accesses. Use proper bit masking to fix this.
- Factor out common SST25 status register printing.
- Use the common SST25 status register printing for SST25VF080B.
Corresponding to flashrom svn r468.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Peter Stuge <peter@stuge.se>
|