Hi Stefan,
On Tuesday 13 March 2007 09:18, Stefan Reinauer wrote:
- Quux pawn2be.wild@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)
[1] http://www2.silabs.com/public/documents/tpub_doc/dsheet/Microcontrollers/Int...
3. The slide also says "two IO ports". Are these the two opto-isolated ILD621s?
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 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?
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.
Cheers,
Paul.