On 20.01.2008 12:48, Ronald Hoogenboom wrote:
On Sun, 2008-01-20 at 11:59 +0100, Ronald Hoogenboom wrote:
The read status register will take at least: 16*(2/33) us = about 1 us (excluding the LPC latency, which is....?), so assuming that the first read status will show busy and the second will show ready, it is only 2 us slower: ~20%, so that should be acceptable. I'll do some checks on the hardware shortly.
I've done the tests and the programming result (eg. the data read back
from the flash) is correct with and without the status reading.
With status reading, programming takes: 1'15 ~ 1'50 Without status reading, programming takes: 0'50 ~ 0'55
Hm.
There is quite some variance in the time taken extra by reading the status, the lower bound is about the expected penalty (as calculated above), but the higher bound is not so easily explainable without better understanding. If you think this performance hit is acceptable, then go for it, put the status reading back in, I would say.
I think we can shorten the delay in the loop to about 5 us. However, even with 10 us delay we still can't explain the time needed to program the chip. In the case without status reading, we have exactly 5 bytes on the SPI bus for every byte written. At 16 MHz, 5 bytes take 2.5 us transfer time. Adding an unconditional 10 us delay (max. byte program time according to the datasheets) gives us a total of 12.5 us per byte written to flash. Looking at the time you needed to program the while flash chip, things don't add up. With 12.5 us per byte and 2 MByte chip size, the total programming time should be close to 25 seconds. That is half the time it takes in reality and tells us we have ~12.5 us overhead per transaction. This overhead can NOT be attributed to LPC cycles because we avoid LPC altogether in byte programming. Either there is some concurrent access to the ROM (SMM or other stuff) or the accumulated reads/writes to the I/O ports of the IT8716F take that long.
Can you use oprofile against the current code to find out where we spend all of that overhead?
Maybe it would be nice to have some kind of progress bar, like in 'rpm -Uhv', 'scp' or 'cdparanoia', at least while programming the flash, especially when the programming times get over a few minutes, as can be expected with these bigger and bigger serial flash devices.
Yes, this would be nice to have. Some chips already implement a per-page progress indicator.
Maybe there should also be support for partial erasing and programming (depending on what the device allows).
The functions are there for most chips, but we currently have no way to tell flashrom about sector sizes. Since quite a few SPI chips have non-uniform sector sizes, you have to store an array or sector sizes for each chip. That gets tedious quickly.
Regards, Carl-Daniel