[OPENBIOS]: Discussion

[Simon Richter]

Matthias Wächter schrieb:

> > There have been talks about what the BIOS should do and support. One
> > opinion is that it should be extremly small and only support loading in
> > a bootloader, and never be touched again. Another may be to support
> > older OS'es using 16-bit INTs.

These questions all sound like compile-time options to me... :-)

I see  three ways how an OS could be called:

  1. Call the bootloader, keep data structures in memory and provide real-mode
     call-back INTs that are compatible with DOS/Windows.
  2. Call the bootloader, but don't expect to be called again (Linux, Solaris)
  3. Call the bootloader, stay resident and export a symbol table. This has never
     been done in the Intel world so far, but it would be the most powerful
     approach, as you could e.g. provide a mechanism that would allow cards that
     are not supported by the OS but by the BIOS (driver provided either by the
     BIOS or by a card EPROM) to be used anyway. The main reason why Solaris/x86
     is not widely accepted is that it lacks many drivers for popular boards.

> First, I don't think the first idea was to "never touch it again".
> Instead, the BIOS would be compiled to fulfill demands exactly specifyable
> and something of constant (until you plug in new hardware, etc.).

An important thing to have would be some method to add/replace BIOS drivers
without changing the BIOS (remember, to all BIOSs are flashable). I am thinking
of some reserved space on harddisk (as the Amiga had [well, sort of]) or an easy
network protocol. This would make the admin's life much easier, as data on
harddisk can be changed over the network, while exchanging the BIOS requires
personal physical presence.

> The question is: Do we get OpenBIOS that far to have an answer to any of
> those questions? Of course, the answer can look different than using the
> old BIOS16, but OpenBIOS must have an answer, and it should not be "no"
> :-)

BIOS16 is merely a question of wrapper functions and initializing interrupt
vectors. I don't see why implementing that interface should cost more than 20k.
Just make it another compile-time option ("DOS/Win9x compatibility?").

> I don't think that this is the way we should walk: This only makes sense
> if the BIOS is a complete kernel to run all the time or at least in
> background. Neither Linux nor NT is prepared for this at the moment,
> AFAIK.

Linux could be prepared rather quick, I think. Run-time linking is already
implemented in the kernel, it shouldn't do much harm to link the kernel against
the BIOS. This would require, however, that the symbol table of the BIOS gets
exported.

> I think, the best way to support BIOS16-based OSes is to _use_ BIOS16,
> i.e. to load it and execute it. We already have a program which, I think,
> will be easily adapted to the 32bit structure (of course, when the
> structural design is done).

But it would also require a way to switch back (needed for e.g. LOADLIN).

> > Joel Mansford mentioned that you could have the BIOS setup program run
> > from your favorite OS, which seems like a good idea to me. Then it could
> > be very good looking, and vouch for easy tweaking of the BIOS.
> > Preferably there should also be a complementary setup inside the BIOS,
> > incase the HD breaks down or whatever.

This leads to a more general question: What will the BIOS <-> OS interface look
like? It should provide these basic functions:

   * Namespaces for different extensions
   * Functions for extension management (query, open, close)

Such an interface could, for example, be

void* action(int8_t namespace, int8_t function, void* arg1, ...);

with namespace == 0 for the management functions.

Then there could be some kind of extension that handles access to the BIOS setup.

> Well, should be user selectable (at compile time), I think. What I don't
> want is a BIOS needing just two assembler instructions to break into (at
> least not in general as it is nowadays).

Breaking into the BIOS is an option. Noone cares if we initialize the interrupt
vectors and the OS destroys them, but if we do not set up the vectors, strange
things will happen when someone inserts a DOS floppy.

> > Concerning hardware compability, I think it will suffice to support newer
> > PCIset computers to begin with.
>
> Agree. I hope we don't lose too many developers for that.?

Well, as long as you can still extend the source tree to add support for older
chipsets, I don't see why.

> > This also implies that I don't think any specific embedded design
> > features should be made at first.
>
> Well, at least we should look _what_ embedded features, not already in
> desktop and mobile computers, are needed and how they fit into our
> structure. We should at least support an interface for such modules as
> they are known by now.

Well, the above interface should cover it all.

> 1) The boot device has to identify itself.
> 2) The user has to identify himself.
> 3) Compression for whole devices is a must.
> 4) The on-board or on-CPU (Pentium III?) random number generator must be
> used.
> 5) Data has to be encrypted not to be decoded by means of opening up the
> computer and moving the hard disk to another one.

IMHO that's not top priority. First of all, the thing should boot, then we can
think about when it should not boot. :-)

1) and 2) should, BTW, be OR conditions. Anyone should be able to boot from a
harddisk that the admin (cryptographically) signed as being safe. However, a
floppy disk requires the admin's password.

> Of course, those features are ALL OPTIONAL, but they have to fit into our
> structure from the first day on. That means, that the BIOS (at the high
> level) should not play with absolute sectors etc. but logical sectors. And
> it should work with uncompressed data, to know of that they are decoded
> already or have to be encoded before written to the hard disk (even if
> there is no decoding/encoding switched on). And: hard disks are large
> enough to contain any number of public authentication keys one would need.

Well, apart from the physical/logical sectors thing, it should not be too hard to
implement later on. The readsector() procedure gets renamed to real_readsector(),
and readsector becomes a wrapper function that does the necessary processing.

CU
   Simon