I was delighted to find flashrom when I needed to recently flash a chip with a Dediprog SF100 and I googled for "dediprog linux".
I started with the 0.9.2 release of flashrom as packaged by Debian, but didn't find support for "flashrom -p dediprog". I then noticed a 0.9.3 release on the website, downloaded the latest code from subversion, compiled it and *still* didn't get support for "flashrom -p dediprog".
After digging through the Makefile, it was easy enough to find the support I needed by doing:
make CONFIG_DEDIPROG=yes
My question is, what needs to happen before this is the default setting? (Such that the package in Debian will have this support compiled in for my convenience.) For everything I did, (writing and verifying a couple of chips on a couple of boards), the Dediprog support seems to work just fine.
Is there some further testing I could help do before this support is enabled by default?
Thanks,
-Carl
Hi Carl,
I'd have answered sooner, but right now I'm switching net providers and have only very sporadic access to email.
Auf 10.12.2010 21:43, Carl Worth schrieb:
I was delighted to find flashrom when I needed to recently flash a chip with a Dediprog SF100 and I googled for "dediprog linux". [...] Is there some further testing I could help do before this support is enabled by default?
Here is the todo list for the Dediprog driver in flashrom: - Implement fast write support. I know how to do most of it, but I won't have time to tackle that before January at the earliest. That would give you native write speed. I'd tell you how to do it, but that would be roughly as difficult as writing it myself (I only have lots of USB traces and some reverse engineered data). - 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... - Hook up speed setting support (dediprog_set_spi_speed needs to be handled the same way as dediprog_set_spi_voltage, and that also means it should take the frequency as parameter instead of some obscure frequency ID).
The speed setting is optional (nice feature, but not essential), but the first two points on the TODO list are necessary to ensure that everything works as designed without people having to wait for ages (up to an hour in the write case) and without people getting garbage on read for older chips.
IIRC two people on IRC (dashcloud and NTU) were interested in helping out with the verification that all SPI chips support the FAST READ 0x0b command. It's fairly simple. Search for 0b in a flash chip datasheet and check if any occurence mentions that it is the FAST READ command.
Regards, Carl-Daniel
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.
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.
On Mon, Dec 13, 2010 at 6:18 PM, Richard A. Smith richard@laptop.orgwrote:
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.
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.
-- Richard A. Smith richard@laptop.org One Laptop per Child
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. 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. Thanks!
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
On 12/14/2010 07:48 AM, Carl-Daniel Hailfinger wrote:
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!
Seems like multiple categories of READ are going to be a necessity for flashrom to support chips that have a different read format.
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.
Indeed, that complicates things. *Sigh* :( I suppose a chip audit will be the only way to sort all this out.
Is that something that can start happening soon? I'm currently on xmas vacation and have some idle time. If we have some sort of plan for dividing up the datasheets among people then I can start going through some.
Perhaps some sort of wiki table on flashrom.org to keep track?
I don't have a board that I can load an AT25512 onto and hook my dediprog up to it to see what it does with devices that have different read structures.
On Tue, Dec 21, 2010 at 9:31 AM, Richard A. Smith richard@laptop.orgwrote:
On 12/14/2010 07:48 AM, Carl-Daniel Hailfinger wrote:
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!
Seems like multiple categories of READ are going to be a necessity for flashrom to support chips that have a different read format.
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.
Indeed, that complicates things. *Sigh* :( I suppose a chip audit will be the only way to sort all this out.
Is that something that can start happening soon? I'm currently on xmas vacation and have some idle time. If we have some sort of plan for dividing up the datasheets among people then I can start going through some.
Perhaps some sort of wiki table on flashrom.org to keep track?
I don't have a board that I can load an AT25512 onto and hook my dediprog up to it to see what it does with devices that have different read structures.
-- Richard A. Smith richard@laptop.org One Laptop per Child
I don't have a wiki account, but I'm fine with however you want to break them up- I should also have some time over the holidays here to look at some sheets. If you'd like to see my previous sheet, it's here: http://www.flashrom.org/pipermail/flashrom/2010-October/005118.html If you have any questions, feel free to ask.
I don't have a wiki account, but I'm fine with however you want to break them up- I should also have some time over the holidays here to look at some sheets. If you'd like to see my previous sheet, it's here: http://www.flashrom.org/pipermail/flashrom/2010-October/005118.html If you have any questions, feel free to ask.
I don't think I have a wiki account either unless it carried over from my coreboot svn account.
I don't have any sort of plan. I'm offering to help because I would like to see it happen sooner rather than later.
If the wiki is a problem then perhaps a google doc?
* Richard A. Smith richard@laptop.org [101224 00:05]:
I don't have a wiki account, but I'm fine with however you want to break them up- I should also have some time over the holidays here to look at some sheets. If you'd like to see my previous sheet, it's here: http://www.flashrom.org/pipermail/flashrom/2010-October/005118.html If you have any questions, feel free to ask.
I don't think I have a wiki account either unless it carried over from my coreboot svn account.
I don't have any sort of plan. I'm offering to help because I would like to see it happen sooner rather than later.
If the wiki is a problem then perhaps a google doc?
has this been resolved? If you still need that wiki account let me know.
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [101213 09:20]:
Hi Carl,
I'd have answered sooner, but right now I'm switching net providers and have only very sporadic access to email.
Auf 10.12.2010 21:43, Carl Worth schrieb:
I was delighted to find flashrom when I needed to recently flash a chip with a Dediprog SF100 and I googled for "dediprog linux". [...] Is there some further testing I could help do before this support is enabled by default?
Here is the todo list for the Dediprog driver in flashrom:
- Implement fast write support. I know how to do most of it, but I won't
have time to tackle that before January at the earliest. That would give you native write speed. I'd tell you how to do it, but that would be roughly as difficult as writing it myself (I only have lots of USB traces and some reverse engineered data).
- 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...
- Hook up speed setting support (dediprog_set_spi_speed needs to be
handled the same way as dediprog_set_spi_voltage, and that also means it should take the frequency as parameter instead of some obscure frequency ID).
This is a good TODO list. But I think we should enable dediprog for a wider audience by setting it to default on in the Makefile before that. This will make the chance for getting the SPI chips tested by someone using the dediprog much more likely.
Stefan
On Fri, Jan 14, 2011 at 4:11 PM, Stefan Reinauer stepan@coreboot.orgwrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [101213
09:20]:
Hi Carl,
I'd have answered sooner, but right now I'm switching net providers and have only very sporadic access to email.
Auf 10.12.2010 21:43, Carl Worth schrieb:
I was delighted to find flashrom when I needed to recently flash a chip with a Dediprog SF100 and I googled for "dediprog linux". [...] Is there some further testing I could help do before this support is enabled by default?
Here is the todo list for the Dediprog driver in flashrom:
- Implement fast write support. I know how to do most of it, but I won't
have time to tackle that before January at the earliest. That would give you native write speed. I'd tell you how to do it, but that would be roughly as difficult as writing it myself (I only have lots of USB traces and some reverse engineered data).
- 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...
- Hook up speed setting support (dediprog_set_spi_speed needs to be
handled the same way as dediprog_set_spi_voltage, and that also means it should take the frequency as parameter instead of some obscure frequency ID).
This is a good TODO list. But I think we should enable dediprog for a wider audience by setting it to default on in the Makefile before that. This will make the chance for getting the SPI chips tested by someone using the dediprog much more likely.
Stefan
flashrom mailing list flashrom@flashrom.org http://www.flashrom.org/mailman/listinfo/flashrom
Hi, I hope to have a (partial?) list of the chips that support fast_read by this weekend.
-
Carl Worth -
Carl-Daniel Hailfinger -
Richard A. Smith -
Stefan Reinauer -
Steven Zakulec