Auf 14.12.2010 05:29, Steven Zakulec schrieb:
On Mon, Dec 13, 2010 at 6:18 PM, Richard A. Smith richard@laptop.org wrote:
On 12/13/2010 03:20 AM, Carl-Daniel Hailfinger wrote:
- Check _every_ SPI chip if it can handle the FAST READ (0x0b) command
and mark the ones which can't, because the Dediprog driver uses FAST READ by default, and all other SPI programmer drivers use the standard READ (0x03) command, so a read test for any given chip with the Dediprog is useless for all other programmer drivers...
What about reversing this? Assume all chips don't support fast read and then mark the ones that do. Then people who are responsible for trying to use the Dediprog with a particular chip would be the ones to go through and change the setting for chips they are using.
That's a good idea. However, it would be a major usability benefit if we can get a sizable number of chips annotated before we enable Dediprog support by default.
A list of supported chips for the SF100 is available at the dediprog site:
http://www.dediprog.com/device_support.php
Assuming that the dediprog really does fast read then going through that list setting .fast_read=1 for each chip listed is a whole lot less work than grovelling through the data sheet for every chip that flashrom supports.
I worry that if you add a depends of full dediprog support on a complete chip audit then it won't happen for a long time. Someone could run through the list of chips the Dediprog supports in probably an hour or so.
As one of the people mentioned in carldani's email, I would be interested in helping. I've taken a brief look at http://www.dediprog.com/download.php?106_upload_file_5 (which is a PDF download, that has a list of chips in it). I took a look at the datasheet for the AT25512, and I can't see any way to tell that this chip supports FAST_READ.
That datasheet is an excellent example because it is pretty difficult to read compared to other SPI flash datasheets.
It's probably because of my lack of datasheet reading experience- so if someone can clue me in to what indicates that (or any other datasheet) offers the FAST_READ capability, I would be greatly appreciative.
I'll explain the AT25512 datasheet first.
Look at http://www.atmel.com/dyn/resources/prod_documents/doc5165.pdf Table 3-1. Instruction Set for the AT25512
READ 0000X011 Read Data from Memory Array WRITE 0000X010 Write Data to Memory Array
This is binary notation, and the X denotes a "don't care" bit, so it can be either 1 or 0. If you translate it to hex, you get this: READ 0x03 or 0x0b Read Data from Memory Array WRITE 0x02 or 0x0a Write Data to Memory Array
At first glance, that looks like READ (0x03) and FAST READ (0x0b) are supported, but there's a catch: Figure 4-6. READ Timing clearly shows that both 0x03 and 0x0b have the following sequence: 1 byte instruction out, 2 byte address out, 1-infinity data bytes in
And here's how you can check if a flash chip supports our default READ and FAST READ instructions:
The READ (0x03) instruction as implemented by flashrom has the following sequence: 1 byte instruction out, 3 byte address out, 1-infinity data bytes in and the FAST READ (0x0b) instruction as implemented by flashrom/dediprog has the following sequence: 1 byte instruction out, 3 byte address out, 1 byte delay/dontcare, 1-infinity data bytes in
If you compare our default instructions with the ones supported by the AT25512, you'll notice that there is no match at all for any sequence.
This means that although the hex value of the supported instructions match, both the standard flashrom drivers and the dediprog flashrom driver will read completely corrupt data from the AT25512.
Side note: It would be cool if someone modified the default SPI chip read function to work with 2-byte addresses as well. Probably copy-n-paste, but maybe there is a more intelligent way available which doesn't kill readabililty.
Steven, you are right about having to read all the datasheets. If you do that, can you please extract a list of allowed instructions from all datasheets (and if some bits are X/dontcare please write that down as well). Such a list will help us a lot if we extend flashrom for more programmer types and for dual/quad read/write interfaces. If you can check the timing (how many bytes for address/delay/data) sequences for the read/write/ID instructions as well, even better!
Richard, Steven demonstrated that a simple check of the Dediprog device list against the flashrom device list isn't going to help. Sorry. We could ask the Dediprog developers about how they handle chips with odd read instructions, but I suspect that it will essentially boil down to using the generic command interface instead of the fast bulk interfaces.
Regards, Carl-Daniel