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

[Peter Stuge]

FENG Yu Ning wrote:
> > 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?

Yes certainly! Thanks for catching that! It means there is a lot more
margin.


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

Which is a huge improvement, because 500s would be more bearable than
4200s, just not very nice.


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

Yes, the problem is that I do not think any kernel API allows actual
control of how multiple transfers are packed together into frames.


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

Yes, the CE# pin has to be controlled separately from the FTDI SPI
stuff. One idea is to use a GPIO pin on the FTDI for that, which will
require at least one USB transfer. Maybe it will be enough to create
the delay, but I suspect it is best to add another transfer before
selecting the chip again.


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

The challenge will be to fit those USB transfers into frames to get
the minimum neccessary delays but still not have too long delays.


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

The USB API is packetized, not a stream of bytes. This frame stuff
I talked about is what happens on the wire, but it is all handled by
the Host Controller hardware, and maybe the host controller driver in
the kernel - and I know for sure that the kernel API doesn't allow
any control over these lowlevel details.

I think the best test is to queue several URBs (USB Request Block)
doing SPI output, GPIO control and SPI input with the FTDI at once,
and see what happens on the output pins.


> Now my time is being eaten by repetitive 1 mail/day periods
> contacting product distributors (ftdi, Dediprog, etc.)

Maybe you could even find the FTDI module at a local electronics
store?


//Peter