On Wed, 7 Jul 1999, Brian Hurt wrote:
Sorry about the newbie questions- I still can't get at the FAQ.
I can't reach the FAQ for here either.
Pointers to where I can get this document gladly accepted. Or a pointer to the archive of this mailing list.
I think Mircea Ciocan mirceac@interplus.ro was going to put up an archive of this mailing list back in february, but I don't know the current status of it.
Or the CVS repository for the code.
Why is the bios going into protected mode? This would seem to make life difficult to load an OS. Is there a game plan for dealing with this that I'm not seeing?
The problem is that the linux load sequence is 16-bit code, which loads the idt and gdt and then performs dozens of more instructions before going into protected mode.
The solutions I see are:
- 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.
- 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.
- 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.
- 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?
- 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.
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).
/ Niklas
[1] ftp://flux.cs.utah.edu/flux/multiboot/MultiBoot.html [2] http://www.uruk.org/grub/ [3] http://www.niklas.ekstrom.com/gnubios/
- To Unsubscribe: send mail to majordomo@freiburg.linux.de with "unsubscribe openbios" in the body of the message