* Paul Millar paul@astro.gla.ac.uk [070314 12:52]:
Slide 13 shows a schematic containing a CP2102. This looks like its accepts a
^^^^^
The Test Integration Manual goes into more detail than the slides: http://www.coresystems.de/PDFs/LinuxBIOS-testing/TestIntegrationManual.pdf
USB connection (from test supervisor host) and outputs a normal collection of serial lines (for the machine that is to be tested).
Yes. It's a USB to RS232 interface.
Some questions:
- Slide 13 says "IOC looks like a serial interface to the test supervisor
server". Is this the USB interface? The serial side (TXD, RXD, DCD, etc...) is on the test machine side, right?
Yes. I chose to use a simple and cheap chip that is already supported by Linux with no additional code. You connect the USB side of the chip to the test supervisor, and it will come up as a serial interface.
None of the serial pins are actually used, except DTR and RTS, because those are the only two completely freely programmable pins.
You could use any other USB circuit which provides IO lines, ie. it could be based on an ezUSB.
- Looking at the CP2102 data sheets[1], it looks like it takes it power from
the USB bus, is this correct?
yes.
(minor quibble: the sample circuit has a capacitor between VDD and Gnd, which looks like its missing in the schematic on slide13; dono if its necessary)
Good question. Since the 2102 is only available as SMD as far as I know I got mine by cracking up an existing serial to usb converter and soldering my own circuit to the small smd pcb that was hidden in the connector.
- The slide also says "two IO ports". Are these the two opto-isolated
ILD621s?
The ILD621* is a dual channel optocoupler which is indeed used to isolate the serial output pins from the switch circuit.
* http://www.vishay.com/docs/83654/83654.pdf
Since I could not get that optocoupler in a low amount and time in my town, I decided to go with two slightly more expensive reed relays which serve the same purpose (but are about €1.50 each, slower and larger than the optocoupler)
- Side 14 says "additional ATX power control using the IOC". So, one can
(or should) connect one of the IOC's ILD621 to the ATX power-on/off pin. If so, do you really need the IPS-400 (remote power switch)?
Exactly, the output of one of the pins
No, you don't really need the IPS but it is pretty much recommended. Or you can use an X10 switch or something, but I have not implemented a driver, nor tested it. During development of the system we saw some cases when the system would not correctly halt. Thus the IPS would switch the machine off, and create an identical start environment for the next test.
The switch is so simple that you have no easy way (yet) to find out whether the machine on the other side (SUT) is actually running (except pinging it, which is not reliable. The machine might hang with no network)
When you do an ATX power off, the ILD621 output is set to high for 4s. This is like pressing the power button for 4 seconds -- it has a different effect whether the machine is on or off. So it could also confuse the test system.
- Could one use /SUSPEND to control the ATX power supply? Something like
driving another ILD621, which shorts ATX pin 14 to Gnd. That should free up one the output lines.
Intersting idea. Then you could connect more logic to the IOC, like the reset connector, which would allow more complex test scenarios.
- The two ILD621s are really just output ports, right?
It's actually one one ILD, and it has 8 pins. I used Eagle for drawing the schematics, and it paints the two optocouplers seperately. Of course one could use single optocouplers, or in case you want to use more output (or input) signals, also a 4x or 8x optocoupler.
There's 3 or 4 bits (RI, DCD, DSR; CTS maybe) that could be used as inputs. Are there plans for connecting these "somewhere" to allow some progress report: the BIOS could signal "some lines" to say its to a certain stage in the init. process (e.g. the memory initialised correctly). That way, when a test fails, one gets some idea where the failure might have occurred (something like the POST codes). Side 23 mentions tests for the BIOS, but there's no mention of how these are instrumented.
Yes, or simply check whether the box is actually running or not. There's some neat ideas you could do with this. Contributions are definitely welcome!
The schematics are more of a "proof of concept" and can definitely be improved, or even just be looked over by someone with more electronics experience.
- I don't think the docs say this explicitly, so I'm guessing the test cycle
is: a. Use IOC to switch Savior, selecting a BIOS chip with a known-good BIOS image. b. Power up test machine. c. Use IOC to switch Savior, selecting the test-BIOS chip. d. Log into test machine: i. flash test BIOS onto the test-BIOS chip. ii. Reboot. e. Somehow test the new BIOS (slide 23 mentions 10 tests; how are the tests run, how are the results gathered?) Is this correct?
d.ii switches the machine off completely, since a reset is not sufficient to emulate cold power on behavior of the hardware.
e. First the test supervision server just scans for certain strings in the LinuxBIOS and Linux output. Then some stuff like /proc/cpuinfo is examined and some programs are copied to the machine and executed (ie for testing memory bandwidth)
The slides are rather old (last october) -- There are 26 different tests in the meantime. A test specification with more details on every single test is available at
http://www.coresystems.de/PDFs/LinuxBIOS-testing/TestSpecification.pdf
The testsuite itself can be downloaded from:
svn://linuxbios.org/testsystem/LinuxBIOS-testsystem/
or browsable online at:
http://linuxbios.org/viewvc/?root=Testsystem
Patches are of course welcome
- I think the title for slide 12 is a little misleading ("remote BIOS
updates") as the BIOS is not updated remotely but rather locally, via the BIOS Savior (if I've understood things correctly). Are there any plans to allow remote BIOS updates? (perhaps by using the CP2102's TXD serial data lines to program the chip).
I called it remote because it is triggered from a remote machine without the developer having to touch the "local machine" himself.
The CP2102 can not be used for bios updates. But you can use a PROMice memory emulator or some such. Those are available for 3000US$ upwards.
I don't have a spare one for testing, so there is no support in the test system, but it can easily be implemented.
The test integration manual says a couple of words about how to add your own components.
http://www.coresystems.de/PDFs/LinuxBIOS-testing/TestIntegrationManual.pdf
- Has anyone entered the circuitry into a schematic capture program? Has
anyone put together a single-layered PCB layout? For small runs, I think home-brewed PCBs might be preferable to strip-board.
I made a PCB with eagle a while ago for an older version of the circuit, but i did not have it manufactured, as it required SMD parts, too.
It might be an interesting idea to integrate the bios savior into the circuit as well, as IOSS does not produce the bios savior anymore.
Hope that helps. Stefan