Discussion

[Charles Esson]

Niklas Ekström wrote:

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

My own view is that it should be under the LGPL. Your right you do lose
freedom, the freedom
to fork the code. Every time someone takes FREEBSD and turns it into a
proprietary solution they fork
the code. It is a nonsense.

On the other hand it is my view that use of a open solution should not require
you to make your OS a open solution. Hence my preference for LGPL. The problem
with M. Stallman is he is a fanatic.

>
>
> 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 agree, and if that's the way it goes I'm interested in putting time in.

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

But who is going to want to, that time has past lets celebrate and forget.

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

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

Big and slow, I suppose with a bit of effort you could make it that. Forth's
can be as fast as C code. The advantage of forth is that an entire self
reproducing OS can be had in less than 128K bytes, so I don't know where the
big came from..

If you want booting across the internet than you are going to have to do it in
a high level language. With forth you have several options, all have been
used. There is FICL, written in C ( this is how apple did it), you can write
the application in FORTH, and use a meta compiler that runs on a FORTH written
in C ( for example GFORTH). I believe the sun version is self reproducing,
that is you can use open firmware to produce open firmware.

Fcode is in the same family as java byte code. And just like Javabytecode
there are many ways to deal with it. If your going to use it once you
interpret it. If you intend to use it as the device drive you compile it.
Writing a Fcode compiler is not a big deal.

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

That is a front end matter, if you take open boot as an example the boot
process builds a device tree, if the OS doesn't zap the boot memory then the
device tree is available to the OS, an application can display the tree.

Further open boot as a configuration script and configuration data items. All
these are candidates for a pretty front end.

In most system that use open boot you can boot into the FORTH interpreter. The
FORTH interpreter in itself is a compiler and interpreter, you can execute
functions that test hardware and build new ones. As apple is using this
approach the number of people that are familiar with it will increase.

Some net references:

azrael.uoregon.edu/imac/
developer.apple.com/technotes/tn/tn1061.html

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

Agree, the problem is getting the foundation, once there it's down hill.

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

If you use open boot and have PCI cards with Fcode they themselves can
indicate that they are possible boot devices.

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

Read with interest.

>
>
> Best regards,
> Niklas Ekström