[coreboot] Tester devices [was: QA contribution]

Peter Stuge peter at stuge.se
Wed Feb 16 03:10:00 CET 2011


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




More information about the coreboot mailing list