[OpenBIOS] OpenBIOS: reality check

[Chia Tee-Kiah]

Hi.

> 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.

I'm quite new to this mailing list, and indeed I was a bit confused about what
was going on, but I would like to give some of my thoughts concerning the
above discussion...

I believe the main problem of today's BIOSes is that they're designed to run in
real mode. A protected mode OS will either have to switch to and from real and
protected mode to perform I/O (which isn't very neat, and incurs quite a lot
of execution overhead) or ignore the BIOS entirely and provide its own I/O
routines (which is a waste of coding effort). It'll be good if there's a BIOS
that can provide some sort of protected mode framework (possibly amounting to
a microkernel?) within which an OS can access BIOS services in true protected
mode. (Proprietary ROM BIOS extension cards will probably have to be modified
to fit into this scheme, but that's another story...)

-- 
 ___________________________________________________________________________
|                                                                           |
| Chia Tee-Kiah                              < mailto:teekiah at bigfoot.com > |
| http://wwp.mirabilis.com/8123598              http://teekiah.home.ml.org/ |
| pgp -kvc: 1024/89d8686d  0f f4 b4 d9 2e 12 c7 b2  1a 85 bc 12 8f 54 77 f1 |
|___________________________________________________________________________|

---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request at linkscape.net   Body: un/subscribe
Problems?  dcinege at psychosis.com