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
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
Hi!
Two questions: Why is that mailing list _that_ slow (2 and more hours for a reply is really slow)?
Second: does anybody mind if we configure majordomo in a way it places "[OPENBIOS]:" in front of any mail as I do it for now by myself? I think this is good practice for mailing lists.
Winscheichwos, - Matthias
On Fri, 5 Feb 1999, Matthias Wächter wrote:
Hi!
Two questions: Why is that mailing list _that_ slow (2 and more hours for a reply is really slow)?
Second: does anybody mind if we configure majordomo in a way it places "[OPENBIOS]:" in front of any mail as I do it for now by myself? I think this is good practice for mailing lists.
Hi...
the problem is that I can't change this options myself and we have a quite inconvenient system administration here. I will try to move this mailing list to another host during the next 2 weeks.
Regards, Stefan.
-- Can you afford *not* to use linux?
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
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.
- The boot device has to identify itself.
- The user has to identify himself.
- Compression for whole devices is a must.
- 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
-
Charles Esson -
Matthew Sullivan -
Matthias Wächter -
Niklas Ekström -
Simon Richter -
Stefan Reinauer