Discussion

[Niklas Ekström]

Hi everyone,

I've seen there have been lots of discussion on the ML lately. Great! :)
After reading through all the mails I have some thoughts that I'd like to
share.

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


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.

As I envision it, the BIOS functionality should be rather big. It shall
support all hardware attached to the motherboard, and also other hardware,
through their own BIOS. This way programmers of operating systems won't
have to worry to much about the hardware part. You may think of it as a
HAL (Hardware Abstraction Layer) if you wish.

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. It could be really badly implemented and be really slow.
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 :-).

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

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

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

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.


Concerning hardware compability, I think it will suffice to support newer
PCIset computers to begin with. That would pretty much mean Pentium and
upwards. This is, as I see it, not a big problem at this time. And when we
(or someone else) wants to support older hardware (386/486/non PCI) that
shouldn't be all to hard when we got a working BIOS. This also implies
that I don't think any specific embedded design features should be made at
first.

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.


That is something I believe that _everyone_ agrees of; that OpenBIOS  
should use a highly modular design. 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. 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. Lastly there could be some
runtime autodetection of hardware. I think this last thing should be used
very moderately, if at all.


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

Best regards,
Niklas Ekström