This is not just for fun. We hit a real bug on BSD with the outl macros.
The macro variable tmp collided with the tmp from outer scope.
second revision, now also taking care of inb/inw/inl. While that shadowing
did not introduce bugs (yet), of course it breaks the build on BSD when
-Wshadow is enabled.
Corresponding to flashrom svn r860.
Signed-off-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
Acked-by: Luc Verhaegen <libv@skynet.be>
The msg_* macros won't compile as is if you use more than one parameter
(i.e.
have a format string and a variable). There are two alternative styles:
GNU or C99 variadic macros. While C99 has limitations compared to the
GNU extensions, these limitations do not affect our macros, so I decided
to go with the standard way.
I adjusted whitespace a bit to have aligned values (cosmetic change).
Corresponding to flashrom svn r841.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Sean Nelson <audiohacked@gmail.com>
This allows us to have one common probe_jedec function instead of half a
dozen wrappers. The trick here is to have FEATURE_ADDR_FULL==0 and thus
default to unmasked addresses. That way, we only have to annotate chips
which need small address masks.
Corresponding to flashrom svn r840.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Sean Nelson <audiohacked@gmail.com>
It also changes so -VV will spit out highly verbose messages for
debugging. This is a minimal patch to lessen impact a later patch will
convert current printf messages to the new interface.
Corresponding to flashrom svn r835.
Signed-off-by: Sean Nelson <audiohacked@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
And rename them accordingly. For now, main() just calls cli_classic(),
but alternative frontends can be switched in main().
Annotate remaining help texts with CLI dependency inside flashrom.c with
a FIXME comment.
Now people can go and create different frontends and be happy. Please
note that any other frontend will have to sort of duplicate the probing
code in cli_classic.c. Refactoring that part of the code is possible,
but not easy because we still want to print instructive help messages
for users.
Corresponding to flashrom svn r833.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Sean Nelson <audiohacked@gmail.com>
Corresponding to flashrom svn r832.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
- replace the hand written serial input flush routine with the termios one.
- serialport_discard_read isn't necessary anymore - it just wrapped
sp_flush_incoming with no extra value.
- serialport_read and serialport_write would misbehave if read or write
didn't process everything in one go.
- sp_flush_incoming should be #define'd out for FAKE_COMMUNICATION like
serialport_discard_read was
Corresponding to flashrom svn r831.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Sean Nelson <audiohacked@gmail.com>
While at it, also rename a few functions to make it obvious
that they are generic and not specific to the Bus Pirate.
Corresponding to flashrom svn r830.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
Some programmers (most notably FT2232SPI) use fallback_* and noop_*,
but those functions lived inside internal.c and were unavailable if no
PCI-based programmers were compiled in.
Move those functions to the new file programmer.c. Thanks to Patrick
Georgi for finding this.
Corresponding to flashrom svn r829.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
The patch converts jedec functions into mask-based generics which can
be used for many chip provided the only changes are the addresses are
converted from 0x5555/0x2AAA to 0x555/0x2AA or similar.
The patch mostly changes jedec.c, but a few other files are changed
because they use the jedec functions within their own functions.
The patch also adds a copyright line to flashchips.c because of my
recent work in converting AMD and Atmel chips to use struct erase_block.
Corresponding to flashrom svn r828.
Signed-off-by: Sean Nelson <audiohacked@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Move that function to udelay.c and compile internal.c only if really
needed. physmap.c is only needed if the programmer is internal or a PCI
card. Make its compilation conditional.
Corresponding to flashrom svn r822.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Idwer Vollering <vidwer@gmail.com>
Add a generic programmer list output function to be used by alternative
frontends. The interface between main() and doit is a hack and should
get a clean design, but for now it serves the purpose of shortening
main() by 120 lines. The rest of main() needs to be refactored a bit
more before moving main() away.
Corresponding to flashrom svn r821.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Sean Nelson <audiohacked@gmail.com>
We could run it after chipset enable, but it definitely has to happen
before board enable because the board enable usually accesses the
SuperI/O. With this patch, it is possible to add a struct superio to the
board enable table for more accurate matching in case subsystem IDs are
ambiguous. This patch focuses on the generic infrastructure aspect and
on support for IT8712F/IT8716F.
Thanks go to Adrian Glaubitz and Ward Vandewege for testing.
Corresponding to flashrom svn r813.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Luc Verhaegen <libv@skynet.be>
Acked-by: Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
This patch is only the first step, but it hopefully will make working
with the code and especially porting to new platforms easier.
Subsequent patches should move #includes for the newly created files
hwaccess.h and chipdrivers.h from flash.h to the files which need them.
Programmers should live in a separate header file as well.
Tested-by: Idwer Vollering <vidwer@gmail.com>
Corresponding to flashrom svn r799.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Sean Nelson <audiohacked@gmail.com>
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>
The deleted function in en29f002a.c is reintroduced as
write_by_byte_jedec in jedec.c as it contains no chip-specific
instructions. It is not yet used in other chip drivers, as key addresses
(0x2AAA/0x5555) are often specified with less bits. After crosschecking
datasheets, most of the fixmes can probably be resolved as indicated in
them, causing significant code reduction.
The common JEDEC code for bytewise programming does not program 0xFF
at all. The chips that had a dedicated bytewise flash function which
has been changed to write_jedec_1 thus changed flashing behaviour
and the "write" test flag has been removed. This applies to: AMD
Am29F002BB/Am29F002NBB AMD Am29F002BT/Am29F002NBT (TEST_OK_PREW before)
AMIC A29002B AMIC A29002T (TEST_OK_PREW before) EON EN29F002(A)(N)B EON
EN29F002(A)(N)T (TEST_OK_PREW before) Macronix MX29F001B (TEST_OK_PREW
before) Macronix MX29F001T (TEST_OK_PREW before) Macronix MX29F002B
Macronix MX29F002T (TEST_OK_PREW before) Macronix MX29LV040
Similar analysis should be performed for the read id stuff.
Corresponding to flashrom svn r785.
Signed-off-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
Acked-by: Sean Nelson <audiohacked@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
This patch removes the extremely dangerous unprotect_jedec function
which is not used at all within flashrom code, and renames the
misleadingly named protect_jedec function to start_program_jedec.
Calls to protect_jedec after flashing are removed, because a) on LPC
chips, the command sent by protoct_jedec is not even in the datasheet
and b) on parallel chips, the block write command issued before already
contained the software protection sequence, so software protection is
definitely enabled.
This patch also removes two clones of protect_jedec
Background: JEDEC Software Data Protection started as an optional
feature, which was disabled on the first single-voltage-flash chips.
The software data protection is the need to prefix a write with a magic
"write enable" command, while without write protection every write
access into the chip's address space modifies flash content. This magic
write enable command also tells the flash chip that the programmer
obviously support sending write-enable commands and turns off the "any
write modifies flash content" mode. There also exist a two-command (6
writes) sequence that disables Software Data Protection completey, which
should only ever be used to prepare updating with a device that can't
handle software data protection.
Corresponding to flashrom svn r783.
Signed-off-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
Acked-by: Sean Nelson <audiohacked@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
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>
This is the first step in enabling platform independent serprog and it
also allows other drivers to use serial port functionality without
requiring serprog.
Pure code move, no code changed.
Corresponding to flashrom svn r771.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
Serprog already has such functionality, so it makes sense to share that.
TODO: Factor out serial communication into a separate file, have that
code be available even if serprog is not selected and make it portable
(it is very Linux-centric right now).
Corresponding to flashrom svn r768.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
To prepare for libflashrom I wanted to make the main loop more readable and more correct and factor out stuff which can be useful in libflashrom.
- Factor out printing of supported devices to print.c.
- Adjust name of wiki printing function to fit the pattern.
- Abort if the user specified --verify and --noverify at the same time.
- Check for extra parameters which don't fit commandline syntax.
Corresponding to flashrom svn r766.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
The two existing SiS chipset enables (compared to the 28 in this patch)
were refactored, and one of them was fixed.
A function to match PCI vendor/class combinations was added to generic
code.
Tested on the "Elitegroup K7S5A". Results are somewhat unexpected (some
PCI settings seem to be inaccessible, but it still works).
This is not based on any docs, but rather on detailed analysis
of existing opensource code for some of the chipsets.
Thanks to for Adrian Glaubitz testing.
Corresponding to flashrom svn r759.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
The rationale is to warn users when they, for example, try to flash
a 512KB parallel flash chip but their chipset only supports 256KB,
or they try to flash 512KB and the chipset _does_ theoretically
support 512KB but their special board doesn't wire all address lines
and thus supports only 256 KB ROM chips at maximum.
This has cost Uwe hours of debugging on some board already, until he
figured out what was going on. We should try warn our users where
possible about this.
The chipset and the chip may have more than one bus in common (e.g.
SB600 and Pm49* can both speak LPC+FWH) and on SB600/SB7x0/SB8x0 there
are different limits for LPC and FWH. The only way to tell the user
about the exact circumstances is to spew error messages per bus.
The code will issue a warning during probe (which does fail for some
chips if the size is too big) and abort before the first real
read/write/erase action. If no action is specified, the warning is
printed anyway.
That way, a user can find out why probe might not have worked, and will
be stopped before he/she gets incorrect results.
Add a bitcount function to the infrastructure.
Corresponding to flashrom svn r755.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
The new option is '-p gfxnvidia', rest of the interface is as usual.
I tested a successful identify and read on a "RIVA TNT2 Model 64/Model 64 Pro"
card for now, erase and write did NOT work properly so far!
Please do not attempt to write/erase cards yet, unless you can recover!
In addition to the NVIDIA handling code it was required to call
programmer_shutdown() in a lot more places, otherwise the graphics card
will be disabled in the init function, but never enabled again as the
shutdown function is not called.
The shutdown handling may be changed to use atexit() later.
Corresponding to flashrom svn r737.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Luc Verhaegen <libv@skynet.be>
If you want support for a particular piece of hardware, just fill in
a few functions in spi_bitbang_master_table. That's it.
On top of this, the RayeR SPI flasher should be supportable in ~20 LOC.
Tested, trace looks OK.
Corresponding to flashrom svn r736.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
Annotate SST49LF004B quirks for TBL#.
Add TEST_OK_PRW which is useful when a PREW chip gets a new erase
routine.
Change a few erase function prototypes to use unsigned int instead of
int.
Corresponding to flashrom svn r731.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Luc Verhaegen <libv@skynet.be>
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>
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 vendor sold different designs under that name, the patch works with
the one that has an Actel FPGA as PCI-to-Flash bridge.
The Flash chip is a "Macronix MX29F001B" (128 KB, parallel) soldered
directly to the PCB.
Flash operations (PROBE, READ, ERASE, WRITE) work as expected.
Corresponding to flashrom svn r712.
Signed-off-by: TURBO J <turboj@gmx.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
Flashrom has the ability to use layout files with romentries, but
this feature was not adapted to the programmer infrastructure and had
undefined behaviour for flasher!=internal. The romentry handling had an
off-by-one error which caused all copies to end up one byte short. Fix
these issues.
Corresponding to flashrom svn r694.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
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>
So far, AMD Geode LX is the only user of this infrastructure. It needs
/dev/cpu0 from ports/sysutils on FreeBSD during runtime on Geode LX.
Corresponding to flashrom svn r690.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Idwer Vollering <vidwer@gmail.com>
Acked-by: <putlinuxonit@gmail.com>
If CONFIG_SERPROG is not set, no stubs and no data of serprog will
remain.
Side benefit: This kills a few dozen lines of code.
r678, r679 and r680 made this possible. Once "Only list available
programers in usage()" is committed, even the usage message will be
adjusted automatically.
Corresponding to flashrom svn r681.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
Use programmer.name to match the --programmer parameter instead of
hardcoding the name of every single programmer in main().
-p dummyfoo won't be mistaken for -p dummy anymore.
Corresponding to flashrom svn r680.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
This allows us to reduce #ifdef clauses a lot if we compile out some
programmers completely.
Corresponding to flashrom svn r679.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
FT2232 and IT87 programmers used functions of the dummy programmer
instead of fallback functions.
The dummy programmer is a "real" programmer with possible side effects
and its functions should not be abused by other programmers. Make
FT2232 and IT87 use official fallback functions instead. Create
fallback_shutdown(). Create fallback_chip_writeb(). Convert the
programmer #defines to an enum.
Corresponding to flashrom svn r678.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
Some SPI chip drivers and the generic 1-byte SPI chip write functions
didn't 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>
Flashrom tries to match these with board enable entries in its database.
If no such board enable entry exists because the board doesn't need one,
flashrom complains. Silence that complaint.
Corresponding to flashrom svn r668.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Slightly updated and
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 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-by: Jakob Bornecrantz <wallbraker@gmail.com>
Corresponding to flashrom svn r651.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Tested it on Epia-m700 worked okay.
Acked-by: Jakob Bornecrantz <wallbraker@gmail.com>
If the parameter is set, the IT87* SPI driver will set the I/O base
port of the IT87* SPI controller interface to the port specified in the
parameter. Usage: flashrom -p it87spi=port=0x820
Corresponding to flashrom svn r646.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
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>
