A couple of ideas to consider - single all inclusive chipset support vs. modularized chipset specific builds: 1. The bios core is relatively stable 2. Chipsets keep changing 3. CPU platforms change over time - 386, 486, ........ 4. There are usually 2 or 3 places in the code where chipset initialization is called - usually very early in the code 5. Encountered these problems in the 16 bit bios over many iterations, finally arrived at a basic structure that included a chipset module. The chipset modules required some ASM and some C and some H code. Rather than create 3 files for a chipset, I created one file to keep the chipset info in a convenient place and then extracted the ASM,C, and H info into 3 temporary files when doing the build. 6. Did this about ten years ago using MS C and MASM - primitive but it works 7. MS H2INC utility is very nice - lets one use one H definition file for both C and MASM structures so they are always in sync with each other 8. A bios build was based on a configuration file (xxx.job) that defined variables for the build for a particular configuration 9. Separating the chipsets from the core code made it easier to debug developing new chipset code and to update core code - by allowing testing to verify core code on existing platforms 10. It also made creating new chipset code easier because it is all defined in one separate file.
BTW - the openbios.org domain has a temporary link to M's new pages - a bit of kludge so far - but we will work on getting this prettified and organized :-)
John
-----Original Message----- From: M Carling m@midgard.net To: openbios@elvis.informatik.uni-freiburg.de openbios@elvis.informatik.uni-freiburg.de Date: Sunday, November 29, 1998 9:13 PM Subject: 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