There is a forth, SUN use it, Apple uses it and freeBSD use it, it is part of the PCI spec and it comes with a IEEE standard. It spends a lot of time dealing with this issue, in a device and CPU independent way. OPENBOOT, IEEE Std 1275.
Why would anyone reinvent the wheel.
"Eric R. Kern" wrote:
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.
I'll give you a little help with sizing the chipset code since I have had some experience with this (I am a BIOS programmer for IBM's Commercial Desktop Division). Upon bootup of a system, there are many PCI configuration registers that need to be set to a certain value in order for the system to boot DOS (let alone a sophisticated operating system like Linux, Windows NT or Windows 98). These registers are generally set through a table early on in POST (Power On Self Test). The autodetecting BIOS would need to keep a table for every chipset that it detects. The tables for all of the chipsets that you want to support would fill any BIOS EEPROM on the market and you haven't even written one line of code yet.
I think I have a better design. There are generally three ways of modifying the BIOS on a computer. The first way is to pull the EEPROM off the mother board and "burn" an image using an EEPROM burner. The second way is to enable boot block recovery mode, put the desired flash image in the floppy drive (or whatever media that was preselected) and turn the computer on. (Boot block recovery mode is usually a jumper setting that runs a "bare bones" portion of BIOS in order to load the desired image.) The third way is through a flash utility.
The flash utility should run from DOS (or maybe Linux for you Linux fans out there). DOS is used since this utility is run at manufacturing time before an operating system has been loaded onto the harddrive and DOS fits nicely onto a floppy. My proposed design would have the system boot to a CDROM (more space and everyone has one) which boots DOS. The autodetection would be built into the flash utility. The chipset and other hardware detected by the flash utility would load the appropriate modules. These modules would then be put together to form a BIOS image and a table of pointers to each module would be created at a specified location in the image.
+------------------------+ FFFFh | Jmp Vector | +------------------------+ | Table of Pointers | +------------------------+ | North Bridge Config. | +------------------------+ | South Bridge Config. | +------------------------+ | Cache Configuration | +------------------------+ | Memory Configuration | +------------------------+ | ISA Configuration | +------------------------+ | PCI Configuration | +------------------------+ | Keyboard Controller | +------------------------+ | BIOS Functions (int 15)| +------------------------+ | Planar Hardware | +------------------------+ | Etc. | +------------------------+ E000h
Just a thought. Good luck.
Eric R. Kern