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