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