[OpenBIOS] More comments and a proposal for priorities

[Benjamin Scott]

CA = Chris Arguin 
CA> Of course this is something important to remember, I'm no sure
CA> everything on this list falls into that category. Why should the
CA> BIOS reconize the DOS filesystem?

For the built-in Linux bootloader, mainly.  You might also be able to
add support for booting NT directly, eliminating one more stage of menus
from the boot process.  Yes, I realize what NT is, but just because
Microsoft refuses to admit other OSes exist doesn't mean *we* shouldn't
do a good job.  :)

CA> Changes? You rewrote the whole thing! :)

Picky picky.  :)

CA> Seriously, I was figuring support for it more for the serial
CA> console stuff. We also need VGA and RS232 support, for the output.

Yeah.  Let us just have a drivers/ tree, which has all your device
drivers.  Make it all as modular as possible, so we can add new drivers
and driver categories later on, and so that we can use the drivers for
whatever we need to (console I/O, boot I/O, whatever).

How much of a chance is there that we can incorporate the Linux device
drivers directly into the BIOS, like Alpha/MILO does?

AW = Adam Wiggins 
AW> I'd like to add rescue/ as really this should be the first bit of
AW> code we do also with maybe a floopy utility disk to do the
AW> burn/recovery.

I have read that the standard Intel flash BIOS design used by many
motherboard manufactures is split into a "boot block" that can recover a
corrupted BIOS via a simple floppy boot, and a "main block" that
contains everything else.  The "boot block" can typcially be
write-protected by a motherboard jumper.  If this is true, we can use
that boot block as our "backup" for when our BIOS gets hosed.  Leave the
jumper on, and we don't have to worry about killing it by accident. 
Meanwhile, we can play with our own BIOS all we want.

I do agree that one of the things our OpenBIOS should do is be able to
load BIOS updates from supported devices directly, without the need to
boot an OS first.

DC = Dave Cinege 
DC> I say simple command line (GRUB like) with a few basic menus is
DC> enough.  Make the UI for navtive OS's (or java), with full online
DC> help etc, etc, etc. (make xconfig style comes to mind) Have it
DC> generate a settings image, and copy the image to NVRAM in one shot.

The idea of putting the glitzy UI with bells-and-wistles in an OS
program has merit; if flash space is at a premium, we should definately
consider that option.

However, I would certainly want every aspect of the BIOS to be
configurable in the BIOS, tho the UI may be a simple command line.  And,
if someone wants to take the time to write a flashy menu system, let
them.  :)

BS = Benjamin Scott (me)
BS> fsm/    <- full-screen menu
DC> Don't go overboard with this.
BS> mouse/  <- mouse support (maybe?)
DC> Waste of time, and useless. Ever use and AMI win bios?
DC> 'Nough said...

I wasn't really being too serious with the GUI and mouse.  I have seen
the AMI "WinBIOS" and think it is one of the stupidest things to hit the
PC market (and AMI is usually pretty good).  A text-based full-screen
menu system would prolly be a good idea, though, because many users like
or need that sort of thing.  But that can come later, much later if need
be.  :)

BS> net/    <- network cards (for BOOTP)
DC> Hmm I don't think we touch this. The network card BIOS just does
DC> it's own thing.

I would definately want to support BOOTP via the BIOS.  Netword cards
are EPROM based (in my experience, anyway), and you have to pull a chip
or reprogram them to change things.  With BOOTP and network card
drivers, we can configure things at will, configure network boot
options, even do things like ping from the BIOS prompt.

There has been mention of putting the Linux kernel directly into flash
memory, if you have the room.  I think that is definately something we
should consider.  If we also support a small "ramdisk" file system in
ROM, then we could have a system that boots totally from flash ROM, with
no local devices.  Put Linux on your coffee maker.  :-)

There has been a *lot* of talk about real-mode vs proected-mode BIOS
support.  Okay, let's look at this logically.  Right now, the BIOS is
almost (totally?) real-mode, both in menus, sys init and boot, and BIOS
call support.  Any OS has to be in real-mode to make BIOS calls.  The
bootstrap (MBR) is always loaded in real-mode, and depends on BIOS to do
any I/O not built-in to the bootstrap.  Once something more intelligent
is loaded, the BIOS can be ignored, or not.

DOS depends on BIOS calls, and is always in real-mode (in some form),
and so depends on real-mode BIOS calls.  Win95 ignores the BIOS a good
deal of the time, and acts just like DOS the rest, so Win95 depends on
real-mode BIOS calls.  Linux uses the BIOS to startup, but ignores it
from then on.  If we can implement a way to boot Linux without BIOS
calls, then Linux doesn't need the BIOS at all.  We could do the same
for NT or OS/2, but we don't have the source.  :-)

So, if we want to support other OSes at all, we need to support BIOS
calles.  Some people will without a doubt want this.  So that should be
a goal.  Make it as compact and as compatible as possible, and maybe
even allow it to be left out of the flash image build if the user won't
need it.  But some hardware even depends on BIOS calls, so don't bet on
it.  :-)  In any event, we should work on this early on.  Besides the
fact that we'll need to, it is easier to reimplement something you know
then design something new.  Let's take it one step at a time. :)

So, if we are going to implement real-mode calls and Linux already
works with them, why should we bother with fancy protected-mode stuff? 
Maybe we don't need to.  The BIOS should be compact, simple, and
elegant, not powerful.  The OS is the power.  Linux boots just fine from
real-mode, and it always will, so a protected-mode BIOS may be a white
elephant.  It is worth investigating, but not until we have the
fundamentals down.

It is important to realize that not including protected-mode code
*doesn't* mean we can't add features.  We should be able to support
loading the boot sector from any partiton, active primary, inactive
primary, or logical (the OS might choke and die, but that's not our
fault <g>).  Add support for basic reads from filesystems (ext2fs,
ISO-9660, maybe FAT) and the ability to pass arguments to the Linux
kernel, and you've just made LILO obsolete, and made Linux booting far
easier and safer.  A basic multi-boot menu would be trivial at that
point.  We can do all this quite easily in real-mode.

Let me be so bold as to propose some priorities:
1) Anything required to initialize the system and boot an MBR
   containing LILO, and let LILO boot Linux.  We would need to
   implement such BIOS calls that LILO makes use of.  I suggest
   using a system configuration set at compile-time to simply things.
2) Full real-mode BIOS interrupt call support.
3) A basic command-line driven UI allowing us to querry and set the
   various BIOS functions and features, and boot.
4) The ability to boot from any partition.
5) The ability to load a Linux kernel directly from a physical disk
   location (like the start of a partition) and boot it.
6) Filesystem support, to allow reading a kernel from a active
   filesystem, rather then a disk location.
7) Other things, like fancy boot menus, netboot, etc.

Comments?  <manic grin>

-- Ben

---
OpenBIOS -- http://www.linkscape.net/openbios/
[e-mail]   Body: un/subscribe
Problems?  [e-mail]