Grub to Real Mode

[Ameise]

Hey,

I am currently trying to get a fresh GRUB boot back to real mode so I can do things like graphics settings.

Along with the other issues, I am noting that my 16-bit code will need to reside below 1MB, as GRUB loads the kernel -at- 1MB. Hence, I'm wondering if there is any 'guaranteed' safe area below 1MB that I can write the code to that GRUB is not using or will be invalid. Otherwise, will I have to manually find clear areas?

Thanks!

[mariuszp]

You can get GRUB to do your graphics settings for you.

[Ameise]

GRUB2 has consistently refused to do such, even when instructed to do so.

Either way, we want to be more independent of the bootloader - it seems bad design to be fully dependent on GRUB2.

As is, I am hoping that there is a guaranteed 'free' area of lower memory which I can write to, otherwise I will have to check for pointers that GRUB returns in the mb header, copy them elsewhere, and so forth.

[gerryg400]

The best thing to do is to parse the Grub tables and make your own copy of the required information. Grub will tell you which additional memory you should not use (acpi tables etc.). Then you can use all the memory that you would like.

[rdos]

V86 mode is a good way. If the CPU supports VME it is even easier as you don't have to emulate interrupt-related instructions.

[jal]

Along with the other issues, I am noting that my 16-bit code will need to reside below 1MB, as GRUB loads the kernel -at- 1MB. Hence, I'm wondering if there is any 'guaranteed' safe area below 1MB that I can write the code to that GRUB is not using or will be invalid.

If you adhere to the Multiboot specs (which I assume you are, using Grub), then Grub reports which memory areas are free. Iirc, it also reports free memory below 1MB. Also, see here.


JAL

[Brendan]

Hi,

Along with the other issues, I am noting that my 16-bit code will need to reside below 1MB, as GRUB loads the kernel -at- 1MB. Hence, I'm wondering if there is any 'guaranteed' safe area below 1MB that I can write the code to that GRUB is not using or will be invalid.

Multi-boot doesn't guarantee that any areas below 1 MiB (including areas marked as "usable RAM" in the memory map) aren't actually used by for the multi-boot information; therefore you can't just assume areas marked as "usable RAM" in the memory map actually are usable RAM until after you've parsed or relocated the multi-boot information.

The other alternative is to simply not use any of the multi-boot information (e.g. switch to real mode, then do memory detection, etc yourself) so that it doesn't matter if multi-boot's information is overwritten; or to not use anything you haven't already parsed or relocated. This is the method I use (partly because the memory detection code in GRUB is inferior anyway).

The new version of Multiboot (and GRUB2) is worse: there's no guarantee that the firmware is "PC BIOS", and as far as I know there's no way for you to determine if the firmware is "PC BIOS" or not. In this case you can't expect BIOS (and VBE) functions to work when they don't exist, and you mostly don't have a choice and have to let GRUB (attempt to) set the video mode right. Unfortunately GRUB mostly passes the hassle onto whoever creates the configuration GRUB uses, which means that (for something like a bootable CD, where the person who created GRUB's configuration can't know which video modes work in advance) it's impossible to have any video mode set reliability (other than low resolution/VGA video modes I guess).


Cheers,

Brendan