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

[Ronald Hoogenboom]

On Sun, 2008-01-20 at 22:28 +0100, Carl-Daniel Hailfinger wrote:

> 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

I think you are forgetting the enable-write command, needed before each
byte-program command. So that will be another 1 byte = 3.0 us total.
But if you look at the it8716f_spi_command function, that will also
before and after the command wait for the busy bit of the 8716's SPI
controller. These actions will generate extra traffic on the LPC bus
(LPC is the only datapath to the SB and CPU, so it has to!). We could
optimize by omitting the wait for SPI ready when there is no data to be
read, eg. readcnt==0. I'll have a look at what can be gained by that.

> 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.
> 

IO MUST go through LPC, as that is the ONLY path to Southbridge.

> 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