Re: BIOS Autodetection Design

[M Carling]

> > The objective is not to write OpenBIOS such that (in practice) a single
> > compiled image can boot any chipset. Rather, the autodetect objective is
> > that a set of chipsets may be chosen at compile time from which the image
> > is about to boot. Thus, for example, a MB manufacturer could compile a
> > BIOS such that one image would work for all the MBs that they manufacture.
> If this (compile time selection) is the objective, why call it autodetect? I
> would have thought from the name that one image fits all. Then, at run time
> it is autodetected, requiring all of the tables at once.

If someone chooses a set of chipsets at compile time, and then compiles
an image which can automatically detect which of those chipsets it on the
MB on which it finds itself running, why not call that autodetect? Do you
have a better name in mind for such functionality?

Note that the software architecture would not impose any particular limit
on the size of the set of chipsets for which support could be compiled in.
Rather the size of the image is the only constraining factor. I cannot think
of an application that would require a BIOS image that supports more than
a handfull of chipsets. MB manufacturers wouldn't need more than a handful,
home users wouldn't need more than a handful, and embedded systems builders
probably wouldn't need more than one. Who needs a BIOS compiled to run on
every machine?

M

BIOS Autodetection Design

[Matthew Sullivan]

M Carling wrote:
> > If this (compile time selection) is the objective, why call it autodetect? I
> > would have thought from the name that one image fits all. Then, at run time
> > it is autodetected, requiring all of the tables at once.
>
> If someone chooses a set of chipsets at compile time, and then compiles
> an image which can automatically detect which of those chipsets it on the
> MB on which it finds itself running, why not call that autodetect? Do you
> have a better name in mind for such functionality?
>
> Note that the software architecture would not impose any particular limit
> on the size of the set of chipsets for which support could be compiled in.
> Rather the size of the image is the only constraining factor. I cannot think
> of an application that would require a BIOS image that supports more than
> a handfull of chipsets. MB manufacturers wouldn't need more than a handful,
> home users wouldn't need more than a handful, and embedded systems builders
> probably wouldn't need more than one. Who needs a BIOS compiled to run on
> every machine?

But i think the original idea was to support old & new machines new machines only
a handful of configs - MB chipset wise...

Old machines though (back to 386's) would need a larg number due to the excessive
numbers of different chipsets.  However in this sineario -damn i can't speel- the
base support could probably be deturmined by the compiler (user) rather than
loading on all chipset support. ie: The user specifies an Intel *X based MB or
Intel RZ based MB, or CiC based MB etc.. and the BIOS takes care of the rest
etc....  That could even be done automagically by 'configure/make config' if you
want.

Yours

Mickey aka Matthew

PS I deliberately separated the RZ MB's cause some of you will probably know there
was a _LOT_ of bugs in the chipset - Source of info Linux source....