Chipset autodetect -- pro and con
There seems to be some disagreement over the issue of whether or not OpenBIOS should provide for possibility to compile into a single binary support for multiple chipset types to be autodetected at run-time. For OpenBIOS to be successful, it needs to become more attractive to the MB manufacturers than the alternatives. I don't know whether such a feature would be attractive to the MB manufacturers or not. I suggest will begin by compiling a list of the advantages and disadvantages of this feature. Having done that (so that we understand it ourselves as best we can) we should then ask the manufacturers. (This will be a good step toward getting free hardware from them for development.) When we ask them, we should also ask any other questions about their needs. In effect, we need to do some market research. Here are the advantages and disadvantages that I can think of. There are probably others. Pro: It's cool. It would allow manufacturers to have one BIOS ROM that supports all their MB products. The autodetect code might also be useful for diagnostics. Con: Extra complexity--something else to go wrong. Bug free code is *really* important in the BIOS. Extra complexity--more difficult to test. What other questions would we like the MB manufacturers to answer for us? M
> Too Big. Each chipset got it's own data and specs (don't forget we're > talking about 386, 486, LX, BX, VX, FX chipset and they got lots of > differences) - combining them all together will give a binary file that > will probably won't fit into the flash (not mentioning other features we > want to have). We aren't talking about compiling in support for all and every supported chipsets, just making it configurable, so one could add support for more chipsets in one binary, of course limited by size. This would for instance be nice for admins having a large pool of computers with two different motherboards. I think this is the answer to many discussions we will probably see: - Do we want a boot logo? - Should it support loading the kernel directly? - Should we support 16bit functions for compatibility - ... Make it configurable (tm) :) Karl Erik Asbjornsen karlea@samfundet.ntnu.no
I think it should DEFINETLTY need to be seperated.
heh, I think the opposite..
Why?
Too Big. Each chipset got it's own data and specs (don't forget we're talking about 386, 486, LX, BX, VX, FX chipset and they got lots of differences) - combining them all together will give a binary file that will probably won't fit into the flash (not mentioning other features we want to have).
I kind of doubt it will be too big. The amount of code to initialize the subsystems is NOT that large in comparison to something like the generic display and generic disk and various other generic systems. I can't see more than about 32-64k of code to support all of the above mentioned chipsets. I'm not a BIOS designer by trade but I *am* a designer of embedded systems. The code to handle the hardware is invariably much smaller than the code to handle the user. Why do I think it should be autodetect? simple: chipsets aren't THAT different. There is software out now which can differentiate between them fairly accurately. There are subtle differences which can increase performance and extra features of the individual chipsets but deep down they're all the same. Perhaps we will need to seperate 386, 486 and Pentium chipsets or perhaps a 386/486 and a Pentium* class BIOS but really that's about it I think. Autodetection is a really great idea in my opinion. Besides, you *don't* want the end user to look up our site because they think they're technical minded, download the wrong flash and boom, be dead in the water. We need bare minimum "generic" BIOS support to protect against this because no matter how hard we try, it *will* happen and OpenBIOS will be a black name, no matter how good it is. Andrew
I think it should DEFINETLTY need to be seperated. Why? Too Big. Each chipset got it's own data and specs (don't forget we're talking about 386, 486, LX, BX, VX, FX chipset and they got lots of differences) - combining them all together will give a binary file that will probably won't fit into the flash (not mentioning other features we want to have). -=-=-=-=-=-=-=-=-=-=- Hetz Ben Hamo ISDN Net Ltd. On Sun, 29 Nov 1998, M Carling wrote:
There seems to be some disagreement over the issue of whether or not OpenBIOS should provide for possibility to compile into a single binary support for multiple chipset types to be autodetected at run-time.
For OpenBIOS to be successful, it needs to become more attractive to the MB manufacturers than the alternatives. I don't know whether such a feature would be attractive to the MB manufacturers or not. I suggest will begin by compiling a list of the advantages and disadvantages of this feature. Having done that (so that we understand it ourselves as best we can) we should then ask the manufacturers. (This will be a good step toward getting free hardware from them for development.)
When we ask them, we should also ask any other questions about their needs. In effect, we need to do some market research.
Here are the advantages and disadvantages that I can think of. There are probably others.
Pro:
It's cool.
It would allow manufacturers to have one BIOS ROM that supports all their MB products.
The autodetect code might also be useful for diagnostics.
Con:
Extra complexity--something else to go wrong. Bug free code is *really* important in the BIOS.
Extra complexity--more difficult to test.
What other questions would we like the MB manufacturers to answer for us?
M
How about having a source tree, which allows chipset type config at compile time, keeping what's in the flash simple streamlined and efficient... Yours Mickey M Carling wrote:
There seems to be some disagreement over the issue of whether or not OpenBIOS should provide for possibility to compile into a single binary support for multiple chipset types to be autodetected at run-time.
For OpenBIOS to be successful, it needs to become more attractive to the MB manufacturers than the alternatives. I don't know whether such a feature would be attractive to the MB manufacturers or not. I suggest will begin by compiling a list of the advantages and disadvantages of this feature. Having done that (so that we understand it ourselves as best we can) we should then ask the manufacturers. (This will be a good step toward getting free hardware from them for development.)
When we ask them, we should also ask any other questions about their needs. In effect, we need to do some market research.
Here are the advantages and disadvantages that I can think of. There are probably others.
Pro:
It's cool.
It would allow manufacturers to have one BIOS ROM that supports all their MB products.
The autodetect code might also be useful for diagnostics.
Con:
Extra complexity--something else to go wrong. Bug free code is *really* important in the BIOS.
Extra complexity--more difficult to test.
What other questions would we like the MB manufacturers to answer for us?
M
We aren't talking about compiling in support for all and every supported chipsets, just making it configurable, so one could add support for more chipsets in one binary, of course limited by size. This would for instance be nice for admins having a large pool of computers with two different motherboards.
Ahh, it's much clearer now. But I don't think that could be called "auto-detect" since the binary file will have only small set of chipset support - so what can it detect? VX or FX chipset?
I think this is the answer to many discussions we will probably see: - Do we want a boot logo?
Yes, this should be cool (2 or 4 bit plane 128x128 or 256x256 compressed pic should do the trick).
- Should it support loading the kernel directly?
Optionally, but I guess there are some Windows 95/98/NT or OS/2 or BeOS who would like to use it also, so don't bind them together :)
- Should we support 16bit functions for compatibility
Oh yeah, unless you can come around with a genious way to remain compatible with current BIOS's and OS's..
- ... Make it configurable (tm) :)
Amen :)
Karl Erik Asbjornsen karlea@samfundet.ntnu.no
On Mon, 30 Nov 1998, Andrew Kohlsmith wrote:
I think it should DEFINETLTY need to be seperated.
heh, I think the opposite..
Why?
Too Big. Each chipset got it's own data and specs (don't forget we're talking about 386, 486, LX, BX, VX, FX chipset and they got lots of differences) - combining them all together will give a binary file that will probably won't fit into the flash (not mentioning other features we want to have).
I kind of doubt it will be too big. The amount of code to initialize the subsystems is NOT that large in comparison to something like the generic display and generic disk and various other generic systems. I can't see more than about 32-64k of code to support all of the above mentioned chipsets.
I'm not a BIOS designer by trade but I *am* a designer of embedded systems. The code to handle the hardware is invariably much smaller than the code to handle the user.
After alot of thinking about this I've come to the conclusion that I agree that there should be autodetection of chipsets. I have been reading some pciset documents from Intel, and as Andrew says there is really only smaller differences (between the PCI chipsets that is). But all this depends on one things; if it is possible to, with 100% accuracy, determine what chipset the BIOS is running on. If this is possible, is see no reason not to include autodetection. A wild guess is that the code for the various chipsets (all together) is not more then a couple of kB.
Why do I think it should be autodetect?
simple: chipsets aren't THAT different. There is software out now which can differentiate between them fairly accurately. There are subtle differences which can increase performance and extra features of the individual chipsets but deep down they're all the same.
Perhaps we will need to seperate 386, 486 and Pentium chipsets or perhaps a 386/486 and a Pentium* class BIOS but really that's about it I think. Autodetection is a really great idea in my opinion. Besides, you *don't* want the end user to look up our site because they think they're technical minded, download the wrong flash and boom, be dead in the water. We need bare minimum "generic" BIOS support to protect against this because no matter how hard we try, it *will* happen and OpenBIOS will be a black name, no matter how good it is.
Andrew
After alot of thinking about this I've come to the conclusion that I agree that there should be autodetection of chipsets. I have been reading some pciset documents from Intel, and as Andrew says there is really only smaller differences (between the PCI chipsets that is). But all this depends on one things; if it is possible to, with 100% accuracy, determine what chipset the BIOS is running on. If this is possible, is see no reason not to include autodetection. A wild guess is that the code for the various chipsets (all together) is not more then a couple of kB. Perhaps it's the best idea to make "chipset-addons", the end-user can choose the add-on and put it into the main-code, like in the Award- or AMI-Bios, modular.
A general Plugin-Interface with some Plugin-Types and a chipset interface. So openbios get's modular and has nearly infinite features, only limited to the amount of flash-memory. ;-) Ciao, Stephan
participants (7)
-
Andrew Kohlsmith -
Asbjoernsen＠atntr.telemax.no -
Hetz B.H (bios email) -
M Carling -
Matthew Sullivan -
Niklas Ekström -
Stephan Müller