We should follow data sheet timing, even if chips have been tested to answer
faster in the field.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3387 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Run time is increased a few 100ms but this is needed for reliability.
I consider this trivial.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3373 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
detected by JEDEC probe routines all have vendor IDs with correct
parity. Use a parity check as additional hint whether a vendor ID makes
sense.
Note: Device IDs have no parity requirements whatsoever.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3308 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
The continuation ID code does not go further than checking for IDs of
the type 0x7fXX, but does this for vendor and product ID. The current
published JEDEC spec has a list where the largest vendor ID is 7 bytes
long, but all leading bytes are 0x7f. The list will grow in the future,
and using a 64bit variable will not be enough anymore.
Besides that, it seems that the location of the ID byte after the first
continuation ID byte is very vendor specific, so we may have to revisit
that code some time in the future.
(Suggestion for a new encoding:
Use a two-byte data type for the ID, the lower byte contains the only
non-0x7f byte, the upper byte contains the number of 0x7f bytes used as
prefix, which is the bank number minus 1 the vendor ID appears in.)
Add support for EON EN29F002AT.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Corey Osgood <corey.osgood@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3030 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
a delay of 10 us after entering ID mode and this was insufficient for
the 29C020. The data sheet claims we have to wait 10 ms, but tests have
shown that 20 us suffice. Allow for variations in chip delays with a
factor of 2 safety margin.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@2962 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
No changes in content of the files.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@2751 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Give decent names to virt_addr and virt_addr_2
* add some comments
* move virtual addresses to the end of the struct,
so they dont mess up the initializer.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@2689 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
indent -npro -kr -i8 -ts8 -sob -l80 -ss -ncs *.[ch]
Some minor fixups were required, and maybe a few more cosmetic
changeѕ are needed.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@2643 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Fixed write_page_write_jedec() in jedec.c. Added a check-reprogram loop
in the same function, to come around the high page write failure rate on
some boards.
This patch includes the changes suggested by Ron to simplify the control
flow.
It also includes trivial changes by me to make flashrom build on newer
systems (libpci needs libz now). I also made a small type case compile fix
and proper return code handling in one or two places.
Signed-off-by: Giampiero Giancipoli <gianci@email.it>
Signed-off-by: Ronald G Minnich <rminnich@gmail.com>
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@2505 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Peter Stuge