[OPENBIOS]: Discussion

[Matthias Wächter]

On Fri, 5 Feb 1999, Niklas Ekström wrote:

> The GNU issue:
> I think we should wait, atleast until we know what the BIOS is going to
> be like. There could be some benefits of being a part of GNU, but I
> believe there are also some disadvantages, such as loosing part of the
> freedom (actually). 

At first, I think we should not _in any way_ threaten OS developers to
program an interface to OpenBIOS using the appropriate code. That means,
we could f.e. take the part concerning OS interface and split it from the
rest of OpenBIOS to make the rest xGPL but the OS interface free to use.
But I think, it's too early to discuss this in detail. We saw Linux not
being used by companies "because the GPL stops us from distributing
binaries only", and we saw (and see) them announcing software which _can_
deal with this issue however.

> 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. 

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.). Of
course, one can always put in new features, compile newer source code,
etc.

> I think the reason that many programmers have avoided using BIOS
> routines instead of their own hardware routines is that they don't know
> in what way the BIOS works. 

No, I don't think that this is the total truth. The BIOS is 16bit, all
"features" of it are basically useless and slow, newer features are not
being introduced to the interface etc.

> It could be really badly implemented and be really slow.

In any way, it must be badly implemented and really slow. That's why every
modern 32 bit operating system switches to protected mode after it has
loaded its own drivers to totally switch off BIOS functionality. Win9x is
the last 32 bit OS switching back to real mode just to let DOS based
drivers or even BIOS-only interfaces do the work.

In fact, using the OS I currently type this eMail on, BIOS is only used to

*) initialize the hardware
*) load and run the kernel

that's what it's _used_ for by now, while everything in the computer works
fine. But when there's a problem, the BIOS lets me boot from floppy, boot
from CD-ROM, lets me install new IDE devices, and even "detects" and uses
new hardware and its BIOS.

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"
:-)

> But when the sourcecode is free, they will be able to read the code and
> see that these routines are actually highly optimized and probably
> couldn't be done any better. (And if they could, they should do so and
> send in the patches to openbios.org :-). 

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.

Of course, they should send in patches, etc., and the source code should
be free, but the _only_ program(s) to use the source code besides new BIOS
modules is the OS loader.

> When it comes to supporting old 16-bit OS'es I am personally not
> interested in supporting them at this time. We don't want any crappy
> 16-bit OS'es anyway! 

Well, as long as they exist, we must either support them in any way (see
above, answer to any question) or beat them until they die :-)

> I think the BIOS should be 32-bit and use protected mode (flat) all the
> way through. And if we really, really need to support 16-bit some day,
> it will be easy to switch back to real mode and implement the necessary
> INTs then. 

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). 

> Though I think we should support every existing 32-bit (pmode) interface,
> such as BIOS32 and VESA 2.0 protected mode interface (the VESA stuff is
> really not up to us, but to the graphicscard manufacturers).

Oops, is BIOS32 already used by something? I used this term to distinguish
between 16 and 32 bit BIOS...

> Some people have talked about OpenFirmware (IEEE 1275) support. This sound
> like a good idea to me, but since I don't really know what that requires
> from the BIOS, I can't make any comment on it. I think I will read through
> the homepage later (http://playground.sun.com/1275/home.html).

At first: Could someone, please, put any link of interest to the OpenBIOS
homepage?

> Although I
> do know that this would require Forth support, which would be a good
> thing, since I believe the PCI specification requires BIOS code in Forth
> for PCI devices. (On the other hand using Forth is said to be big and
> slow, so I don't know...)

Remember the forth, Luke. :-)

At first, we must define to what we want to be compatible in what way. Of
course, this can be done at a later point in time, but it may require
structural changes affecting the whole source code, so we should decide
early.

> 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. 

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).

> 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.?

> 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.

> I also, like many other here, think that we should support as many booting
> devices as possible. Perhaps we should begin by supporting floppy and IDE,
> and then move on to other things, such as network and USB and so on. This
> would be real easy to implement later, due to the modular design.

Well, what I want to say here is: We should IN ANY WAY (even booting the
missionary way) support AUTHENTICATION, COMPRESSION and ENCRYPTION for any
data besides the BIOS itself. That means:

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.

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.

> That is something I believe that _everyone_ agrees of; that OpenBIOS
> should use a highly modular design. 

Of course, but the skeleton has to be fixed in some way from the
beginning.

> This will bring several obvious
> advantages. I have though of three different places where the modularity
> will take place. First is the sourcecode, where many different pieces of
> hardware can be supported via preprocessor directives, and separate
> sourcefiles.

Of course, many types of processors should be supported, too!

> Then just before flashing the BIOS into ROM, there could be
> different modules that the user could choose between to change
> functionality, but without having to recompile.

Hmmm ... well, choosing the modules is something like linking, and linking
is nearly like compilation. Of course, it would be great to have all
modules _and_ the setup tool _and_ that linker to fit on one 1.44 floppy
disk.

> Lastly there could be some runtime autodetection of hardware. I think
> this last thing should be used very moderately, if at all. 

agree.

> If you are still reading this, I want to apologize for this quite large 
> post (didn't mean to do it... ;)

Finally we have reached some point of discussion, that's good! And look,
my post is not smaller either :-)

Winschdawos,
- Matthias

-- 
Der Wein mit der Pille ist in dem Becher mit dem Fächer.
-----------------------------------------------------------------------------