[coreboot] Yet another idea of an SPI flash chip programmer

[Peter Stuge]

FENG Yu Ning wrote:
> > I wonder how easy these are to order..
> 
> I did not post this because I felt it was like advertising,

I encourage vendor information on the list as long as the products
haven't been mentioned before and are relevant to coreboot. Even
advertising (your own products and services) should be OK now and
then, again as long as they are relevant for coreboot. I've done it
when I've had some significant news.


> but here it is:
> 
>   http://www.dediprog.com/SPI-flash-accessories/SPI-Flash-Socket-8pin
> 
> I have contacted with the company and I am told the MOQ is 10.
> Shipping fee is high except for Taiwan.

Nice! I sent an inquiry to the manufacturer about a sales rep in
Europe, we'll see what reply I get.


> > And for which flash chip size? That is also important, because
> > double the size will double the time. :) 4Mbit vs. 16Mbit = 4x
> > the time.
> 
> Could the words, between parentheses after "not slow" in my
> original post, serve as a specification of that kind?

Unfortunately "not slow" is difficult to use in calculations. :)


> I think what I meant in the original post is I do not want to wait
> for more than 3 mins for any chip. Of course that is not a proper
> spec. Since 8Mbit chips are widely used these days (is it?), my
> spec would be: 3 mins - 8Mbit.

Ok. That's a good approximate goal. Let's see how to write
SST25VF080B in 2.5 min = 150 s.

(Conservatively assuming read/verify needs the other 30s.)

The first two bytes require six bytes * 8 clocks = 48 clocks.
All other two bytes require three bytes * 8 clocks = 24 clocks.

So the first two bytes need 24 extra clocks, and 8 more are needed at
the end for the WRDI command.

8388608 / 2 * 24 = 100663296 + 32 = 100663328 total clocks

For end-of-write detection I think it is easiest to simply wait Tbp
(10us) after each pair of bytes. Using this method, the time spent
waiting will be a minimum of:

8388608 / 2 * .00001 = 41.94304 seconds

Because of the high number of waits needed and because of the
"distance" in hardware between the PC CPU doing the waiting and the
SPI output pins on the USB module, this time can increase a lot.

Data will be streamed to the FTDI and not transferred all at once and
stored in RAM closer to the flash chip, so USB performance must also
be considered.

FT2232D is a full speed device, the minimum unit in full speed USB
scheduling is a frame, and a frame is scheduled every 1 ms.

Assuming that there is no other activity on the USB, and that only
one transfer is made per frame, every wait state will be a minimum of
1 ms, instead of 10 us, causing a 100x slowdown. About 4200s = 70 min
would be spent waiting for scheduling. :)

There is room for more than one transfer in each frame however, so if
care is taken, dummy transfers can be inserted (should be commands
that communicate with the FTDI only, maybe reading some status
register) between the three bytes going out to SPI.

I am not sure if the FTDI chips or even the Linux USB stack allow
this fine control over the USB communication, so I am curious to hear
more about any testing that is done.


Most of the time budget will be eaten up by wait states. If the USB
communication can be optimized so that overhead costs only 3x
(which I think is way too optimistic still) that means ~125 seconds
of waiting, leaving 25 seconds for clocking out write commands:

100663328 / 25 = 4026533 clocks per second.

The FTDI can do 6MHz, so there is a little bit of margin. But again,
I think that 30 us timing precision will be difficult to reach
reliably.


> > Please do. The 2232 MPSSE mode's maximum SPI clock is 6MHz, but the
> > problem is with turnaround time between each sequence of bytes that
> > are read or written. ..., this need for status reads can slow the
> > process down quite a lot.
> 
> I did not realize that. Let's see.

It will be very interesting.


> > Another option is to download the data to be flashed "just in time"
> > so that no buffering is needed. But then the PC communication link
> > needs more care. I think that is easier than adding RAM however.
> 
> After all, a (not so) fast GPIO peripheral interface, with a simple
> (stupid) protocol, solves the problem. The philosophy of PC decides
> we do not have things of that kind.
> 
> Serial and parallel ports are simple, but they are a bit slow.
> USB is fast, but the protocol is complicated (for SPI programming
> application).

USB can be quite fast in many applications, but it is not at all
suitable for intensive bi-directional communication with fast timing.

Also, products like the FTDI chips simplify away many details of USB
that can be critical to get adequate performance.


What to do then? One solution is to keep the FTDI module and add a
microcontroller to do the actual SPI communication. The FTDI is used
only to download data 16, 32 or 64 bytes at a time, enough to keep
the microcontroller busy with writing to the flash and polling for
flash ready, and that way the micro doesn't need external RAM.

That will certainly allow 8Mbit to be written in less than a few
minutes and any microcontroller with SPI can be used.


But, then the software needs much more work, because the
microcontroller must know how to communicate with every flash chip.

It would be very neat to look at most available flash chip data
sheets and create a configuration format that allows the PC software
to instruct the microcontroller which sequences to use.

The primitives write byte, wait usec and read byte would be enough
for starters.


Now the project isn't very simple anymore.. :)


//Peter