[flashrom] Status of dediprog support?

[Carl-Daniel Hailfinger]

Auf 14.12.2010 05:29, Steven Zakulec schrieb:
> On Mon, Dec 13, 2010 at 6:18 PM, Richard A. Smith <richard at 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

-- 
http://www.hailfinger.org/