[LinuxBIOS] google support: automatic build reports: HOWTO ?

[Stefan Reinauer]

* Paul Millar <paul at 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:
> 
> 1.  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.

> 2.  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.

> 3.  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)

> 4.  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. 

> 5.  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.

> 6.  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.

> 7.  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

> 8. 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

> 9. 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

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/