Multiboot memory map is "empty"

[Gnome]

Hey everyone.

I boot my kernel from GRUB and obtain information about the system from the Multiboot information structure supplied by it.

Right now, I'm working on implementing memory paging, and so I want to extract the memory map from the Multiboot information structure. It says that the memory map is located at 0x00052784 but that it has length 0. This is obviously not correct, and I believe that my declaration for the information structure is at fault.

I know it's the right length -- I use the boot_loader_name field prior to this, and that's correct, and the declaration appears to match the example in the GRUB documentation in every way that matters. I've replaced some the types to match the style in my kernel (unsigned long => dword_t), and made the fields that point to stuff be a pointer rather than a dword_t, but neither should affect anything; if they did, then the boot_loader_name would be wrong.

Is that memory map base pointer (0x00052784) a reasonable value? It probably isn't correct. Any help would be appreciated.

Thanks in advance for any assistance.

[Moose]

Your mboot address pointer seams correct. It doesnt really matter where it is, as long as it doesnt sit in a memory hole.

Have you enabled the memory map by the flags in your multiboot header?

Moose.

[Gnome]

I just wondered if that always ends up in some location and someone would recognize whether it's good or not.

You know, I never thought to check the header flags... That doesn't appear to be the problem, however. I'm using the header flag 0x00000003 (bits 0 and 1 set). According to the specs, that means module page alignment and memory information.

Gnome

[Gnome]

Some more information I probably should have included earlier:
The Multiboot flag I'm getting in the information structure is 0x3A7 (binary 1110100111). The mmap_* fields (marked by bit 6) is not set. Yet, as I mentioned, I'm setting bit 1 in the header flags that requests the mmap_* fields

[Moose]

Well thats why you're not getting the map then.

I think even if you ask for it, Grub can't guarantee that a map can be provided, or that it will be 100% correct. But read the multiboot spec to make certain of that.

Moose.

[Gnome]

No, the specs say that the first 16 of 32 bits are required functionality. If GRUB can't provide them, then it should error out before it boots the image. Also, they guarantee that the memory map provided will list all memory available for normal use.

Wow, I wish this were better documented. As far as I can tell, I am doing everything correctly, but the docs aren't very clear on quite a few issues. An example or well-labelled diagram would go a long way to clearing up issues like this.

All examples I've seen of Multiboot headers use the 0x00000003 flag (or 0x00010003 for non-ELF), which is what I use too.

I tried looking through the Linux source to see what flags they use, because it obviously works for them, but after much grepping and poking around, I couldn't find any reference to it anywhere. The next thing I try will be to search for the Multiboot header in my Linux kernel image. That's probably what I should have done in the first place.

Gnome

[13BeastREW]

Hopefully I'm understanding your question correctly... You can not rely on the memory map info grub gives you, you must create and set your own GDT. The only things known come from GRUB is that cpu is in protected mode 32-bit flat addressing (all segment registers start at 0) and the A20 gate is enabled. From there you build up.

[Gnome]

GRUB guarantees some things about the state of the system when execution gets to your code. It sets up its own GDT that has all the segments pointing to the entire address range (which you can change, obviously, but I don't). You must set up your own IDT if you want to handle interrupts. It also supplies you with an extensive information structure containing all sorts of information about the system (BIOS drives, memory info, memory map, etc.) that you can configure your kernel with. All this info is fetched by GRUB from the BIOS before switching to protected mode.

My problem is that, in Bochs, GRUB can't fetch the memory map or something, because it doesn't give it to me in the information structure. It works fine on real hardware

Gnome

[EKP++]

It COULD be that the (old) BIOS simply doesn't do a proper memory map?

Anyways - show us some code, its really hard to debug problems if you can't see the source.

[mikeleany]

But if you read in section 3.1.1 of the MB spec, under 'flags' it says:

"If bit 1 of the 'flags' word is set, then information on available memory via AT LEAST the 'mem_*' fields of the Multiboot information structure . . . MUST be included. IF the boot loader is CAPABLE of passing a memory map (the 'mmap_*' fields AND one EXISTS, then it MAY be included as well."

In other words, if bit 1 is set, you'll always get the amount of lower and upper memory, but there's no gaurantee about the memory map. I wouldn't rely on it being there.
My guess is that Bochs doesn't provide a memory map to GRUB so GRUB doesn't provide one to you.