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