Hi, Juhana Helovuo wrote: > Now there is more progress. After some building, coding, and > debugging I have the tester sort-of-working.
Cool. > In this image you can see the tester plugged into an Asus mainboard: > > http://alpskari.asiantuntijat.org/~juhe/in-system-flasher/DSC08430.jpg Sadly this URL does not work for me. :\ > The work is still quite incomplete: > > * The first PCB had two layout errors (corrected by jumper wires), > so it needs some rework. All right. > * Some host-side software is missing. Flashrom extension or a > separate program is needed to control the pushbutton inputs. This has nothing to do with flashrom, and should certainly be a separate program. > * The PCB could be extended to include a software-controlled isolated > switch to control a relay, which can switch mains power of the target > mainboard on or off. I am still uncertain whether I want to have > self-hacked devices with 230 VAC parts in my house. Well yes and no. It's not something we want to promote, but switching AC is of course the ideal power cycle. > * Currently there is no tester firmware that could operate both the > SPI and RS-232. The main problem is that the AT90USB162 > microcontroller supports only up to five USB endpoints Sorry, but the problem is how the USB firmware has been implemented. > I do not know if it is possible to implement two USB CDC class > virtual serial ports with less than seven EPs. With two serial > ports, one could represent the RS-232 interface, and other be used > to control the programmer without writing any custom USB drivers. I thought we agreed that in particular the flash programming must be implemented with a custom protocol directly on top of USB, rather than something on top of a serial port emulation on top of USB. And as far as the serial port goes.. We can and should just make the coreboot tester software support the tester hardware directly. This means using a custom protocol directly on top of USB also for the serial console. Abusing USB to emulate a UART is always a bad idea. Sometimes the only way, but not the case here. We can do much better. > This could be solved either in software by writing a custom USB > driver for both the tester and the host, or in hardware by > replacing the microcontroller with a more capable model. If anyone > on the list can suggest any easier solutions, I'd be glad to hear > about them. I think it's a good idea to support more than a single microcontroller, but I also think the AT90USB is capable enough to do this task pretty well. Per-interface classes, vendor specific on each interface, I'd need to look into the serprog protocol to suggest the first interface, but the second would just need one bulk IN endpoint for the serial input stream from mainboard UART. Should not be more than five endpoints including 0 IN and OUT. > * The handling of SPI ROM is horribly slow. Programming and > verifying 1 MByte ROM takes about half an hour. The main suspect > is nonexistent USB data buffering in the tester firmware. No need to suspect. The serprog protocol is simply too stupid for SPI. I have brought up the need for a data model that can describe SPI flash programming on numerous occasions; this is one application where it is absolutely neccessary. The SPI extension I created for the Artec FlexyICE is another. flashrom currently has a good grasp on how to program SPI flash, but that needs to be abstracted into data, so that flashrom can send a "task" to a flashing device, rather than being in the all-wrong business of fiddling with bits over serprog. Ideally data can be buffered as well. How much RAM is available in the AT90USB you are using? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
