General comments

[Benjamin Scott]

Hello all,

Okay, a friend of mine got me so interested in this that I had to sign
up.  And, having signed up, I of course have to put my two-bits worth
in.  It's an Internet tradition!  :) In regards to some stuff on the
OpenBIOS homepage (OB being quotes from the homepage)....

OB> Sun-like bootconsole

I think this is one of the coolest aspects of this project.  I've
always liked things like DEC's SRM console for hardware-level control. 
They give you a lot of power and control and don't get in your way.  For
our purposes, they are also simpler to program, easy to extend for new
features (just add commands and/or variables), and typically use less
memory then full-screen menus.  They also work on serial consoles.

OB> Remote administration (?)

I think I might have a better idea:  Make the BIOS data structures
available via a standard interface to the OS, allowing query and set. 
This is a good idea anyway (makes system administration easier), and
lets the OS handle all the network transport and management protocol
stuff.  I don't really see any need to have the BIOS support it
directly.  Why complicate things needlessly?  (Of course, if there is a
legitimate need for this, by all means, let's do it).

Would be nice if you could return to the BIOS UI from the OS via
function call or hardware (like the HALT switch on DEC systems).  I
suppose you might even be able to return control to the OS, if you
didn't make any intrusive changes, but I dunno if that would be useful.

OB> no Unneccessary hardware detection that makes startup slow
OB> no 16bit Code
OB> no MSDos Filesystem code

While I agree that we should dump anything that is around simply
because it was there first, let's not fall into the trap of getting so
hooked on redesigning things we forget reality.  For one, any x86 CPU
starts in real mode, so you'll need at least a 16-bit stub to init
protected mode.  Some expansion cards that provide BIOS extensions don't
work well in protected mode (older stuff, true, but Linux has always
been good on that front).  Real-mode code is sometimes simpler or
smaller then protected-mode, too.  Likewise, DOS FAT has two
advantages:  It's simple (easier to support) and nearly universal
(almost everything supports it).

I guess my main point is, we should try to avoid arbitrarily declaring
what "Must" and "Must Not" be.  Make the code design as modular as
possible, and you can include whatever you want.  Developers will
support what they know or need.  Users can choose what they want and
like.  This mirrors the design of the Linux kernel itself, and I think
it is a very good design policy to follow.

Chris Arguin ([e-mail]) posted a suggestion for a source
code tree.  If I may be so bold to make some suggestions/changes:

ui/       <- user-interface and UI extensions
  cli/    <- command-line interface
  fsm/    <- full-screen menu
  mouse/  <- mouse support (maybe?)
  gui/    <- GUI (if we get really bored :)
drivers/  <- device drivers for boot and BIOS function support
  ide/
  scsi/   <- how do we tie this in with SCSI cards that have their own
             INT13 BIOS?  write our own drivers for the SCSI chipset?
  usb/    <- can USB support boot devices?
  net/    <- network cards (for BOOTP)
init/     <- handles system initialization and the like
boot/     <- OS boot stuff (standard MBR, Linux kernel, BOOTP)
std/      <- standard BIOS call implementation (like good ole INT13)
ext/      <- OpenBIOS extensions (dunno what they are yet, tho :)
misc/     <- the ever-popular "other" category

Comments, suggestions, flames, etc?

-- Ben

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

[Chris Arguin]

On Wed, 18 Feb 1998, Benjamin Scott wrote:
> OB> no Unneccessary hardware detection that makes startup slow
> OB> no 16bit Code
> OB> no MSDos Filesystem code
>
> While I agree that we should dump anything that is around simply
> because it was there first, let's not fall into the trap of getting so
> hooked on redesigning things we forget reality.  For one, any x86 CPU

Of course this is something important to remember, I'm no sure everything
on this list falls into that category. Why should the BIOS reconize the
DOS filesystem?
> support what they know or need.  Users can choose what they want and
> like.  This mirrors the design of the Linux kernel itself, and I think
> it is a very good design policy to follow.

Amen.
> Chris Arguin ([e-mail]) posted a suggestion for a source
> code tree.  If I may be so bold to make some suggestions/changes:

Changes? You rewrote the whole thing! :)
> ui/       <- user-interface and UI extensions
>   cli/    <- command-line interface
>   fsm/    <- full-screen menu
>   mouse/  <- mouse support (maybe?)
>   gui/    <- GUI (if we get really bored :)

Ok, I see how you are constructing this... Yeah, this will proably be
somewhat cleaner, and better address the issue of using multiple
inputs/outputs, as raised by somebody else.
> drivers/  <- device drivers for boot and BIOS function support
>   ide/
>   scsi/   <- how do we tie this in with SCSI cards that have their own
>              INT13 BIOS?  write our own drivers for the SCSI chipset?
>   usb/    <- can USB support boot devices?

Somebody will throw a harddrive on there :)

Seriously, I was figuring support for it more for the serial console
stuff. We also need VGA and RS232 support, for the output.
> net/    <- network cards (for BOOTP)

I had debated this, but I wasn't thinking along the lines of BOOTP.
Definitly we want some network support for that.
> init/     <- handles system initialization and the like
> boot/     <- OS boot stuff (standard MBR, Linux kernel, BOOTP)
> std/      <- standard BIOS call implementation (like good ole INT13)
> ext/      <- OpenBIOS extensions (dunno what they are yet, tho :)

As you have mentioned before, set/query commands for the BIOS settings.
> misc/     <- the ever-popular "other" category

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

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]