The DoC problem

[Eric W Biederman]

Ronald G Minnich <rminnich at lanl.gov> writes:

> On Mon, 9 Sep 2002, Hamish Guthrie (Mail Lists) wrote:
> 
> > I think the DoC mess is here to stay, there is one potential solution if
> > people are insisting on having DoC, and that is to make up a little board
> > which plugs into a BIOS socket which has both a 256k flash device and a
> > little bit of decode logic for a DoC, as well as a DoC - if anyone is
> > interested in this approach, I could knock together a few prototypes for a
> > couple of $'s, but I have my reservations as to this being a permanent
> > long-term solution for production systems.
> >
> 
> I was not clear but what I want is something that works for long-term
> production systems. It seems that DoC is unsuitable in the long term due
> to DoC limitations and M-systems lousy attitude.
> 
> I'm thinking in terms of what a company like cwlinux.com could ship to
> users. The IDE-FLASH would have to be either slave on the primary channel
> or master on the secondary channel. But wouldn't a slow IDE-FLASH on
> either channel make the other device run slowly? I thought this used to
> be the rule -- the IDE bus ran only as fast as the slowest device?

Long term you have to worry about the LPC bus.  So pins are not an
issue.  512KB is already available at a bootable address, larger chips
are likely to appear as more boards move over to the LPC bus.  Both
Intel and AMD chipsets already support it.  I don't know what recent
Via chipsets do but I would be very surprised if they didn't.

Etherboot proves how much functionality can be shoved into a small
space.  Right now I still don't need more than 64KB for a single copy
of LinuxBIOS and Etherboot.  So a dedicated firmware shell like
busybox has plenty of room to live.

I don't see not having a DOC as something to get hung up on.

Eric