[OpenBIOS] OpenBIOS: reality check

[Benjamin Scott]

DK = David Kennedy <dkennedy at engsoc.carleton.ca>
DK> A command line interface can be supplied, as well as some code that
DK> would investigate the current hard drives, and their partition
DK> tables.  This could produce a BIOS that is similar to many older
DK> "minicomputer" style BIOSs.

  Actually, it's similar to a lot of modern microcomputer style BIOSes,
too.  H/P, DEC, Sun, and SGI (well, SGI's is GUI, of course :) all have
some level of diagnostics and boot control in firmware.  Doing something
like those is one of the more frequent ideas that has appeared so far. 
:-)

DK> Since every single PC in existance has a ISA bus

  Actually, that is incorrect.  The ISA bus is fast becoming a thing of
the past.  Any modern system bridges the PCI bus to the core system bus,
and then bridges the ISA bus to the PCI bus.  That's at least two levels
of seperation between the ISA bus and the CPU.  Some systems are even
shipping with no ISA bus at all.  Microsoft's PC98 spec hints that ISA
should be phased out totally by the year 2000 or so.  So don't bet on
ISA being around in new systems.

  Of course, there are a huge number of older ISA systems that we
shouldn't ignore.

DK> not all PCs have  the  same  BIOS chip (not even the same number
DK> of chips, or the same number of pins), this allows for better 
DK> distribution.

  I think you're missing the key element of this effort: Flash ROM. 
This whole thing started because someone wrote a device driver for Linux
that lets you get at the flash ROM the BIOS is stored in.  The idea is
we write replacement BIOS code that the user (or OEM) will blow into
their flash ROMs.  We're not talking replacing actual chips.  Not for
the most part, anyway.  :-)

CA = Chris Arguin <chris.arguin at unh.edu>
CA> That is a good solution as well. With most of the proposals we
CA> have had, we have no use for the MBR anymore. Looking at the LILO
CA> docs, it looks like we have 446 bytes, assuming we leave the
CA> partition table intact... Not enough room to put in simple
CA> filesystem calls, I think. Too bad.

  I've been saying all along that if you're going to depend on something
on the disk, you might as well just write a better bootloader and forget
messing around with the BIOS.  OpenBIOS is going to be a lot of work,
and if we don't get some benefit out of it, it just isn't going to be
worth it.   And frankly, simply having the source to something that
usually only gets used to load a loader isn't worth it.  :-)

  You can quite easily do most everything, with the exception of a
totally diskless boot, by building a better bootloader.  That includes a
unified boot menu, filesystem support, network boot, Linux kernel
support, and whatever else floats your boat.  You can even add your own
custom hardware abstraction API if you want (NT does a cheesy version of
that now).  But it can all be done simply by creating a new primary
partition and putting your bootloader there (similar to IBM's Boot
Manager).

  If you don't want to spare the primary partition, you can do that,
too.  Leave some space unallocated to any partition at the start of your
disk.  Hack the MBR (that's what LILO does, after all) to load a
secondary bootloader stored in that unallocated space.  You can use as
much space for your boot loader as you need, then.

  I believe, that if we're going to go to the trouble of re-implementing
all the BIOS interrupt services (and we're going to have to make this at
all compatbile), in all its 16-bit real-mode glory, we should definately
plan on including advanced features like:
  - Network boot
  - Booting from any partition
  - Booting a Linux kernel directly
  - Filesystem support, so we can easily specify above Linux kernel
  - A powerful BIOS UI (most likely command-line driven)
  - Extended hardware diagnostics in flash ROM
  - Multi-option boot menu
  - Enhanced security

  Yes, they should all be user-selectable options, not forced upon
them.  And no, I don't know if any of these are actually possible.  But
that's the sort of thing I'm interested in.  :-)

  While the idea of implementing a whole new set of BIOS calls -- either
to be more powerful or faster, or to run in protected-mode -- sounds
appealing, it would be totally useless.  DOS won't use it because DOS
depends on the old calls, and runs mainly in real-mode anyway.  LILO and
other low-level bootloaders won't use it because they don't need to. 
Win95, NT, and Linux won't use it because they already bypass the BIOS
and use their own drivers.  The most we could hope to do is rewrite the
existing drivers and stick them in flash.  That just complicates things
needlessly.  It's easier to have those drivers in the OS to begin with.

  In short, we don't have much hope of fixing the basic "unintelligent"
nature of the PC hardware platform.  :-)

  If anyone can think of a *real* reason to create all those new BIOS
calls, then please, let me know.  :-)

CA> I tend to agree with you that it would be best to leave
CA> filesystem code out of the bios.

  I would really like to be able to boot a Linux kernel, specified by
partition and filename, without needing a intermediate bootloader.  But
that is me.  :)

					-- Ben <hawk at ttlc.net>


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