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

Peter Stuge stuge-linuxbios at cdy.org
Thu Mar 15 20:37:49 CET 2007


On Thu, Mar 15, 2007 at 06:51:41PM +0100, Stefan Reinauer wrote:
> * todthgie <todthgie at 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




More information about the coreboot mailing list