can someone knowledgable tell us about those automated build reports on mainboards ? how does it work ? greetinx: --Q
Quux schrieb:
can someone knowledgable tell us about those automated build reports on mainboards ? how does it work ? greetinx: --Q
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
* 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.
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.
* 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
On Wed, Mar 14, 2007 at 05:44:12PM +0100, Stefan Reinauer wrote:
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.
No doubt the way to go.
//Peter
hello all,
sorry about the bad language in this mail, i dont have much time atm. I'm quite new to linuxbios(this is my first post to te list), but i find it realy interresting. in some time i will start to install it in some machines here starting whit the to be carpc. I'm more a hardware engineer that a software one (but i concider firmware almost hardware;-) ) and i think i can and maybe will design a (new) device for automated testing
This because i dont realy like to (hot) swap chips. and i think adding support for new board (i have not found one of my boards on the list) will not be done i a few builds. So the device for automated building can help greatly with the 'normal' devolopment.
but before i start designing i would like to have some input about what functions the device should have.
at this moment im thinking about the folowing:
- as a minimum savior like way to update the bios, but much better is this can be done remote im thinking about using the flash chip as a shared memory between a microcontroler and the motherboard (using tristable drivers for arbitrage) - have a usb to serial convertor so the test server can talk to the microcontroler. - maybe include a way to switch the mains voltage to the target computer - OR / AND inculde a way to switch off the remaining voltage (+5Vsb) of the atx power supply (this is easy) and prevent the mother board from switching on the atx PSU. - monitor at least some core functions of the target device (power supply voltage ect) to report state to the host. - maybe relay the serial debug console of the target to the host.
- of cource als schematics/layouts/Ucfirmware will be public. - i have no idea of i price yet. but i hope to come up with something that can do a lost for not too much money.
furthermore i would like to know what kind of bios chips are around on motherboards.. i know of the following:
Prom like flash devices in DIP or PLCC or SOIC packages that have Address, Data and Control (CE/RD/WR) busses Disk on Chip Millenium combo devices that combine a flash 'disk' with a 'bios'
Greetings Reinder de Haan The Netherlands
----- Original Message ----- From: "Peter Stuge" stuge-linuxbios@cdy.org To: linuxbios@linuxbios.org Sent: Wednesday, March 14, 2007 19:14 Subject: Re: [LinuxBIOS] google support: automatic build reports: HOWTO ?
On Wed, Mar 14, 2007 at 05:44:12PM +0100, Stefan Reinauer wrote:
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.
No doubt the way to go.
//Peter
-- linuxbios mailing list linuxbios@linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios
todthgie said: (by the date of Wed, 14 Mar 2007 20:37:52 +0100)
Hello Reinder de Haan,
your post to this mailing list seems very interesting. However, unfortunately, it is visible that you have no experience with mailing lists :)
I suggest you, to post your ideas again in a slightly corrected manner, and then it is very likely that you will get some interesting answers.
- write a correct subject line - do not answer to an existing thread (send a fresh email which starts a new thread) - describe your ideas a little bit more clear.
I'm sure that then you will have some interesting answers.
This etiquette is necessary, becaucase most of the people do skim through the subject lines, without reading what is inside. You replied to some other thread, and people interested in *that* particular thread are not interested in your *particular* problem. You want to addres all the people (not only the group of people interested in this thread). That's why you need to post a new topic with correct subject line :)
Hope this helps.
* todthgie todthgie@hotmail.com [070314 20:37]:
in some time i will start to install it in some machines here starting whit the to be carpc. I'm more a hardware engineer that a software one (but i concider firmware almost hardware;-) ) and i think i can and maybe will design a (new) device for automated testing
Sounds very interesting. I'd be glad to assist, but I am a hardware newbie, roughly understanding what a pull-up resistor is, but not able to read from the electrical specification when one is needed ;)
This because i dont realy like to (hot) swap chips. and i think adding support for new board (i have not found one of my boards on the list) will not be done i a few builds. So the device for automated building can help greatly with the 'normal' devolopment.
Yes indeed!
- as a minimum savior like way to update the bios, but much better is this can be done remote im thinking about using the flash chip as a shared memory between a microcontroler and the motherboard (using tristable drivers for arbitrage)
Yes, a completely external flash ability would be much preferred over the bios savior variant.
The BIOS savior hack starts the system, flashes the bios using ssh login, powers down and then starts the newly flashed system.
This is slow and at least in theory very error prone. It also means that you have to have a working bios at all, which is not necessarily always the case.
The alternative I know here are the PROMice devices, but they are 3000 bucks. Since I designed the system to do cheap automated distributed testing of 50-100+ motherboards, 3000*50 bucks (even with a decent volume discount) would be far beyound what such a project could bear with. Building a single "IOC" as I did is below 10€, and a bios savior was between 10 and 30 eur, so that is roughly a factor 100 below the costs of a promice.
Using the same device for development and testing would be a great additional advantage of course.
Plugging such a microcontroller onto a soldered on flash chip with a plcc piggyback clip or a plcc socket/plug combination would make an additional flash chip unnecessary, and allow the device to be ultimately used.
A lot of equipment in this category is parport driven, which is extremely bad for people like me with only their legacy free laptop with lots of USB ports.
- have a usb to serial convertor so the test server can talk to the
microcontroler.
Sounds good. Or it could use a microcontroller with usb built in. No idea which of them would be suitable for such a project.
- maybe include a way to switch the mains voltage to the target computer
- OR / AND inculde a way to switch off the remaining voltage (+5Vsb) of the
atx power supply (this is easy) and prevent the mother board from switching on the atx PSU.
Triggering both the atx power button, reset button, real power supply, would be cool. No idea if the real power plugging would be expensive to add. I used an IPS-400 for that goal, but it costs 400 bucks for 4 ports --> expensive.
- monitor at least some core functions of the target device (power supply
voltage ect) to report state to the host.
Yes! Maybe even frequencies if that is easily possible?
- maybe relay the serial debug console of the target to the host.
by addin another usb->serial converter and a hub? that would be neat. Because the system needs a serial cable for each test system.
another idea would be to detect host writes to the bios chip or some other memory area and interpret that as console. This is interesting for those boards that have no serial port anymore. We used a USB debug device for some of those (80$) but not all boards have debug capable USB controllers.
- of cource als schematics/layouts/Ucfirmware will be public.
- i have no idea of i price yet. but i hope to come up with something that
can do a lost for not too much money.
The hardware requirement for testing a mainboard are roughly
* 25€ for the bios savior * 10€ for the IOC * 100€ for 1/4 of the power switch * 10€ for a serial to usb converter * 10€ for a USB hub * 10€ for cabling (usb, serial null modem) --- 165€ per board (plus board hardware)
This should be well in the range of the production costs of a decent microcontroller based solution.
furthermore i would like to know what kind of bios chips are around on motherboards.. i know of the following:
Prom like flash devices in DIP or PLCC or SOIC packages that have Address, Data and Control (CE/RD/WR) busses Disk on Chip Millenium combo devices that combine a flash 'disk' with a 'bios'
DoC (Millenium) is usually not used anymore. There's a couple of PLCC LPC and FWH chips that are normally used.
SST49LF040 for example, or Intel N82802AC, Winbond W49F002UP, Winbond W39SFsomething.
Stefan
On Thu, Mar 15, 2007 at 06:51:41PM +0100, Stefan Reinauer wrote:
- todthgie todthgie@hotmail.com [070314 20:37]:
in some time i will start to install it in some machines here starting whit the to be carpc. I'm more a hardware engineer that a software one (but i concider firmware almost hardware;-) ) and i think i can and maybe will design a (new) device for automated testing
Sounds very interesting. I'd be glad to assist, but I am a hardware newbie, roughly understanding what a pull-up resistor is, but not able to read from the electrical specification when one is needed ;)
I've been chatting about building something similar. I have some ideas for components but haven't had time to sit down and put it together yet. Also I've been thinking about clever ways to support parallell, LPC and SPI in the same device, but parallell is 5V and causes some trouble since all modern chips run at 3V3 and many can't handle 5V data.
- as a minimum savior like way to update the bios, but much better
is this can be done remote im thinking about using the flash chip as a shared memory between a microcontroler and the motherboard (using tristable drivers for arbitrage)
Yes, a completely external flash ability would be much preferred over the bios savior variant.
This is a must.
Plugging such a microcontroller onto a soldered on flash chip with a plcc piggyback clip or a plcc socket/plug combination would make an additional flash chip unnecessary, and allow the device to be ultimately used.
I think we want to experiment with this to see what we can expect to work. It would be neat, I know it's done in some systems (PS2 modchips) but I don't know how well PC chipsets would cope.
A lot of equipment in this category is parport driven, which is extremely bad for people like me with only their legacy free laptop with lots of USB ports.
USB is a given IMO. It has good bandwidth, availability and power.
- have a usb to serial convertor so the test server can talk to
the microcontroler.
Sounds good. Or it could use a microcontroller with usb built in. No idea which of them would be suitable for such a project.
My idea is a EZ-USB SX2 and a CPLD or FPGA. No need for a separate micro, if one is absolutely neccessary it could live in the FPGA.
- maybe include a way to switch the mains voltage to the target
computer
This is a good idea.
- OR / AND inculde a way to switch off the remaining voltage
(+5Vsb) of the atx power supply (this is easy) and prevent the mother board from switching on the atx PSU.
Triggering both the atx power button, reset button, real power supply, would be cool.
Yep, I want this too, and it's dirt simple.
No idea if the real power plugging would be expensive to add. I used an IPS-400 for that goal, but it costs 400 bucks for 4 ports --> expensive.
I'd say $15 for a relay that controls line power and the IEC connectors. The power switch should be optional, or at least detachable, for convenience.
- monitor at least some core functions of the target device
(power supply voltage ect) to report state to the host.
Yes! Maybe even frequencies if that is easily possible?
Voltage and current is easy enough, frequencies not.
We'd do this with an ATX power connector proxy board. Monitoring is simple, controlling requires more expensive components so should be optional.
- maybe relay the serial debug console of the target to the host.
by addin another usb->serial converter and a hub? that would be neat. Because the system needs a serial cable for each test system.
Right. This is called a composite USB device. But on the other hand it's much cheaper to get a separate serial->USB cable.
another idea would be to detect host writes to the bios chip or some other memory area and interpret that as console. This is interesting for those boards that have no serial port anymore. We used a USB debug device for some of those (80$) but not all boards have debug capable USB controllers.
Yes, this feature is also a must IMO.
- of cource als schematics/layouts/Ucfirmware will be public.
- i have no idea of i price yet. but i hope to come up with something that
can do a lost for not too much money.
The hardware requirement for testing a mainboard are roughly
- 25??? for the bios savior
- 10??? for the IOC
- 100??? for 1/4 of the power switch
- 10??? for a serial to usb converter
- 10??? for a USB hub
10??? for cabling (usb, serial null modem)
165??? per board (plus board hardware)This should be well in the range of the production costs of a decent microcontroller based solution.
Could work out even with the ATX power proxy.
furthermore i would like to know what kind of bios chips are around on motherboards.. i know of the following:
Prom like flash devices in DIP or PLCC or SOIC packages that have Address, Data and Control (CE/RD/WR) busses Disk on Chip Millenium combo devices that combine a flash 'disk' with a 'bios'
DoC (Millenium) is usually not used anymore. There's a couple of PLCC LPC and FWH chips that are normally used.
SST49LF040 for example, or Intel N82802AC, Winbond W49F002UP, Winbond W39SFsomething.
SPI flash (SST25LF080A) is the next variant.
Parallell flash is only for old boards but would be nice to support as well, if we're going to put this together.
I think the best thing is to put a 8/16Mbit flash (or two) onto the device and just do away with (save on a shelf) the original flash chip. That way we don't need to implement support for more than a few chips.
Socketed PLCC and DIP is easy enough.
But they can be soldered on too and SOIC SPI chips are always soldered on. We want to work with those chips too if at all possible so we should investigate how/if chipsets typically survive short circuits on their flash IO pins.
//Peter
On 15.03.2007 20:37, Peter Stuge wrote:
On Thu, Mar 15, 2007 at 06:51:41PM +0100, Stefan Reinauer wrote:
Plugging such a microcontroller onto a soldered on flash chip with a plcc piggyback clip or a plcc socket/plug combination would make an additional flash chip unnecessary, and allow the device to be ultimately used.
I think we want to experiment with this to see what we can expect to work. It would be neat, I know it's done in some systems (PS2 modchips) but I don't know how well PC chipsets would cope.
Would be great if this works out.
another idea would be to detect host writes to the bios chip or some other memory area and interpret that as console. This is interesting for those boards that have no serial port anymore. We used a USB debug device for some of those (80$) but not all boards have debug capable USB controllers.
Yes, this feature is also a must IMO.
Agreed.
Regards, Carl-Daniel
On Thursday 15 March 2007 19:37, Peter Stuge wrote:
On Thu, Mar 15, 2007 at 06:51:41PM +0100, Stefan Reinauer wrote:
- todthgie todthgie@hotmail.com [070314 20:37]:
- as a minimum savior like way to update the bios, but much better
is this can be done remote [...] shared memory between a microcontroler and the motherboard (using tristable drivers for arbitrage)
[...]
I guess something like three octal bus transceivers (e.g. 75HC245) for the logic and something a bit more clever for the power lines.
Plugging such a microcontroller onto a soldered on flash chip with a plcc piggyback clip or a plcc socket/plug combination would make an additional flash chip unnecessary, and allow the device to be ultimately used.
I think we want to experiment with this to see what we can expect to work. It would be neat, I know it's done in some systems (PS2 modchips) but I don't know how well PC chipsets would cope.
Showing my ignorance here, but wouldn't the flash need to be tri-stated from the mobo for burning? If the mobo support this anyway (as I guess the PS2 must) then we're in luck; but can we assume this will be true for all test platforms?
A lot of equipment in this category is parport driven, which is extremely bad for people like me with only their legacy free laptop with lots of USB ports.
USB is a given IMO. It has good bandwidth, availability and power.
[...]
My idea is a EZ-USB SX2 and a CPLD or FPGA. No need for a separate micro, if one is absolutely neccessary it could live in the FPGA.
As a design goal, I think we should avoid components that require external devices (e.g. chip/FPGA burners). The 8051-based controllers (like EZ-USB) will accept uploading of firmware via USB (see fxload program). Devices like FPGAs need external hardware to burn the image.
I was looking at EZ-USB too, but was favouring an AVR-based chip (if we can get ones that don't need external burner). The reason being that the Cypress/EZ-USB chip I2C interface only works in master-mode whereas some of the AVR chips have (through the TWI interface) support for I2C in slave mode.
[the next bit is a crazy idea, which I'm quite prepared for more knowledgable people to shoot it down ;-]
We could then connect the card to the DIMM SMBus. This could be either directly wired onto one of the memory DIMM roms or use a suitable blank to tap the SMBus signals. This idea came from reading the LM-sensor's fun page, see: http://lm-sensors.org/wiki/HardwareHacking
For this to work, LinuxBIOS would (once the northbridge is configured) send out a byte-stream over the memory SMBus to some fictitious or reserved address. Normally this would do nothing, but the interface card would pick up these signals and relay them to the test machine via the USB interface.
The byte-stream could be a predefined set of patterns (like with POST cards) or could be the console output (or both). If a machine/LinuxBIOS-image pair failed to boot, the test machine would know the last codes it received. This would hopefully bracket the point where the machine froze.
[...]
No idea if the real power plugging would be expensive to add. I used an IPS-400 for that goal, but it costs 400 bucks for 4 ports --> expensive.
I'd say $15 for a relay that controls line power and the IEC connectors. The power switch should be optional, or at least detachable, for convenience.
This is probably window-dressing (and probably obvious, too), but it would be nice to package this roughly in-line, i.e. a plug and socket back-to-back, plus some kind of connector (a simple jack-socket for example) that accepts a TTL signal. That way you could plug it into anything.
[...]
Voltage and current is easy enough, frequencies not.
We'd do this with an ATX power connector proxy board. Monitoring is simple, controlling requires more expensive components so should be optional.
Agreed, although I'd say that voltage monitoring isn't critical for the job. AFAIK, a switching-mode psu should cope with most (roughly constant RMS) voltages above ~100V. (If we plug the test-control machine into the same power-supply, then we have a primitive test for power outages: can we ICMP-ping the test-controller? ;-)
another idea would be to detect host writes to the bios chip or some other memory area and interpret that as console. This is interesting for those boards that have no serial port anymore. We used a USB debug device for some of those (80$) but not all boards have debug capable USB controllers.
Yes, this feature is also a must IMO.
(c.f. the DIMM/SMBus idea above)
[...]
165??? per board (plus board hardware)
This should be well in the range of the production costs of a decent microcontroller based solution.
Could work out even with the ATX power proxy.
Yup. The 8-bit controller are pretty expensive (~£10,€15). Their evaluation boards (with some nice interfacing) often come in at about ~£15 (€22). Bits and bobs beyond that will push up the price (£7,€10 relay?), but I'd hope not too much!
[...]
I think the best thing is to put a 8/16Mbit flash (or two) onto the device and just do away with (save on a shelf) the original flash chip. That way we don't need to implement support for more than a few chips.
Just to confirm, would the plan here be to have a "standard" flash chip (we pick one) on a standard board?
One would connect the chip's address, data and power lines (through the tri-state buffers) to a smaller header board, which would have the right pins to mate with whatever socket is on the mobo.
The main-board (with the flash chip) would be always the same, but we'd need designs for a selection of header boards to cover the different chip/sockets pairs.
Socketed PLCC and DIP is easy enough.
But they can be soldered on too and SOIC SPI chips are always soldered on. We want to work with those chips too if at all possible so we should investigate how/if chipsets typically survive short circuits on their flash IO pins.
I don't know much about SPI, but isn't that a serial interface?
If we've got a parallel chip on our BIOS-replacer, would we not need another chip (a SPI one) to support a mobo that uses a (SOIC) SPI BIOS, along with additional tri-state circuitry?
Cheers,
Paul.
* Paul Millar paul@astro.gla.ac.uk [070315 23:47]:
I think we want to experiment with this to see what we can expect to work. It would be neat, I know it's done in some systems (PS2 modchips) but I don't know how well PC chipsets would cope.
Showing my ignorance here, but wouldn't the flash need to be tri-stated from the mobo for burning? If the mobo support this anyway (as I guess the PS2 must) then we're in luck; but can we assume this will be true for all test platforms?
That's what I think, too.For not-tristated motherboards, does this mean we can not flash while the board is running, or will we risk destroying the mainboard even by attempting a flash while is is powered off?
Many memory emulators (like the PROMice) require that you "keep the machine in reset" while updating the emulated flash memory. But I figured that's a different situation because it's not a real flash chip but a lot more logic between the host and the target.
As a design goal, I think we should avoid components that require external devices (e.g. chip/FPGA burners). The 8051-based controllers (like EZ-USB) will accept uploading of firmware via USB (see fxload program). Devices like FPGAs need external hardware to burn the image.
Oh, can't the FPGA be loaded via software? I think that's possible with some of them at least. Maybe we can use the uC to push the FPGA software over the USB line? (just dreaming of a perfect world)
I was looking at EZ-USB too, but was favouring an AVR-based chip (if we can get ones that don't need external burner). The reason being that the Cypress/EZ-USB chip I2C interface only works in master-mode whereas some of the AVR chips have (through the TWI interface) support for I2C in slave mode.
I have a GalepIV here, and it can burn about every chip I know of. I will gladly offer to burn chips if someone helps by designing a PCB around it :-)
I think the best thing is to put a 8/16Mbit flash (or two) onto the device and just do away with (save on a shelf) the original flash chip. That way we don't need to implement support for more than a few chips.
Just to confirm, would the plan here be to have a "standard" flash chip (we pick one) on a standard board?
Would using an own flashchip not mean that you have to desolder at least parts of the onboard flash chip or cut pins? How complicated would that be? Or is such a device just not possible for soldered flash chips due to the missing tri-states?
The main-board (with the flash chip) would be always the same, but we'd need designs for a selection of header boards to cover the different chip/sockets pairs.
ironwood electronics has a lot of those headers.
I don't know much about SPI, but isn't that a serial interface?
yes.
If we've got a parallel chip on our BIOS-replacer, would we not need another chip (a SPI one) to support a mobo that uses a (SOIC) SPI BIOS, along with additional tri-state circuitry?
I think so, too.
I'd actually prefer a solution that does not require any flashchip except the one on the mainboard. Flash chip data sheets are available, so we could easily support them in that solution. Maybe we can even use drivers from flashrom?
On Fri, Mar 16, 2007 at 01:04:45AM +0100, Stefan Reinauer wrote:
does this mean we can not flash while the board is running, or will we risk destroying the mainboard even by attempting a flash while is is powered off?
Right, this will depend on what the flash is connected to.
Many memory emulators (like the PROMice) require that you "keep the machine in reset" while updating the emulated flash memory. But I figured that's a different situation because it's not a real flash chip but a lot more logic between the host and the target.
Could be a requirement from the PROMice that the target not accesses it while it's being programmed. Could also just be good advice so you don't get confused when the target executes the code before it has been downloaded fully.
Oh, can't the FPGA be loaded via software? I think that's possible with some of them at least.
Most are flash nowadays and can be reprogrammed via JTAG.
Maybe we can use the uC to push the FPGA software over the USB line? (just dreaming of a perfect world)
Management interfaces are nice. This is a good reason to add a microcontroller! A tiny one with just a few IOs is enough. Updating the device could take a few minutes, but it would always work.
I will gladly offer to burn chips if someone helps by designing a PCB around it :-)
And this is where I'm held in reset. I know how I want it to work but don't have time. :( If someone else beats me to it that's of course great!
Would using an own flashchip not mean that you have to desolder at least parts of the onboard flash chip or cut pins?
I was thinking primarily of the socketed situation. But yes, for soldered flashes this is quite right.
How complicated would that be?
Too complicated for it to be fun.
Or is such a device just not possible for soldered flash chips due to the missing tri-states?
Maybe. It needs to be investigated.
AMD: Is it OK to take a completely unpowered board, apply 3V3 to the flash ROM chip from an external source and then drive the flash ROM signals from the same external source? Can the 81(31)1 handle this or will it break?
Does anyone know if the nVidia chipset can handle it?
I'd actually prefer a solution that does not require any flashchip except the one on the mainboard. Flash chip data sheets are available, so we could easily support them in that solution. Maybe we can even use drivers from flashrom?
For full speed our device does all the talking to the flash, so it would need to know how to talk to each type. Ie. re-implement the flashrom drivers in VHDL. :\ Not a lot of work, but needs to be done. Maybe it would be possible to abstract the JEDEC command set and create a "scripting language" for how the device should speak to the flash. That is fairly future proof and still fast.
//Peter
On Thu, Mar 15, 2007 at 10:47:18PM +0000, Paul Millar wrote:
shared memory between a microcontroler and the motherboard (using tristable drivers for arbitrage)
I guess something like three octal bus transceivers (e.g. 75HC245) for the logic and something a bit more clever for the power lines.
Too big. Some FPGAs can be fitted in less space than a single 245. The BIOS savior is nearly too big for some boards. This thing needs to be very compact.
Plugging such a microcontroller onto a soldered on flash chip with a plcc piggyback clip or a plcc socket/plug combination would make an additional flash chip unnecessary, and allow the device to be ultimately used.
I think we want to experiment with this to see what we can expect to work. It would be neat, I know it's done in some systems (PS2 modchips) but I don't know how well PC chipsets would cope.
Showing my ignorance here, but wouldn't the flash need to be tri-stated from the mobo for burning? If the mobo support this anyway (as I guess the PS2 must) then we're in luck; but can we assume this will be true for all test platforms?
I'm talking about "drowning" whatever signal comes from whoever is usually talking with a signal of our own.
PS2 modchips do this to inject code when the CPU reads from the BIOS flash. We want to do it the other way around. (Send our stuff to flash instead of what the northbridge wants to send.)
This may short circuit the output drivers of whatever chip was supposed to be talking (BIOS flash in PS2, northbridge in our case) and depending on how they are designed that can destroy them.
A lot of equipment in this category is parport driven, which is extremely bad for people like me with only their legacy free laptop with lots of USB ports.
USB is a given IMO. It has good bandwidth, availability and power.
[...]
My idea is a EZ-USB SX2 and a CPLD or FPGA. No need for a separate micro, if one is absolutely neccessary it could live in the FPGA.
As a design goal, I think we should avoid components that require external devices (e.g. chip/FPGA burners). The 8051-based controllers (like EZ-USB) will accept uploading of firmware via USB (see fxload program). Devices like FPGAs need external hardware to burn the image.
I was looking at EZ-USB too, but was favouring an AVR-based chip (if we can get ones that don't need external burner). The reason being that the Cypress/EZ-USB chip I2C interface only works in master-mode whereas some of the AVR chips have (through the TWI interface) support for I2C in slave mode.
Note SX2, not FX2. The SX2 is a plain USB interface chip that can push through a lot of data but is relatively stupid. FX2 is what you describe. I had scrapped the microcontroller because it's not really needed, a state machine is basically enough.
I intentionally aim beyond a DIY project because I don't think one could be made that is smaller than, or similar to, a BIOS savior, and that the extra features from the more advanced technology are worth the extra effort and cost. Manufacturing can be expensive but I think that if the group comes together we will be able to make a small run. (If we fail, perhaps we can find a corporate sponsor willing to help us with funding.)
I am by no means authoritative on this, if a super-cheap DIY alternative was available that would without a doubt be very useful!
We could then connect the card to the DIMM SMBus.
This idea has come up before and I think it's great, but some if not all memory controllers need a bit of setup before they can speak on the SMBus, which unfortunately shoots it down. :\
However:
If the CPU is executing code it must have read the code from ROM so the special-reads-make-a-debugwrite scheme has better chances to work out. (But it's not perfect, some architectures may not do byte reads from the ROM at all, only bursts, and a cache would also thwart this plan.)
For this to work, LinuxBIOS would (once the northbridge is configured) send
Doesn't work when debugging code for configuring the northbridge. ;)
I'd say $15 for a relay that controls line power and the IEC connectors. The power switch should be optional, or at least detachable, for convenience.
This is probably window-dressing (and probably obvious, too), but it would be nice to package this roughly in-line, i.e. a plug and socket back-to-back, plus some kind of connector (a simple jack-socket for example) that accepts a TTL signal. That way you could plug it into anything.
Well, since it's AC I would prefer to make a small box, but I firmly believe smaller is better for any gadget. :)
Voltage and current is easy enough, frequencies not.
We'd do this with an ATX power connector proxy board. Monitoring is simple, controlling requires more expensive components so should be optional.
Agreed, although I'd say that voltage monitoring isn't critical for the job. AFAIK, a switching-mode psu should cope with most (roughly constant RMS) voltages above ~100V.
I think Stefan meant monitoring the ATX voltages, 3V3, 5V, 12V. That's what I meant anyway. :)
165??? per board (plus board hardware)
Could work out even with the ATX power proxy.
Yup. The 8-bit controller are pretty expensive (~£10,???15).
Ouch, look for a new supplier. :) The simplest 8-bits shouldn't go for more than a few £/EUR even in single quantities. With more peripherals, of course price goes up. But rougly the same money can be spent on SX2+FPGA which makes for a tremendously powerful device.
I think the best thing is to put a 8/16Mbit flash (or two) onto the device and just do away with (save on a shelf) the original flash chip. That way we don't need to implement support for more than a few chips.
Just to confirm, would the plan here be to have a "standard" flash chip (we pick one) on a standard board?
I meant when replacing the normal mainboard flash chip with the BIOS savior-like device, with two identical flash chips.
When the original flash can't be replaced it may need special support in the device. To get away from having to update the device we either create a command set that works for programming any flash, or require desoldering the original flash. The latter would stop many if not most developers from contributing. :\
But they can be soldered on too and SOIC SPI chips are always soldered on.
I don't know much about SPI, but isn't that a serial interface?
Yep, check out the SST25LF080A.
If we've got a parallel chip on our BIOS-replacer,
The small FPGAs don't have enough IO pins for that..
would we not need another chip (a SPI one) to support a mobo that uses a (SOIC) SPI BIOS, along with additional tri-state circuitry?
Benefit of the FPGA; Just add an SPI block to it and you're (well, almost) done.
//Peter
-
Carl-Daniel Hailfinger -
Janek Kozicki -
Paul Millar -
Peter Stuge -
Quux -
Stefan Reinauer -
todthgie