[LinuxBIOS] google support: automatic build reports: HOWTO ?
paul at astro.gla.ac.uk
Wed Mar 14 12:52:49 CET 2007
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).
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, 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
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.
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
Size: 189 bytes
Desc: not available
More information about the coreboot