Stefan Tauner wrote:
i am currently designing a small and cheap platform to recover from coreboot and other failures easily.
Yay more flashers.
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.
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.
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.
easy interfacing with today's spi flashes
SPI access should also be part of the HAL of course.
without any level shifting.
Yes, is a good feature.
fixed 3.3V ldo voltage regulator (ld1117).
LD? LM? Anyway, that's an 800mA regulator, quite overkill for this application where not even 100mA is required. A smaller one should be cheaper.
- vias for a single row 8pin header to allow attaching probes/test clips (e.g. http://www.pomonaelectronics.com/images/large/6109.jpg) to hook up in-situ flashes.
May want to consider how the test clip is connected to board. The cables on my clips go to a DIP-style connector that plugs into an 8-pin socket.
parts for this excluding the pcb would be in the 10-25$ range. depending on how many pcbs i/we would produce the whole thing would cost probably about 40$. not THAT cheap, but quite better than the dediprog stuff :)
That LPC1343 I mentioned is available on a board from Olimex which is ready made, easy to order at least in Europe, has SPI and power supply on a convenient box header (UEXT) and a small experiment area.
http://olimex.com/dev/lpc-p1343.html
It's 13 EUR + shipping and VAT.
it would also be more convenient and open than the FT2232SPI
Did I mention how I really think USB serial chips are stupid, and FTDI in particular because they have ridiculous prices.
i am not sure about what to do with soic16 chips.
I also don't think they are very common.
drop support for them altogether and let the user hook them up with clips?
Certainly an option.
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. And the filesystems are buggy as well.
A second flash chip could be handy for offline mode - but what is supplying the power?
//Peter