[coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).

[Carl-Daniel Hailfinger]

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