Re: Chipset autodetect -- pro and con

[John Foster]

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 
To: [e-mail]

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