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