Real mode vs protected mode at boot

[Auraomega]

First off, I tried searching but the search refused because of too many hits

I'm wondering what the pros and cons are when loading your kernel in each mode, for example if I roll my own boot loader I'm free to load my kernel in real mode and set up protected mode later down the line, or I could set up protected mode before I load my kernel, GRUB on the other hand loads all kernels in protected mode.

I know it's possible to switch to V86 however purely from a just booted point of view, what reasons do people have for one mode or the other? Do people even consciously choose or is it purely based on what boot loader one chooses to use?

[bewing]

There are a number of things that must be done in Real mode before your OS starts multitasking in pmode. Most bootloaders fail to do these things for you because a) there are so many of them, b) the requirements change over time, c) the choices are partly custom to your OS, d) there is no standard for how the bootloader should pass the results to your OS. So, for typical bootloaders that boot into pmode, many OSes transition back to rmode for awhile anyway, to do these things for themselves. However, there are definite advantages that can be had for bootloaders that run primarily in pmode. So, even though it lacks aesthetic purity, you should probably expect that your OS will spend time in both modes during initialization -- unless you find a really nice bootloader that does every last thing that you want.

[Candy]

A bootloader is a thing that you need to start the kernel. That's all it's supposed to do. Ignore all the details about it and jjust make it load your kernel as quickly and correctly as possible. Did you try grub? That one is portable, has file system support and starts you off in pmode.

[roboman]

well the boot sector is 512 bytes long, with most storage devices. Some of that gets used up with disk info. Even if you use the whole 512, that's a short program. 1) some how cram enough into the boot sector to do every thing you need 2) you have the boot loader load the os and have the os do all it needs and leave a bit of software that likely doesn't get used again in memory 3) you write a boot loader that loads a second stage boot loader, that sets things up the way you want and then loads the os. 4) you get slick, do a single stage boot load and over write the real mode setup section of the os with variables used by the p mode part of the os.

I've been working with DexOS, Dex picked option 2 and I haven't seen a good enough reason to change it on my branch of his os. But I don't really see it as a better option then the others. But I'm also no master programmer, just some one who has been playing with software for a long time.

[smwikipedia]

well the boot sector is 512 bytes long, with most storage devices. Some of that gets used up with disk info. Even if you use the whole 512, that's a short program. 1) some how cram enough into the boot sector to do every thing you need 2) you have the boot loader load the os and have the os do all it needs and leave a bit of software that likely doesn't get used again in memory 3) you write a boot loader that loads a second stage boot loader, that sets things up the way you want and then loads the os. 4) you get slick, do a single stage boot load and over write the real mode setup section of the os with variables used by the p mode part of the os.

I've been working with DexOS, Dex picked option 2 and I haven't seen a good enough reason to change it on my branch of his os. But I don't really see it as a better option then the others. But I'm also no master programmer, just some one who has been playing with software for a long time.

Hi roboman,
I am designing the booting phase for my little OS so I'd like to learn from your experience.
Since the Dex picked option 2, in what mode did you load the OS? If it is rmode, I believe you must be using BIOS to access floppy/hard disk. If it is pmode, did you write any device drivers for floppy/hard disk?
I am eager to hear from you.
Thanks.

[skyking]

I don't think there's a big difference if you just consider the switching to protected mode thing (if you roll your own - otherwise it's easier to leave as much as possible to the bootloader). However since you most likely want to be in protected mode in order to use C/C++ code you would be better of with switching in the boot loader if that's wanted in the boot loader.

Since the space directly after the MBR normally is not used I think it's pretty OK to put the rest of the bootloader there.

[Brendan]

Hi,

Since the space directly after the MBR normally is not used I think it's pretty OK to put the rest of the bootloader there.

Well, no.

For the traditional MBR scheme, an OS's boot code begins in the first sector of that OSs partition. The MBR and the sectors between the MBR and the first partition belong to the "boot manager"; which might be a simple thing that's only capable of chain-loading the boot code in the active partition, or might be a more complex graphical menu that supports multiple OSs and has other features. An OS has no right to touch the MBR or the sectors between the MBR and the first partition. Of course an OS may provide its own "boot manager", but this is mostly for convenience (so users don't have to find and install their own if they don't want to) and shouldn't prevent the user from replacing the OSs boot manager with any other boot manager whenever they like.


Cheers,

Brendan

[skyking]

Hi,

Since the space directly after the MBR normally is not used I think it's pretty OK to put the rest of the bootloader there.

Well, no.

For the traditional MBR scheme, an OS's boot code begins in the first sector of that OSs partition. The MBR and the sectors between the MBR and the first partition belong to the "boot manager";

Well that was pretty much what I meant, since it is unused (not in a partition) you can put bootloader code there (or boot manager if you want to call it that)...

[Brendan]

Hi,

For the traditional MBR scheme, an OS's boot code begins in the first sector of that OSs partition. The MBR and the sectors between the MBR and the first partition belong to the "boot manager";

Well that was pretty much what I meant, since it is unused (not in a partition) you can put bootloader code there (or boot manager if you want to call it that)...

You're getting "boot manager" and "boot loader" confused - they're entirely different things intended for entirely different purposes. Imagine a simple thing that asks the user which partition to chainload (a boot manager, in the MBR), and the first part of an OS's boot code (a boot loader, in a partition).

If you don't see what I mean, maybe you should install a boot manager (e.g. PLOP or GAG or one of the many others); and see if it trashes your OS's boot loader (because your boot code is using sectors it shouldn't touch) instead of chainloading your OS's boot loader.


Cheers,

Brendan

[skyking]

You're getting "boot manager" and "boot loader" confused - they're entirely different things intended for entirely different purposes. Imagine a simple thing that asks the user which partition to chainload (a boot manager, in the MBR), and the first part of an OS's boot code (a boot loader, in a partition).

Perhaps I didn't read that difference between "boot manager" and "boot loader", but then what is the big harm if the "boot manager" (which according to you "owns" the space before the first partition) contain code that is able to actually load the kernel (like grub can do with linux fx)?

[Combuster]

but then what is the big harm if the "boot manager" (which according to you "owns" the space before the first partition) contain code that is able to actually load the kernel (like grub can do with linux fx)?

That it doesn't work if you need a separate boot manager for system A and for system B, both of them needing the first cylinder and neither able to boot the other. That is why you should put the OS' loader in the partition, so that anything capable of chainloading can boot any OS.

[Solar]

Consider this:

I have a Linux and a Windows installed on my machine, plus a free partition I use to "experiment" with operating systems.

My boot manager is GRUB, which allows me to boot from any of the three partitions.

If I would have to replace GRUB, even temporarily, because your OS can only be loaded by its own boot manager (instead of being chainloaded by any boot manager), I won't even give it a try, period.

It's as Brendan said: You "own" the partition your OS is installed in. Assume the first sector of your partition gets chainloaded by some boot manager. Provide a boot manager that can be used in absence of anything pre-installed in the MBR, but make it optional.

Make sure that your OS can work partition-contained and chainloaded. It's OK if your boot manager can load your kernel directly, circumventing the need for a boot loader (as GRUB does for Linux). Just make sure that you also have a boot loader option that can load your kernel without having the MBR or the first cylinder for itself. (Again, as GRUB does for Linux - you can install GRUB into the first partition sector instead of the MBR.)

At this point, it becomes clear that it is completely sufficient to provide only a boot loader because there are plenty boot managers already out there, and there's very little you can do "customizing" the boot manager without losing chainloading compatibility.

PS: This should perhaps be in the Wiki, somewhere in the vicinity of "Beginner Mistakes"...