[coreboot] Yet another idea of an SPI flash chip programmer
FENG Yu Ning
fengyuning1984 at gmail.com
Wed Dec 24 15:09:28 CET 2008
On Wed, Dec 24, 2008 at 2:24 AM, Peter Stuge <peter at stuge.se> wrote:
> FENG Yu Ning wrote:
>> 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.
> 8388608 / 2 * 24 = 100663296 + 32 = 100663328 total clocks
SST25VF080B has a size of 8M bits. Therefore I think the dividend
(size in bytes) should be 1048576 instead of 8388608?
However, that affects little on the total time, compared to USB
protocol overhead, or even Tbp.
> 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
Here the waiting time would be approximately 5 seconds.
> 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. :)
We really should prevent that from happening then.
> 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.
We may not need a dummy transfer to wait. Let's wait on a lower layer.
The FT2232D datasheet suggest that we need to control output to the
CE# pin (of the SPI flash chip) manually. If the flash chip does not
react to the clock signal when CE# is high, we can simply insert some
control bytes doing dummy read. We can wait for an exact time period
because we decides how many 8x clocks to wait for. Then all can be
done in one transfer.
> I am not sure if the FTDI chips or even the Linux USB stack allow
> this fine control over the USB communication,
If the above idea works, all we need is proper assembly of control
bytes, which are data from the view of USB protocol.
> so I am curious to hear more about any testing that is done.
Yes. At last testing gives the result.
> Most of the time budget will be eaten up by wait states.
Now my time is being eaten by repetitive 1 mail/day periods contacting
product distributors (ftdi, Dediprog, etc.)
> What to do then? One solution is to keep the FTDI module and add a
> microcontroller to do the actual SPI communication.
> Now the project isn't very simple anymore.. :)
If I go one step further adding support for other types of flash
chips, I am actually starting another willem project :-)
More information about the coreboot