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 -- http://www.hailfinger.org/ _______________________________________________ flashrom mailing list [email protected] http://www.flashrom.org/mailman/listinfo/flashrom
