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

[Paul Millar]

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 at 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.
-------------- 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/20070315/9a0b0055/attachment.sig>