[coreboot] [RFC] cheapish and free usb spi flashing device
stefan.tauner at student.tuwien.ac.at
Wed Apr 27 22:42:29 CEST 2011
On Fri, 22 Apr 2011 05:08:32 +0200
Peter Stuge <peter at stuge.se> 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?
sure serprog is pretty stupid, but that has nothing to do with its
serial property. :)
> At a very minimum translate the serprog protocol to native USB.
> 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. of course factoring out the control
messages is useful, but there are several drawbacks:
- we cant tunnel it as easily (e.g. over tcp like serprog)
- everything gets way more complicated on the microcontroller
i dont see a lot of performance improvements from it either. dropping
cdc and just stream our own protocol via usb's bulk endpoints would be
fine with me. i have already done this once.
maybe i am missing something though. please layout your basic ideas how
an USB flashing protocol should look like, what it could do (what
serprog or something similar could not (as easily)).
btw do we want to support non-spi flashes at all?
> Also, make a simple HAL for the AVR, so that your C firmware can be
> re-used with other processors. I'll make it run on LPC1342/43.
spi reads, writes and cs(/hold?/wp?) will be independent.
atm i am extending serprog and character reads and writes from the
serial stream are basically independent. i do use avr-specific printfs
though (those fetch the strings from flash memory instead of ram...
harvard architecture, which is not abstracted), but that can be dealt
with if need be.
> > without any level shifting.
> Yes, is a good feature.
it costs performance in the case of the avr though... about 8MHz maximum
clock instead of 16 with vcc>=4.5V.
> > i was also thinking about an offline mode which uses an SD-card or
> > another flash to store/load an image for the target flash.
> SD is not worth the effort. SD cards are very incompatible and it
> takes a lot of work to implement a well-functioning card reader.
thats true, i have tried ;)
> 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.
> A second flash chip could be handy for offline mode - but what is
> supplying the power?
a usb power supply for example :)
adding another connector for other power supplies wouldnt be a problem
BUT.. since there is not really interest in _my_ new flasher anyway and
everyone seem to have built his own, i think we should just concentrate
on the usb protocol.
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
More information about the coreboot