Thanks everyone for their comments. I've had another evening to think about things, and have some further thoughts:
On Thu, 8 Jul 1999, [ISO-8859-1] Niklas Ekstr�m wrote:
[snip happens]
- Don't go into protected mode. So long as addresses stay below 1 meg,
this shouldn't be a problem (PCI/AGP configuration is the only reason I know of why we may need to go above 1M).
This is not an option. The BIOS needs to access memory above 1MB to be able to detect DRAM timings etc.
This is what I thought. In addition, gcc really dislikes producing 16-bit code. There is a 16-bit DOS gcc linked to off of D.J. Delorie's site that is being used for the port of Linux to the 8086, but I don't think it's usable. I suppose we could dump gcc totally and go with some other compiler, but A) I _like_ gcc, and would like to keep Linux as my build environment, and B) I don't know of any other free usable 16-bit DOS compilers out there (I'd rather not use an old, properietary, unsupported compiler like Borland C for DOS).
All of these things conspire to strongly encourage the use of protected mode in the BIOS. :-)
- Go into protected mode for initial configuration, then exit it to load
the boot code (note that the BIOS service routines would have to run in real mode in this case).
This is how other BIOSs today do it. That is also how you have to do if you strive for IBM-PC BIOS compability.
Unless I'm missing something, the linux boot sequence uses IBM-PC BIOS functions. I found a number of int 0x13 (diskette services) and int 0x10 (video services) calls in arch/i386/boot/setup.S. Even Grub makes heavy use of BIOS services- a quick grep revealed 23 different BIOS calls, using services 0x13 (disk), 0x10 (video), 0x1a (RTC), and 0x16 (keyboard).
- Stay in protected mode, run the OS loader in V86 mode, and "cleverly"
handle the protection fauls (probably by "emulating" them- on the lidt/gidt instructions we save off their offsets, and on the lmsw instruction doing all three- lidt/gidt/lmsw).
I guess this is not an option either. Since V86 runs realmode code you will run into problem directly when the OS wants to do something in protectedmode. Even if it could be done (by "emulating" something) it seems like a really bad idea to me.
This is actually my leading favorite canidate. The idea is that once the lmsw instruction is executed, the OS takes over. From my 386SX Microprocessor Programmer's Reference Manual (outdated, I know- but I haven't gotten the more advanced documentation yet), the sensitive instructions are: lidt, lgdt, lmsw, mov to/from special control registers, clts, and hlt. The moves to DRx and the hlt instruction should simply be run in priveledged mode. Movs to TRx should be ignored (for now)- I don't think any OS actually uses these. The rest would need to be emulated.
On execution of a lmsw, the bios would perform all the lidts, lgdts, and movs to CRx, and resume the flow of code at the next instruction- i.e. give up and let the OS take over. I'm estimating the total code to do this is only a few hundred lines, most of which would be parsing the instructions. I am, of course, volunteering to write this code. :-)
- Same as above, but instead of emulating the instructions, we exit from
protected mode at that point, and retry the instruction (and hope that no one ever tries to use a BIOS service after executing a protected instruction).
This looks just like your second solution, only that you run the bootup realmode instructions in V86 mode instead of "real" realmode. Pointless?
Not quite. The difference is _when_ do we switch to real mode- 1) just before jumping into the boot loader, 2) the first time the boot loader does something we don't want to deal with emulating, or 3) never (and we just carefully hand over control to the OS when it loads).
- Beg the OS maintainers to change their code. I dislike this option
intensely- while on Linux we could probably do it (by becoming OS maintainers), I doubt Microsoft would listen.
This depends on what changes you ask the OS maintainers for. The BIOS I'm working on will be Multiboot compliant, which means that the OS have to conform to the Multiboot standard [1] in order to be loaded by the BIOS. See the GRand Unified Bootloader (GRUB) homepage [2] for information about what OSs are supported by the standard etc.
So basically you're putting the boot loader into the bios. I'm not 100% comfortable with this idea- it locks you into a boot loader.
This is a viable alternative for me, mind you, and I may do just that. But I have complete control over the OS being loaded (Linux) and how it's loaded, and do not have to coordinate with other distributions, or boot Windows, or anything ugly like that. But I'd like to have a more flexible system- I'd like to see VA-Research be able to use OpenBios.
You can look at my website [3] for short information about what my BIOS will be like (see the mailinglist archive for the reasons of why I'm working on a BIOS of my own instead of OpenBIOS).
Do you have code I can look at? Can you email me (off-line) your reasons?
Thanks for the links- they've given me more things to look at.
- To Unsubscribe: send mail to majordomo@freiburg.linux.de with "unsubscribe openbios" in the body of the message