[OpenBIOS] What is the point, a new BIOS or utilities in ROM?

Chris Arguin cpa at hopper.unh.edu
Wed Feb 25 10:56:53 CET 1998


On Wed, 25 Feb 1998, Odd Skjaeveland wrote:

> A quick scan of historical postings makes me think the group would
> benefit from clearing up a few things.

True enough. We've argued out quite a few ideas, and on some of them the
dust may have settled without any clear understanding of what we should
do.

> There seems to be a demand for having certain functions in ROM. File
> system code has been mentioned, and also a boot loader of some kind to
> get rid of LILO.

The only reason, AFAIK, to have any filesystem code is to do the
bootloader that replaces LILO. The two go together.

> Making the BIOS be more than a BIOS would be a mistake in my opinion.
> The BIOS is sopposed to be the hardware abstraction layer, and I think
> it should be kept that way. 

I posted something like this before, and I agree with you to some extent.
The BIOS is a bit more, however. The BIOS, despite its name, is a
low-level hardware configuration, initialization, testing, and abstraction
layer.

Assuming we shadowed the BIOS (no big deal) and wrote all the hardware
abstraction in protected mode, then OSes like Linux could use BIOS calls
without any of the delay currently associated with BIOS calls. I think
that this is the "Right Way"

But no matter what, Linux will still have all the old drivers. Sure, we
can hack the kernel to have a "OpenBios" support, which will expect the
drivers to be in BIOS, but there will be plenty of people who will still
need the older drivers, so the Linux source will still have to have them.
Win95 won't be fixed in any hurry, unless Microsoft makes their own BIOS.
So even if it is the "Right Way", there may be no benefit from doing it.

> If we need a better BIOS, then we should build one. I think a
> discussion on BIOS topics and how we could improve it, would do us
> good.  Please don't confuse it with where the BIOS is stored. Pulling
> a new BIOS from disk after startup from a primitive ROM based BIOS, is
> ok. If the code is a hardware abstraction layer, it is still a BIOS.

This is true. But what if my harddrive crashes. Tradionally I could still
boot off of floppy. If critical sections of my BIOS were on that disk, I
would have to have a floppy with that BIOS code. It just starts to get a
little ugly.

I've argued that it could be done by keeping "extentions" on the disk, so
that the BIOS would just lose some features in the event of a harddrive
crash (and probably features you wouldn't use when doing emergency repair
work to the computer).

> If we would like to move code normally kept on disk to ROM, like
> putting file system code or a LILO-killer in ROM, then let us do so.
> But let us not make it part of the hardware abstraction layer code.

We've all agreed that the code should very modular. The BIOS currently
contains a very simple loader, and some of us just want to... fancy it up
a bit :)

 > So what are the goals? Putting file system code, a LILO-killer,
> networking software or other code in ROM because it is better than
> pulling it from disk? Or is it to build a better hardware abstraction
> layer? Or both?

Not just because it is better than pulling it from disk. If your machine
goes down, and it is headless, and the problem is, for example, the
seconday cache is bad, how do you fix it? You drive over to where the
machine is, connect up a monitor and keyboard, reboot the machine, enter
BIOS setup, and disable the cache. If the BIOS can work over the network,
all those steps go away.
 
> If I may suggest a utility that I think belongs in ROM rather than on
> disk: an improved memory test. Note, I did not say I think it should
> be part of the BIOS code, just that it should reside in ROM.

I think that one of the modules that a lot of people will want is a more
extensive bootup test, or maybe a secondary, optional, intensive test. 

> (ROM is, by the way, a pretty hopeless acronym because a read only
> memory is totally useless. Even PROM doesn't make any sense, how can
> one program a read only memory? If we'd known better back in the stone
> age, we would have called it a WORMM, write once read many memory, or
> something...)

> For the benefit of further discussions, I suggest we somehow make it
> clear wether we are talking about putting non-BIOS type of code in ROM
> or if we are talking about actual BIOS code.

Just like ROM is a bad choice of words, these days BIOS is also a bad
choice. BIOSes do a lot more than Basic Input/Output. They always have
done more, and now they do a lot more (and with modren OSes they don't do
much relating to their name).

 
--
Chris Arguin                 | "...All we had were Zeros and Ones -- And 
Chris.Arguin at unh.edu         |  sometimes we didn't even have Ones."
                             +--------------+	- Dilbert, by Scott Adams
http://leonardo.sr.unh.edu/arguin/home.html |


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



More information about the openbios mailing list