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

Stefan Reinauer stepan at coresystems.de
Fri Mar 16 01:04:45 CET 2007


* Paul Millar <paul at 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?


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.dehttp://www.coresystems.de/




More information about the coreboot mailing list