[coreboot] [RFC] cheapish and free usb spi flashing device

[Peter Stuge]

Stefan Tauner wrote:
> > > right now my plan is the following:
> > > an avr atmegaXXu2 is connected via usb and implements the serprog
> > > protocol
> > 
> > Please do not! Make good use of USB and design a protocol that
> > actually takes advantage of relevant USB features, instead of
> > pretending that USB is a serial port, which is really lame.
> 
> what features do you think _are_ relevant?

The fundamental feature is that USB communication is highly
structured on the very lowest level. It is a tremendous waste not to
take full advantage of this property.


> > USB is a packet bus. Making it behave like a dumb stream of bytes is
> > almost never a good idea.
> 
> if i had to transfer the content of a file i would choose tcp instead
> of udp. this is quite similar imho.

That comparison isn't valid because USB does not always resemble UDP,
only when using isochronouse transfers. Consider this:

Would you use telnet+Zmodem to transfer the file, or rather FTP?

(Remember that you are implementing both ends of the connection and
disregard the complications in FTP caused by worldwide NAT.)


> there are several drawbacks:
> - we cant tunnel it as easily (e.g. over tcp like serprog)

Any protocol can be tunneled over any other protocol. In fact I think
what I suggest would be even easier to network enable than serprog.


> - everything gets way more complicated on the microcontroller

I don't know about *way* more, but yes, more complicated. The flip
side is that the interface is tremendously more elegant, and easy to
use. This is more important than saving a few hours of development
IMNSHO.


> i dont see a lot of performance improvements from it either.

Not about performance, about usability and elegance. Concepts not
very common in software development worldwide. But in fact they may
be the only worthy goals in software development. They also tend to
go hand in hand.


> maybe i am missing something though. please layout your basic ideas
> how an USB flashing protocol should look like,

I've tried to explain the general idea to several people but noone
has really gotten what I mean, so to answer your question I have been
thinking a bit more about the details of the protocol.

The design goal is to be able to cat a .rom file into a device node
created by standard Linux kernel drivers, and have that .rom file
written to a flash chip. In practise the goal is unreachable because
the kernel doesn't expose endpoints as device nodes anymore, but we
want to come as close to the goal as possible. Consider a usbcat
program being used instead of regular cat.

The question is what other information the hardware must be given
before it can accomplish this. This is the SPI flashing data model
that I have been asking for several times.

1. Flash bus - SPI or LPC/FWH (only SPI first, but keep LPC in mind)
2. What SPI commands to use for identify, erase and program
3. Max SCK speed
(4. How to do identify, erase and program on LPC)

I think flashrom already knows these things except maybe 3, the data
is just not exported in any suitable way yet.

So far I can think of two ideas for how this data is sent to a
microcontroller:

1. Oneshot transfer of a datastructure with some or all parameters,
followed by one single transfer of the data to be programmed

2. An instruction set is created that gets executed by a simple state
machine in the microcontroller, and instead of the parameterized data
structure above, one microcode snippet would be sent for each
operation identify/erase/program.

Of course it's also possible to do both of the above, and in fact
they might complement each other. 1. assumes that we can design a
very future proof data model for SPI programming, or the
microcontroller firmware might have to be updated for a future SPI
chip. While I think we could actually do this, it's still nice to
have a completely generic interface such as 2. since then the user
can always create the needed microcode snippets from a data sheet,
without having to upgrade the firmware. (OTOH, the LPC1343 is
extremely easy to reprogram, so this may be moot as long as
microcontroller developers are eager and quick.)

I hope this is not too abstract for people to understand the idea?

To spell it out even more, in USB terms, there would be, at least:

* a control transfer to set the SPI clock speed
* a control transfer to set the current address in memory
* a control transfer to switch power supply to the flash chip
* bulk out sends SPI bytes
* bulk in reads SPI bytes

The above is the simplest interface, even simpler and more stupid
than any of 1. and 2. I describe above. But it would be the minimum
to start with, to guarantee a completely future proof hardware. It's
also easy to implement.

The next step would be:

* a control transfer to set command(s) used for identify
* a control transfer to set command(s) used for erase
* a control transfer to set command(s) used for program

These command(s) are not just one byte, a "language" (data model 1.,
or microcode 2.) is needed to express the various sequences.


> btw do we want to support non-spi flashes at all?

Yes, but one thing at a time. The microcontroller will not likely
have LPC master hardware so it will have to be bit-banged, and will
thus not be too fast. Good use of USB to speak SPI is more important.


> > > i was also thinking about an offline mode which uses an SD-card
..
> > And the filesystems are buggy as well.
> we would not need one... wear leveling is done by the card and we
> only need a continuous block.

Then the use of the SD card as media is significantly reduced,
because a PC with a card reader can not use the default file transfer
tools (Explorer, Finder, mount/mtools) to put an image to-be-flashed
onto the card.


//Peter