Hi Daniel,
On 16.06.2010 16:34, Daniel Flinkmann wrote:
Thanks for the quick reply. See my answers below:
After that I can't see any progress, as -V is pretty silent when writing the flash and -VV dumps far too much to have an overview.
Yes. Progress bar printing is on our list of useful things to do, but some parts of the current flashrom architecture don't really fit, and thus this will require quite some refactoring. I can hack up a progress printing patch which outputs a dot every time 1024 bytes are read/written. That would give you some progress indicator for now, and we can continue fixing flashrom to eventually support something like that natively.
Understood. The dots every 1kb would help to have a minimal monitoring.
Will tackle that soon.
Probing for Atmel AT25DF021, 256 KB: RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0x00, id2 0x00
WTF?!? This looks like data corruption. Such a response is absolutely unacceptable. Can you run
flashrom -p buspirate_spi:dev=/dev/ttyUSB0 -V
a few times (should be a matter of a few seconds) and check if any probe_spi_rdid_generic complains about a parity violation? If yes, there is a bug somewhere which needs to be fixed.
Yes, I will do so, when I am back at home and report them to the mailing list.
Thanks.
Chip status register is 1c Chip status register: Block Protect Write Disable (BPL) is not set Chip status register: Auto Address Increment Programming (AAI) is not set Chip status register: Bit 5 / Block Protect 3 (BP3) is not set Chip status register: Bit 4 / Block Protect 2 (BP2) is set Chip status register: Bit 3 / Block Protect 1 (BP1) is set Chip status register: Bit 2 / Block Protect 0 (BP0) is set Chip status register: Write Enable Latch (WEL) is not set Chip status register: Write In Progress (WIP/BUSY) is not set Found chip "SST SST25VF080B" (1024 KB, SPI) at physical address 0xfff00000.
Ouch! That chip can only write one byte at a time. This will be painful and slow. We might be able to use a few tricks (e.g. AAI write), but even with the tricks, your flash chip is one of the worst cases for the Bus Pirate.
Better awfully slow, than having a brand new, but bricked mainboard ( I have ordered a new preflashed flash chip, but it is still in the delivery). So I am open for some more pain ;-)
True. By the way, flashrom can do cross-flashing, so if the flash chip is removable, you could hotplug it into another board with SPI flash and run flashrom there. Would be much faster (maybe a minute to write), and reads would probably take a second or two.
Flash image seems to be a legacy BIOS. Disabling checks. Writing flash chip... Some block protection in effect, disabling Erasing flash before programming... Erasing flash chip... Looking at blockwise erase function 0... trying... 0x000000-0x000fff, 0x001000-0x001fff, 0x002000-0x002fff, 0x003000-0x003fff, 0x004000-0x004fff, 0x005000-0x005fff, 0x006000-0x006fff, 0x007000-0x007fff, 0x008000-0x008fff, 0x009000-0x009fff, 0x00a000-0x00afff, 0x00b000-0x00bfff, 0x00c000-0x00cfff, 0x00d000-0x00dfff, 0x00e000-0x00efff, 0x00f000-0x00ffff, 0x010000-0x010fff, 0x011000-0x011fff, 0x012000-0x012fff, 0x013000-0x013fff, 0x014000-0x014fff, 0x015000-0x015fff, 0x016000-0x016fff, 0x017000-0x017fff, 0x018000-0x018fff, 0x019000-0x019fff, 0x01a000-0x01afff, 0x01b000-0x01bfff, 0x01c000-0x01cfff, 0x01d000-0x01dfff, 0x01e000-0x01efff, 0x01f000-0x01ffff, 0x020000-0x020fff, 0x021000-0x021fff, 0x022000-0x022fff, 0x023000-0x023fff, 0x024000-0x024fff, 0x025000-0x025fff, 0x026000-0x026fff, 0x027000-0x027fff, 0x028000-0x028fff, 0x029000-0x029fff, 0x02a000-0x02afff, 0x02b000-0x02bfff, 0x02c000-0x02cfff, 0x02d000-0x02dfff, 0x02e000-0x02efff, 0x02f000-0x02ffff, SUCCESS. done.
Timing with the Bus Pirate can be calculated as follows:
If we assume the usbserial driver of your OS pushes all bytes of a read/write at once, we have one USB transaction per read and one transaction per write. Each transaction takes 1 ms (USB standard). To send a SPI command to the chip, we need:
- one write/read to activate CS#
- one write/read to send/receive SPI command and response
- one write/read to deactivate CS#
This means a total of 6 transactions and 6 ms per SPI command if we have optimal conditions. To read a whole chip, we slice it up in pages of 256 bytes each (some chips need that) and then we slice each page up in chunks of 12 bytes each (Bus Pirate read length limit). This means we have 22 chunks per page. Your chip has 1 MByte (1048576 bytes), 4096 pages and thus 4096*22=90112 read chunks. Each chunk has to be read with a separate command, so the absolute minimum read timing for your chip with the current code is 90112*6=540672 ms or roughly 9 minutes.
Your chip supports two write modes:
- standard one-byte-at-a-time (write_1) write (default)
- auto address increment (AAI) write
and flashrom uses write_1 mode right now (can be changed).
write_1 mode means you have to send at least three SPI commands to the chip per written byte: write enable, write byte, read status. Your chip has 1 MByte (1048576 bytes), needs 1048576 byte writes, thus 1048576*3=3145728 SPI commands, and 3145728*6=18874368 ms or roughly 315 minutes to write in the optimal case, plus the time to verify (full chip read).
AAI write mode means you have to send at least two SPI commands (or one SPI command and continuous listening on the SO pin) per two written bytes. Your chip has 1 MByte (1048576 bytes), needs 1048576/2=524288 AAI writes, thus 524288*2=1048576 SPI commands, and 1048576*6=6291456 ms or roughly 105 minutes to write in the optimal case, plus the time to verify (full chip read).
The current flashrom SPI code has some additional delays which shouldn't have an effect during erase/read, but I sent a patch to remove them a few minutes ago. Those delays slow down write a lot, though.
Once the delay removal patch is in, the following options remain:
- Use AAI to speed up write by a factor of 3 compared to the default.
- Violate the Bus Pirate communication protocol and batch each
CS/command/CS combination into one write/read. Should result in a speedup for read/write/erase by a factor of 3. Not sure if it is doable.
- Violate the Bus Pirate communication protocol some more and batch each
flashrom multicommand into one write/read. Speedup by a factor of 2 for write.
With enough protocol violations and AAI write, the minimum write time for your chip is roughly 18 minutes plus the time to read the chip. This write time can only be achieved if your OS has good usbserial drivers and if the Bus Pirate is fast enough.
The biggest mystery right now is the 60 minutes required to erase. Unless I'm mistaken, this means all of the time is spent reading for the verify operation. Given that my calculations result in 9 minutes read time, I'd like to know what's going wrong here before you attempt to write. If this is a problem affecting all operations, you would have to deal with write taking a day or more. That is totally unacceptable.
Can you measure exactly how long a read of the chip takes, preferably while no other processes are running in the background on the machine running flashrom?
I don't like the idea to violate the Bus Pirate communication protocol, but using AAI and utilizing your new sleep removals should be a nice step forward.
OK. I just sent a patch which violates the protocol, but according to the data sheets I have available my hack should work due to existing buffer sizes even if it violates the protocol.
The used computer which is running flashrom and using the Bus Pirate is an Atom D330 running 64bit Ubuntu Lucid Lynx and is normally just a TimeMachine/Fileserver, but was idling all the time.
Hm. Are you running the machine with HZ=100 or HZ=100? HZ=1000 could in theory improve flash access speed (due to scheduler side effects).
I will try to make an exact measurement of the flash erasing and rom reading again.
No need to get erase timing, read timing is sufficient.
Shall I give your speed-up patch a try before I start doing the measurement above?
It would be nice if you could measure read timing with unmodified flashrom and with my protocol violation hack.
Regards, Carl-Daniel