On Thu, Mar 15, 2007 at 10:47:18PM +0000, Paul Millar wrote:
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.
Too big. Some FPGAs can be fitted in less space than a single 245. The BIOS savior is nearly too big for some boards. This thing needs to be very compact.
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?
I'm talking about "drowning" whatever signal comes from whoever is usually talking with a signal of our own.
PS2 modchips do this to inject code when the CPU reads from the BIOS flash. We want to do it the other way around. (Send our stuff to flash instead of what the northbridge wants to send.)
This may short circuit the output drivers of whatever chip was supposed to be talking (BIOS flash in PS2, northbridge in our case) and depending on how they are designed that can destroy them.
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.
Note SX2, not FX2. The SX2 is a plain USB interface chip that can push through a lot of data but is relatively stupid. FX2 is what you describe. I had scrapped the microcontroller because it's not really needed, a state machine is basically enough.
I intentionally aim beyond a DIY project because I don't think one could be made that is smaller than, or similar to, a BIOS savior, and that the extra features from the more advanced technology are worth the extra effort and cost. Manufacturing can be expensive but I think that if the group comes together we will be able to make a small run. (If we fail, perhaps we can find a corporate sponsor willing to help us with funding.)
I am by no means authoritative on this, if a super-cheap DIY alternative was available that would without a doubt be very useful!
We could then connect the card to the DIMM SMBus.
This idea has come up before and I think it's great, but some if not all memory controllers need a bit of setup before they can speak on the SMBus, which unfortunately shoots it down. :\
However:
If the CPU is executing code it must have read the code from ROM so the special-reads-make-a-debugwrite scheme has better chances to work out. (But it's not perfect, some architectures may not do byte reads from the ROM at all, only bursts, and a cache would also thwart this plan.)
For this to work, LinuxBIOS would (once the northbridge is configured) send
Doesn't work when debugging code for configuring the northbridge. ;)
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.
Well, since it's AC I would prefer to make a small box, but I firmly believe smaller is better for any gadget. :)
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.
I think Stefan meant monitoring the ATX voltages, 3V3, 5V, 12V. That's what I meant anyway. :)
165??? per board (plus board hardware)
Could work out even with the ATX power proxy.
Yup. The 8-bit controller are pretty expensive (~£10,???15).
Ouch, look for a new supplier. :) The simplest 8-bits shouldn't go for more than a few £/EUR even in single quantities. With more peripherals, of course price goes up. But rougly the same money can be spent on SX2+FPGA which makes for a tremendously powerful device.
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?
I meant when replacing the normal mainboard flash chip with the BIOS savior-like device, with two identical flash chips.
When the original flash can't be replaced it may need special support in the device. To get away from having to update the device we either create a command set that works for programming any flash, or require desoldering the original flash. The latter would stop many if not most developers from contributing. :\
But they can be soldered on too and SOIC SPI chips are always soldered on.
I don't know much about SPI, but isn't that a serial interface?
Yep, check out the SST25LF080A.
If we've got a parallel chip on our BIOS-replacer,
The small FPGAs don't have enough IO pins for that..
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?
Benefit of the FPGA; Just add an SPI block to it and you're (well, almost) done.
//Peter