[OpenBIOS] OpenBIOS: reality check

[David Kennedy]

On Tue, 24 Feb 1998, Stefan Reinauer wrote:

> > A standard BIOS doesn't know about the file system, all it does is
> > load the first sector on the disk. The rest is up to the boot loader
> > of the operating system.
> 
> Wrong. Current BIOSs have a simple MSDOS system in their int-Code. MSDOS
> even doesn't have it's own filesystem code afaik..

According to all the BIOS code I have read, BIOSs do not have any
filesystem code.  As outlined before, all they  have  is  sector,
cylinder and head code.

> > This is generally based on a trial and error detection procedure
> > (set biggest possible size, then find out how many address bits
> > really work), rather than presence detect bits.
> 
> Again, modern PC Chipsets allow reading the exact RAM configuration out of
> their registers

Yes, in a proprietary way.

I  would  like to take this opportunity now to stop and as "Why?"
I'm sure it's been brought up, but I don't see the need to  rein-
vent  the wheel when it comes to BIOSs.  First off, don't all PCs
come with BIOSs?  Second, writing a generic BIOS that will encom-
pass  all  the  new  motherboards,  IMO, will be a wasted effort.
Aren't the majority of PC chipsets proprietary on  how  they  are
initialized for caching, memory configurations, et al?  Personal-
ly, I see this project as a waste of programming  power.   As  it
was  said  earlier,  the only forseeable benefit is to LILO (ini-
tially).  I don't see much support after  that  either,  unfortu-
nately.

The  idea  of replicating the BIOS programming interface is not a
worthy effort either, IMO.  Everyone agrees that it is old, ante-
quated, and kludged.  The idea of rewriting all the BIOS routines
anew without the legacy baggage is a good idea, but I don't think
that  you should "hide" the fact that you are doing it.  I think,
if you are going to rewrite the BIOS routines correctly, a unused
interrupt  vector  should  be chosen, and a completely new set of
routines should be written.  Or perhaps, simply  writing  a  com-
plete  set  of routines to be loaded overtop of the BIOS, so that
any programming wanting the GNU BIOS routines  would  simply  in-
clude  the  object file, and call a initialization routine or two
(provided of course they are taking complete control of the  sys-
tem).  Those are my ideas for the current project.

As  an offshoot from this project, I have an idea that I can per-
sonally use (or, more specifically, that I wanted to  use).   Ac-
cording to the documentation I have, memory locations from C8000h
to E0000h are checked at 2k intervals for the  sequence  "0xAA55"
If it is found, the next byte is a "length indicator representing
the number of 512-byte blocks in the ROM."  Following that  is  a
far  code entry point.  The entire ROM also has to be checksummed
modulo hex 100 and come up to 0.  I think this interface  can  be
used to produce a LILO of sorts that can replace the initial boot
loader.  A command line interface can be  supplied,  as  well  as
some  code  that  would  investigate the current hard drives, and
their partition tables.  This could produce a BIOS that is  simi-
lar  to many older "minicomputer" style BIOSs.  This interface is
checked after all of the initialization sequence occured, and be-
fore  any  bootstrapping.   That  way,  a more modern BIOS can be
written without the worry of compatibility between all  sorts  of
different  hardware.   This  has  other practical values as well.
Since every single PC in existance has a ISA bus, but not all PCs
have  the  same  BIOS chip (not even the same number of chips, or
the same number of pins), this allows  for  better  distribution.
It  allows faster development time, since you can easily remove a
card to boot the machine to a useable state again. (as opposed to
gerryrigging  some  sort  of  external platform with a mechanical
switch.)  Also, hardware illiterites  are  more  comfortable  in-
stalling  an  ISA  card,  as opposed to removing chips off of the
motherboard.

As  for  my  experience, I have been programming in Assembly lan-
guage for 7 years now, concentrating on low  level  VGA  program-
ming,  rudamentary  OS code, as well as custom cards.  I have two
BIOS listings, one is a 386+ BIOS  reverse  engineered  (obtained
freely  from  x2ftp.oulu.fi I believe).  The other is in the back
of the IBM Technical Reference Personal Computer AT, 1985.   This
code  is  original IBM BIOS code for the 286.  (Did you know that
they tested each register, conditional jumps and  the  BOUND  in-
struction?)

Whichever  way the project desides to go, I wouldn't mind helping
out.  I have experience in this area, and I would like  to  prac-
tice my skills in something, that might, quite possibly, do some-
thing, for someone, somewhere. ;)

-- 
David Kennedy
Vic/Linux and Pet/Linux: RPMs coming soon.