This is a philosophical question that I am posing here for discussion.
What should the purpose of the BIOS be?
In my mind, the BIOS should be a minimal piece of code, used only to initialize the hardware to the extent needed to boot the system. This would include initializing the memory space and boot device, reading the first block of code from the boot device and turning control over to that block of code. This "boot block" would then finish initializing the hardware, loading API's, OS's or whatever, from the boot device.
I believe that all API level services should be provided by the boot block code that is loaded by the BIOS and not by the BIOS itself.
The idea of the BIOS providing an API is something that developed in the early days of PC's when each card had its own BIOS/API supplied in ROM on the card. IBM and the clone makers quickly tried to consolidate these separate BIOS blocks into a single EPROM. The problem with this solution is that the BIOS is not flexible, it is very hardware dependent, is optimized for a single OS and is very complex.
A simple BIOS, whos only task is to initialize the CPU/Memory/Boot Device, then load and execute a boot block (from the boot device) would be preferable to trying to replicate the "BIOS as an API" model that is used in todays PC's.
I think that the "BIOS as a boot loader" model is simple and flexible enough that it will be easy to maintain (especially in a free software environment) and easier to evolve as the hardware and software environments change. All of the intelligence (system initialization and API's) reside within the code stored on the boot block (rather than in the BIOS code stored in EPROM/EEPROM).
Using this approach you would not have to worry about optimizing the BIOS code for any specific OS. The BIOS's only job would be to load/execute the first block from the boot device and then get out of the way. The first block stored on the boot device could then contain low level hardware initialization and API's (if needed) that are optimized for the OS that is going to be used.
Once control passes from the BIOS boot loader you have complete flexibility. You could set the system in any mode, load any OS, load a multiple OS loader, even load an old fashioned 16 bit BIOS into shadow and act like a legacy PC clone. But none of this code has to be in the BIOS itself.
The BIOS as boot loader would also be well suited for embedded applications because it is small, lightweight and can be specifically implemented to boot from things such as flash, EPROM, network cards, radio modems or other unusual boot devices.
In all cases the code would simply initialize the hardware then load/execute the boot block from the boot device. The BIOS would only need to be as complex as the hardware deems necessary. Support for new and custom hardware (non boot devices) would only have to be implemented once, in the OS. Not twice, once in the BIOS and once in the OS.
Thoughts, comments?
Dave
Dave wrote:
This is a philosophical question that I am posing here for discussion.
What should the purpose of the BIOS be?
In my mind, the BIOS should be a minimal piece of code, used only to initialize the hardware to the extent needed to boot the system. This would include initializing the memory space and boot device, reading the first block of code from the boot device and turning control over to that block of code. This "boot block" would then finish initializing the hardware, loading API's, OS's or whatever, from the boot device.
Well if we drop the the legacy of supporting DOS and windoze and tweak a little the free OSes not to depend by "classic" BIOS calls ( I belive that Linux still use at boot some BIOS calls for memory size discovery, some APM sevices and so...) and add a little configuration program that will be nice as a start. But somewhat it MUST be a metod for add-on cards to announce their capabilitys more than what we have now on the PCI bus. BTW somebody studied the IEEE proposal ???
I believe that all API level services should be provided by the boot block code that is loaded by the BIOS and not by the BIOS itself.
You mean by the kernell ;) ???
The BIOS as boot loader would also be well suited for embedded applications because it is small, lightweight and can be specifically implemented to boot from things such as flash, EPROM, network cards, radio modems or other unusual boot devices.
In most embedded devices THE boot media is the ROM so, the configuration is also enough fixed to not necesite a configuration program and btw. is there some ( even scratch...) standard for what a embbeded BIOS should do, tommorow I'll start coding to some micro-PC board with ALI 6117C and I'll like a starting point.
P.S. Still nobody answered me, really nobody doing embedded on this list :(((
Mircea C.
A bios has to provide enough support to load a program. Now where are you going to load the program from. A floppy, nope that's stupid. From harddisk, why, what great note from heaven said all computers come with a hard disk.
It is my view the network is the only sensible place to load it from.
So a bios has to load a OS ( application), and has to have network code so it can load from the logical location.
In a perfect world the bios should hide from the OS the hardware. New hardware should be able to add CPU independent drivers.
For a well thought out and complete answer to this question take look at IEEE 1275. Unfortunately like all complex questions the complete answer is not simple to follow.
Now for the last statement, nobody is doing embedded control.
Yes I am, and I will ask the question, for embedded control why do you want to boot an OS. You can fit a lot of code ( including the OS) in a $10 flash.
Regards
Charles Esson
Mircea Ciocan wrote:
Dave wrote:
This is a philosophical question that I am posing here for discussion.
What should the purpose of the BIOS be?
In my mind, the BIOS should be a minimal piece of code, used only to initialize the hardware to the extent needed to boot the system. This would include initializing the memory space and boot device, reading the first block of code from the boot device and turning control over to that block of code. This "boot block" would then finish initializing the hardware, loading API's, OS's or whatever, from the boot device.
Well if we drop the the legacy of supporting DOS and windoze and tweaka little the free OSes not to depend by "classic" BIOS calls ( I belive that Linux still use at boot some BIOS calls for memory size discovery, some APM sevices and so...) and add a little configuration program that will be nice as a start. But somewhat it MUST be a metod for add-on cards to announce their capabilitys more than what we have now on the PCI bus. BTW somebody studied the IEEE proposal ???
I believe that all API level services should be provided by the boot block code that is loaded by the BIOS and not by the BIOS itself.
You mean by the kernell ;) ???The BIOS as boot loader would also be well suited for embedded applications because it is small, lightweight and can be specifically implemented to boot from things such as flash, EPROM, network cards, radio modems or other unusual boot devices.
In most embedded devices THE boot media is the ROM so, theconfiguration is also enough fixed to not necesite a configuration program and btw. is there some ( even scratch...) standard for what a embbeded BIOS should do, tommorow I'll start coding to some micro-PC board with ALI 6117C and I'll like a starting point.
P.S. Still nobody answered me, really nobody doing embedded on this list :(((
Mircea C.
Hi
Charles Esson wrote:
A bios has to provide enough support to load a program. Now where are you going to load the program from. A floppy, nope that's stupid. From harddisk, why, what great note from heaven said all computers come with a hard disk.
Failsafe loading? Should be from a floppy/network/any other device that doesn't need a lot of code to initialize and grab code from... (or one that does, but comes with it's own initialization code - see below)
It is my view the network is the only sensible place to load it from.
So a bios has to load a OS ( application),
Not so...
and has to have network code so it can load from the logical location.
This shouldn't be too dificult anyhow, if you have a netcard boot prom, the code from that could be used to get a config/boot file, and in the 'safe' code mode, a flash image be collected instead of the normal boot code. Floppy disk support should be used, you might find that the 'safe' image with IDE code will get to big to have it in a failsafe area.
In a perfect world the bios should hide from the OS the hardware. New hardware should be able to add CPU independent drivers.
For a well thought out and complete answer to this question take look at IEEE 1275. Unfortunately like all complex questions the complete answer is not simple to follow.
Now for the last statement, nobody is doing embedded control.
Yes I am, and I will ask the question, for embedded control why do you want to boot an OS. You can fit a lot of code ( including the OS) in a $10 flash.
Yours
Matthew
PS Appologies if you were not refering to the 'protected' (failsafe) bios code.
Charles Esson wrote:
For a well thought out and complete answer to this question take look at IEEE 1275. Unfortunately like all complex questions the complete answer is not simple to follow.
Now for the last statement, nobody is doing embedded control.
Yes I am, and I will ask the question, for embedded control why do you want to boot an OS. You can fit a lot of code ( including the OS) in a $10 flash.
NO, NO, that was Dave said:
The BIOS as boot loader would also be well suited for embedded applications because it is small, lightweight and can be specifically implemented to boot from things such as flash, EPROM, network cards, radio modems or other unusual boot devices.
AND that was what I (Mircea) replied:
In most embedded devices THE boot media is the ROM so, theconfiguration is also enough fixed to not necesite a configuration program and btw. is there some ( even scratch...) standard for what a embbeded BIOS should do, tommorow I'll start coding to some micro-PC board with ALI 6117C and I'll like a starting point.
And that means that I don't agree with Dave on that part, I was just asking if there is some kind of specifications for embedded systems API to have even a little compatibility and portability between that boards, like some standard services: memory alocators, equipment list, device list and proprerties like in I or O or I/O, is analog, digital, serial, network, timer or so, range of values, interruup services made simple, interrupt priority alocation map, watch-dog presence and programming and a simple way to specify priorityes on those loaded tasks and yes, even some standard routines for upgrading Flash on serial or network interface, this last thing sickens me, it seems that every board has his own proprietary way to be updated. This is great for loocking users with you, and give nothing to the competition but here we're laking about Open ( even Free like in FSF if we join the GNU project :) things. So if you (or others) plan to do something like that I invite you to join forces NOW !!!
Mircea C.
On Wed, 3 Feb 1999, Dave wrote:
What should the purpose of the BIOS be?
In my mind, the BIOS should be a minimal piece of code, used only to initialize the hardware to the extent needed to boot the system. This would include initializing the memory space and boot device, reading the first block of code from the boot device and turning control over to that block of code. This "boot block" would then finish initializing the hardware, loading API's, OS's or whatever, from the boot device.
Well, I think that's true. It's one way of giving the BIOS a new purpose.
That means, we have (for now) two general ways:
a) (my suggestion) Implement a new BIOS with a new API. b) (your suggestion) Implement a new BIOS with only the functions to access a "larger BIOS", say, a kernel or other on any media.
Of course, (a) needs more space and probably is slower than (b). (b) has the advantage to only do the absolute minimum of jobs to access the kernel. But that kernel (maybe a pre-kernel) also has to initialize the hardware, it has to know exactly on which board it resides etc.. (a) would partly (main parts) hide hardware details from the next-to-load kernel, so except for the new interface and a new kernel loader, the OS (and the kernel) doesn't have to change very much.
Any further thoughts? We need a direction, and this is a main crossing, I think! Folks, your opinion, please!
The idea of the BIOS providing an API is something that developed in the early days of PC's when each card had its own BIOS/API supplied in ROM on the card. IBM and the clone makers quickly tried to consolidate these separate BIOS blocks into a single EPROM. The problem with this solution is that the BIOS is not flexible, it is very hardware dependent, is optimized for a single OS and is very complex.
Exactly that is, what the above solution (a) is thought for, added to the flexible idea of burn-time configuration (i.e. a "make config"). This solution would demonstrate it's principle flexibility at "make config" level, but the BIOS itself would not have to be complex, redundant, with large unused pieces of code.
A simple BIOS, whos only task is to initialize the CPU/Memory/Boot Device, then load and execute a boot block (from the boot device) would be preferable to trying to replicate the "BIOS as an API" model that is used in todays PC's.
Well, that's exactly the topic to talk about!
The problem is: Then your BIOS would have, say, in the simplest way some 10k of code (binary), without using encryption, authentication, network etc.. And all the complexity is in the boot block, which, of course, has no limit except on the available RAM.
The problem is, that then _both_ BIOS and boot block would have to match each other and the motherboard. To keep them in sync can not be done in a general way - think of someone who swaps harddisks etc.
Of course, if it gets too large what we want the BIOS32 to be in the (a) way, we've got a problem, and I think, we will have this problem somedays. Of course, then something like your idea would be good - maybe on a per-module basis? - just a thought.
I think that the "BIOS as a boot loader" model is simple and flexible enough that it will be easy to maintain (especially in a free software environment) and easier to evolve as the hardware and software environments change. All of the intelligence (system initialization and API's) reside within the code stored on the boot block (rather than in the BIOS code stored in EPROM/EEPROM).
What's your suggestion concerning remote boot (network, USB, firewire, ...)? how would _that_ match your idea?
Using this approach you would not have to worry about optimizing the BIOS code for any specific OS. The BIOS's only job would be to load/execute the first block from the boot device and then get out of the way.
hmmm, I mean, the partitioning scheme should be kept for a minimum amount of compatibility to other OSes. Either the boot loader resides on an own partition (like the OS/2 boot loader) or it would be loaded like DOS - implicitly from the partition (boot block, file name searching, loading, executing). The problem is: Both need an API to continue loading or to search for data on the media (harddisk, etc.). I don't think that it would fit into something like a boot sector ("first block from the boot device"). What exactly do you mean with "one block"?
Winschdawos, - Matthias
Matthew Sullivan wrote:
Hi
Charles Esson wrote:
A bios has to provide enough support to load a program. Now where are you going to load the program from. A floppy, nope that's stupid. From harddisk, why, what great note from heaven said all computers come with a hard disk.
Failsafe loading? Should be from a floppy/network/any other device that doesn't need a lot of code to initialize and grab code from... (or one that does, but comes with it's own initialization code - see below)
It is my view the network is the only sensible place to load it from.
So a bios has to load a OS ( application),
Not so...
Why not, to a boot loader a OS is nothing more than an application. If you look at open boot you will see there are options to leave the loader in memory with open boot code allocating memory to the OS on request, and dealing with the OS's I/O. It seem like a logical thing to to. The OS provides the API the user applications expect. The BIOS provides a hardware independent layer for the OS. Under NT it is the HAL, under Apple and sun it's open boot.
Once upon a time the IBM pc double boot made sense. Today with flash being what it is, it makes no sense.
and has to have network code so it can load from the logical location.
This shouldn't be too dificult anyhow, if you have a netcard boot prom, the code from that could be used to get a config/boot file,
You have made a large assumption about the boot hardware, not a wise thing for a bios to do.
and in the 'safe' code mode, a flash image be collected instead of the normal boot code.
Loading the OS is a minor issue, providing a device independent layer for the OS that is the big one..
Floppy disk support should be used, you might find that the 'safe' image with IDE code will get to big to have it in a failsafe area.
A few more years and floppy disks will be something we remember. I won't remember them fondly, too many boot block viruses, and failed floppies for me to have happy memories.
Regards Charles Esson
In a perfect world the bios should hide from the OS the hardware. New hardware should be able to add CPU independent drivers.
For a well thought out and complete answer to this question take look at IEEE 1275. Unfortunately like all complex questions the complete answer is not simple to follow.
Now for the last statement, nobody is doing embedded control.
Yes I am, and I will ask the question, for embedded control why do you want to boot an OS. You can fit a lot of code ( including the OS) in a $10 flash.
Yours
Matthew
PS Appologies if you were not refering to the 'protected' (failsafe) bios code.
Hi,
Charles Esson wrote:
Matthew Sullivan wrote:
-[snip]-
So a bios has to load a OS ( application),
Not so...
Why not, to a boot loader a OS is nothing more than an application. If you look at open boot you will see there are options to leave the loader in memory with open boot code allocating memory to the OS on request, and dealing with the OS's I/O. It seem like a logical thing to to. The OS provides the API the user applications expect. The BIOS provides a hardware independent layer for the OS. Under NT it is the HAL, under Apple and sun it's open boot.
Once upon a time the IBM pc double boot made sense. Today with flash being what it is, it makes no sense.
I think we maybe at cross purposes here. I was refering to the 2 parts of the BIOS, the main part and the failsafe.
My reference was the the failsafe, a small peice of code to load a BIOS image eg: from floppy, if the main BIOS code is corrupt, not present. This code would be 'protected' from being over written by normal BIOS installation and only serves the purpose to ensure that someone updating their BIOS to a different config will be ensureed that theyu will always beable to 'repair' any possible 'damage' with out the need for the pocket EPROM/FLASH programmer ;-)
and has to have network code so it can load from the logical location.
This shouldn't be too dificult anyhow, if you have a netcard boot prom, the code from that could be used to get a config/boot file,
You have made a large assumption about the boot hardware, not a wise thing for a bios to do.
Not a large assumption, a net card with a boot rom will get a boot image, we can exploit that... If it doesn't have a boot rom, then it's not used.. Look at today's AMI/AWARD BIOS's for the example of what I mean...... ;-)
and in the 'safe' code mode, a flash image be collected instead of the normal boot code.
Loading the OS is a minor issue, providing a device independent layer for the OS that is the big one..
Cross purposes I think...
Floppy disk support should be used, you might find that the 'safe' image with IDE code will get to big to have it in a failsafe area.
A few more years and floppy disks will be something we remember. I won't remember them fondly, too many boot block viruses, and failed floppies for me to have happy memories.
I hope not, I know they are getting scarser, but unrelyable, slow, as they maybe, but they do work, and the hardware is pretty much standard... (IF & Size). Code for initializing a floppy controller & reading a disk is very small considering the same code required for IDE drives.. (Remember there are an aweful lot of chipsets out there, and the failsafe code doesn't want to be hardware dependant ie, it needs to be the same code for everyone, so it is slick stable, and works cross platform, then it only needs to be programmed once - you won't get a second chance with it - if it works you could install anything into your flash afterwards, and providing you didn't remove that initial check/backup code, you'll still be able to boot an image from a device, whether it be floppy or net supplied.....)
Just my thoughts....
Yours
Matthew
On Thu, 4 Feb 1999, [iso-8859-1] Matthias Wächter wrote:
Using this approach you would not have to worry about optimizing the BIOS code for any specific OS. The BIOS's only job would be to load/execute the first block from the boot device and then get out of the way.
hmmm, I mean, the partitioning scheme should be kept for a minimum amount of compatibility to other OSes. Either the boot loader resides on an own partition (like the OS/2 boot loader) or it would be loaded like DOS - implicitly from the partition (boot block, file name searching, loading, executing). The problem is: Both need an API to continue loading or to search for data on the media (harddisk, etc.). I don't think that it would fit into something like a boot sector ("first block from the boot device"). What exactly do you mean with "one block"?
I don't think reading one physical block from the medium is a good solution. Many non-x86 systems read a specified amount of data from the medium they boot from (which may usually be a random access device such as a floppy disk, a hard disk or a CD-ROM, a sequential access device such as tape or a network device). This greatly simplifies boot loaders and allows to get rid of them at all in some cases, i.e. the system firmware loads the kernel of the OS directly.
For example, upon booting a DEC Alpha system from a random access device, the SRM firmware loads the first block from the device and treats two 64-bit words at offsets 480 and 488 as the number of blocks and the number of the first block to read from the device, respectively. There is also a 64-bit magic number located at offset 496 which indicates the bootblock is valid. The blocks are being read and then executed. This allows booting a Linux kernel directly from a disk. A second-stage boot loader may also be used and unlike x86-based solutions it's clean and straightforward (and is written in C, actually).
A similar approach is used on MIPS-based DECstation systems.
-
Charles Esson -
Dave -
Maciej W. Rozycki -
Matthew Sullivan -
Matthias Wächter -
Mircea Ciocan