Let's start with the benefits of BIOS16:
G1) It's supported by all PC OSes. G2) It's supported by the hardware manufacturers. Think of: your VGA card providing its own BIOS, think of your newly bought SCSI controller: You plug them in, and at least you (a) see a picture on the screen and (b) can boot an operating system from it (of course, you need a driver to use it under the operating system as well).
Can we use any of this code which is in these cards for BIOS16 support? It would easen up the memory requirements.
G4) The BIOS is standalone. You don't need any data on a media to boot.
This sounds like an OpenBIOS feature :-) We could create somekind interface for adding custom modules. Some programs might fit directly to same EEPROM with OpenBIOS.
So, what's OpenBIOS for (AKA feature list)?
F1) input/output/intermediate/control device flexibility. input device: harddisk, network, parallel port ZIP, ... output device: VGA, HGC, serial, network, ...
What is HGC?
F3) Support for "intelligent devices". There's a main difference between devices storing data and devices able to compute or interact in any other way. From the BIOS point of view, this dynamic way of communication (for example, authentication, remote boot, remote administration) and the appropriate way of implementation could be a main feature of OpenBIOS. F4) Authentication (user).
This would also open possibilities for user profiles. Instead of just returning "user authenticated", the server could say "User ok. Please boot from network image server:filename:params". It might also be usefull if the authentication could be passed to the operating system underneath.
F5) Authentication (boot block). This mechanism could be used in other way, too: A non-"intelligent device", i.e. the boot block itself (block device), could have to authenticate itself TO THE BIOS. I don't know whether one can get this bullett-proof (think of the turing machine and the related axiom), but the idea is great, I think.
Why limit this to just boot block? I think that at least the file (kernel) should be authenticated. One rather bullet-proof method could be using md5 checksums stored in NVRAM. checksum matches -> boot loader will be allowed to continue.
This would enable one to boot from insecure media (like floppy disk) in a public area and still be rather secure. It would also be usable when booting from net.
F6) Compression. Not a main detail, but interesting in any way.
Might be usable when booting from serial line :-)
F7) Encryption. A main topic as security becomes relevant more and more. Of course, related to (F4) and (F5). Needed for any media which can be harmed by someone and for any media where the transmission of data can be (a) listened to and (b) modified (or even faked).
Not true with b) since it's possible to detect modifications using authentication.
F8) Flexible and hierarchically selectable boot device selection. A typical IDE boot control file could look like:
Boot:=PCI(0,3):ISA:Legacy_IDE(0,UDMA):Partition(1):BootLoader(Linux_OpenBIOS)
Could you explain this format a bit?
It would be nice to be able to pass parameteres to boot loader. Boot loader would then pass them to the kernel which is beeing loaded.
If we want to replace entire boot loader (like LILO) then we would need a way to boot from different files. This might be possible to implement without including file system support in BIOS.
It could be done using utility which would run under the operating system. The utility would store the starting point and the length of the boot image (kernel) in NVRAM.
Sun's OpenBoot has some neat features. One of them is dev-aliases.
Here is an example:
boot /iommu@f,e0000000/sbus@f,e0001000/espdma@f,4000/esp@f,80000/sd@3,0
Quite long, isn't it. I'm not certain what t /iommu is, but I think that it refers to the motherboard itself since as I understand it some sparc architectures allow multiple motherboards (with 2 or 4 cpu's / board). Sbus refers to the expansion bus, esp refers to scsi-controller and sd to scsi disk, @3,0 refers to scsi id 3 and lun 0.
I think that we should think something as configurable as that.
OpenBoot allows this to be written as:
boot /iommu/sbus/espdma/esp/sd@3,0 and I think that if you have only one disk, you can use command: boot /iommu/sbus/espdma/esp/sd
You need the longer version only if you happen to have multiple SCSI-controllers or SBUS'es etc.
Since that's quite hard to remember, OpenBoot allows you to define alias for that device and then you can use commands like boot disk boot disk1 boot net boot tape
or even the feared: boot floppy
In addition, we would have a system control file, like:
InputDevice:=PCI(0,2):ISA:Legacy_8042:AT102(german,ISO-8859-1) Monitor(my_19_inch_cube):=Table(Monitordata,Samsung_900p) OutputDevice:=Duplicate(OutputDevice_2):PCI(0,5):RivaTNT(my_19_inch_cube,text,100,43):TermOut(ISO-8859-1) OutputDevice_2:=PCI(0,3):ISA:Legacy_16550(0,9600,8N1):TermOut(US-ASCII)
Aarghh! Yet another place to configure your monitor. But you are right, BIOS would seem to be the correct place to do it. This would allow us to use fixed-frequency monitors more easily, but it could also create problems. But to be really useful this information should be made possible to obtain while running some OS.
I'm beginning to see that there is some need for bios after the kernel has booted. I can almost see the light :-)
If the EEPROM is large enough, we could implement something like a boot device selection browser to help us search for bootable devices. Of course, this is just the idea of an idea :-) and will need a large BIOS because all relevant modules would have to be in it.
I don't think this to be a problem. We just need multiple user interfaces, one basic which is as small as possible and then really fancy for those of us who have enough EEPROM available.
But how should OpenBIOS deal with the advantages of BIOS16?
D2) Support by hardware manufacturers. Of course, we could try to be compatible to BIOS16 not only to provide DOS etc. to boot, but also to let hardware prividing BIOS16 BIOS to get a place in our structure. Of course, this would blow up code and make our BIOS like Win9x using both 32bit and legacy BIOS drivers.
I don't think that we should mix bios16 stuff with the rest of the OpenBIOS. I'd say that bios16 should be as separate as possible from the "real stuff" so that it wouldn't ruin the design. I'm not at all certain wether this kind of separation is possible, so please comment.
D3) BIOS extensions.
Well, They should be possible, I think. More: We could use BIOS chips
located in VGA or SCSI cards to contain the appropriate OpenBIOS drivers (of course, this would make them incompatible to BIOS16) instead of the BIOS16 code.
In future all devices will have OpenBIOS drivers in their BIOS chips :-) Definetly worth supporting. Perhaps somekind of model for dual support might be nice so that a device could have both: OpenBIOS code and bios16 code.
D4) The BIOS is standalone. Of course, this could (and will) be a main problem (and is discussed already heavily). Either we try to make it standalone and take the risk of having the OpenBIOS not to fit into EEPROM, or we remove more and more benefits of OpenBIOS to reach the goal. To have main BIOS functionality on harddisk is dangerous in any way. Harddrive defect, new hard drive, virus, security, diskless workstations, etc.
I don't think that removing features from OpenBIOS only because we need bios16 support is an option. I think that we should make OpenBIOS modular and make it _support_ module loading from hd. Since we already decided (?) to have somekind of authentication for bootblock why coudn't we use authentication for modules as well?
If bios16 would be seperate module, it wouldn't be vital to have it in order to get the system boot. It would be required only if the user wishes to run OS which doesn't support OpenBIOS. I wouldn't recommend storing modules in HD. I think that this is much better way than not beeing able to use bios16 at all.
In addition I think that Bios16 might not be needed on older machines since you can't run w95/nt with them. More likely old 486's are used as servers which run linux or some other free unix.
For legacy OS's (Dos, Windows) that require a BIOS, the Boot Loader can load a BIOS from the boot device directly into Shadow Ram and execute it as if it where copied from EEPROM to Shadow Ram.
Thought of that: Then we have a problem using the CMOS for our purposes
Another tought: how much NVRAM we have to store our data? Encryption keys and boot loader configuration take some space..
A couple of you have mentioned Open Boot.
I found something on the SUN server I think. Search there for it. I think it's of no use for us at least because the sources are not free.
Even if there is no source to be copied we might want to copy some ideas from OpenBoot. I think that we should compare BIOS/bootloader features used in other systems before deciding what to include in OpenBIOS.
Comments, anyone?