[coreboot] Tester devices [was: QA contribution]

[Peter Stuge]

Juhana Helovuo wrote:
>> unit that can administer testing of one or even better several
>> mainboards. I have plenty of design and implementation ideas if
>> you'd like to go into that.
>
> I started building a tester device to hook up a mainboard into an
> automated test host.

Nice.


> The basic plan is as follows:
> The host computer is connected to tester device via USB.

This certainly makes the device itself simpler. But it requires
*another* system to be monitoring all these devices.. I can't seem to
let go of the thought that I would prefer a tester device to be
connected directly to the internet, and work autonomously. Ethernet
is simple enough with something like an LM3S6965 ARM. WiFi would be a
nice option, but will also increase the unit cost..


> The tester is connected to the target mainboard so that it can take
> control of the BIOS ROM and reprogram it regardless of the state of
> the target mainbaord.

Yes. A flash emulator would of course be ideal, but also requires
some programmable logic, ie. either one more component, or a larger
component. In some cases board size is critical, e.g. to fit a tester
inside a tight case.


> The tester device can also connect to the serial port of the target
> mainboard, so it can act as a serial-over-USB-device.

Right. Either the tester just has a UART, or if it is networked then
it will itself do the checkpointing. As for the USB device, it's
fairly important to use a generic USB hardware. The ATmega U chips
would work fine I believe. The key is to have multiple interfaces,
ie. at least one bulk IN endpoint for the serial port, and one bulk
OUT endpoint for downloading flash data, but it might be a good idea
to make both of them bidirectional, which then needs four bulk
endpoints. And it's important to be able to provide custom
descriptors, which the ATmega U and many other micros with USB
allows.


> The tester also has two FET switches for controlling the reset and
> ATX power buttons on the target mainboard.

Yep. I've also been thinking that the power good signal could be
used. One problem with FETs is that they must be plugged in to the
mainboard the right way. It would be significantly simpler to use the
device if it had a solid state switch instead, but that's also more
expensive.


> The actual AC power control of the target mainboard is not included
> and should be done by another device, such as this:
> http://www.gembird.nl/default.aspx?op=products&op2=item&id=3234

Do you know where these units can be purchased, with the various
voltage ratings and power plugs that are needed around the world?


> Here are some images of my first (incomplete) prototype:
>
> http://alpskari.asiantuntijat.org/~juhe/spi-flasher-piirilevyt/

Looks like a great start!


> The software is not yet done, except a prototype microcontroller
> program that can read and program SPI ROMs. It is controlled by
> "flashrom" from Linux host. It can communicate via serial port
> using the "serial programmer" protocol.

With USB connectivity I think it is important to really take
advantage of the simplicity and efficiency of USB, rather than
emulating a serial port on top of it. Also, having a serial port over
USB both for target connectivity, *and* for flash programming, is IMO
unneccssarily confusing. For the flashing we will simply implement
the serprog protocol properly using native USB concepts. It should be
very easy.


> Flashrom program was modified by adding a "serprog-spi"-module,
> which is modified from "serprog", mainly by adapting it to suit
> SPI.

Hm, ok. Yeah maybe some hacking will be needed in flashrom. I've
tried to get a design discussion going with Carl-Daniel for a data
model that can describe any SPI programming algorithm, but he's very
busy. I believe that data model is really what is needed to make the
programming really fast. But of course, serprog works right now!


You're doing really nice work! :)


//Peter