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

Paul Millar paul at astro.gla.ac.uk
Wed Mar 14 12:52:49 CET 2007

Hi Stefan,

On Tuesday 13 March 2007 09:18, Stefan Reinauer wrote:
> * Quux <pawn2be.wild at yahoo.de> [070313 06:38]:
> > for starters, there is
> > http://www.linuxbios.org/Distributed_and_Automated_Testsystem
> > of course. So, putting together the circuit for remote boot is a
> > requirement, yes ?  --Q
> Yes, pretty much. If we get a couple of systems for the test system,
> we could have a decent PCB manufactured, but for 1 or 2 it's probably
> too expensive.

I've had a look at the QA slides and have had a quick flick through the two 
manuals (all linked from the above URL).  I've a few questions, although I 
must confess to not much experience with electronics: some of the questions 
are probably obvious to everyone else...

Slide 13 shows a schematic containing a CP2102.  This looks like its accepts a 
USB connection (from test supervisor host) and outputs a normal collection of 
serial lines (for the machine that is to be tested).

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?

2.  Looking at the CP2102 data sheets[1], it looks like it takes it power from 
the USB bus, is this correct?
(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)


3.  The slide also says "two IO ports".  Are these the two opto-isolated 

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)?

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.

6.  The two ILD621s are really just output ports, right?  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.

7.  I don't think the docs say this explicitly, so I'm guessing the test cycle 
	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?

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

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070314/7708f268/attachment.sig>

More information about the coreboot mailing list