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....