[OpenBIOS] OpenBIOS: reality check

[David Kennedy]

On Tue, 24 Feb 1998, Benjamin Scott wrote:

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

Yes.  I put "minicomputer" in quotes because I wasn't sure of the
correct term to use (with the dozens that are floating around).

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

Hmm...  I certainly hope that I never get a system without an ISA
bus.  I have way too many specialty cards that require it.

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

Definately.

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

Ah..  ok..  But  the  problem, again, that I see with this is the
fact that you are going to replace the proprietary initialization
code  with  a, hopefully compatible, generic initialization code.
With the dozen or so PC chipsets out there, can all these differ-
ent versions of the initialization code be effectively created?

>   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

This  one has been done over and over.  But it's done with a BIOS
chip on the network card using the technique I discussed  before.
Again,  because  of  the multitude of network boards, I forsee it
being very difficult to offer this in a generic BIOS.

>   - Booting from any partition

This  is  a rather easy extension.  But the more important one is
to boot off of any controller type (SCSI, EIDE, ...)

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

Actually,  all BIOSs (to my knowledge anyway) have extended hard-
ware diagnostics.  The problem is that  nobody  knows  about  it.
The BIOS outputs sequential numbers out to a specific port, anal-
ogous to the lights on the back of a Sun4, or on the front of  an
Apollo.   A POST card can be obtained which will list the numbers
as they arrive.  Also, if an error occurs, it  displays  extended
information  that  is send over the port.  Of course, it would be
better to have it display to  the  screen,  but  relying  on  the
screen to work might be too much to ask.

>   - Multi-option boot menu
>   - Enhanced security

Unfortunately,  enhanced  security is not feasable, especially if
someone reaches into  the  case  and  jumpers  the  "clear  CMOS"
jumper.

	- Headless booting

I  would  spend  good  money on a machine that can boot without a
graphics card, and a keyboard.  That way, two wires come out  the
back, and the machine has room for all of my custom ISA cards.

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

I don't see a need to reimplement all of those calls either.  Es-
pecially since most of them are kludged anyway.   Rewriting  them
to  new specs (in 386 Protected mode) could get rid of code bloat
in the Linux kernel, and could pave the way for some tiny  embed-
ded OSs.

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

Yup. :)

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

Well,  rudamentary  filesystem code would be acceptible, I think.
Enough to find the kernel.  How does other command line BIOSs  do
it?

I  can tell my posts are more negative than positive, but I'm not
interested in bashing the idea.  I'm  interested  in  getting  an
idea that won't be fruitless, and if people let their imagination
run wild (especially in the realm of the PC BIOS),  a  completely
useless,  really  expensive  (time wise that is) project will re-
sult.  Or that's the way I see it.

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



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