On Tue, 24 Feb 1998, Benjamin Scott wrote:
DK = David Kennedy
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
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
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
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"
- 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-
In short, we don't have much hope of fixing the
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. :)
Well, rudamentary filesystem code would be acceptible, I think.
Enough to find the kernel. How does other command line BIOSs do
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.
Vic/Linux and Pet/Linux: RPMs coming soon.
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe