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