[LinuxBIOS] google support: automatic build reports: HOWTO ?
stuge-linuxbios at cdy.org
Fri Mar 16 01:48:37 CET 2007
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
> 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.
More information about the coreboot