BIOS Autodetection Design

[Charles Esson]

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