OSDev.org

Hey everyone.

Maybe someone here has come across this problem, or something similar.

I boot my OS using GRUB, and so far this has worked very well. However, when I tried to add memory paging and needed to access the mmap_* fields of the Multiboot information structure, I found that GRUB wasn't supplying them. It provides the mem_* fields with information about the amount of RAM (even though the flags say it shouldn't), but the mmap_length is 0.

I'm supplying GRUB the header flag 0x00000003 (i.e, bits 0 and 1 set, which should enable page alignment and memory information). It gives back the information structure with the flag 0x000003D7, which has bit 6 (mmap_* fields) not set. This doesn't make any sense, because I'm telling it to give me memory information, and the Multiboot specification says that if the bootloader does not understand any bit that is in the header flag, or if it can't satisfy it, then it should error out. Yet, it merrily boots the kernel. Every example I've seen of this uses the same header flags.

The Multiboot specification leaves much do be desired in this area. I'm sure whatever is wrong is something silly on my behalf, but I'm at a loss to figure out what it is. What header flags do people in here use? Any help would be much appreciated.

Thanks in advance,
Gnome

This is interesting: it only does this when running in Bochs.

When I run it on a real machine, it gets a long list of memory blocks, all but the first of which are empty (base 0x00000000, length 0). The first appears to be correct (by comparing it to the one Linux prints out on boot). The rest, like I said, are empty.

So my question becomes two-fold. First, why would this be different in Bochs? Second, why does GRUB return bogus memory maps?

Thanks for you time,
Gnome

Last time I looked, I had a similar problem. Back then I thought I did something wrong.

I haven't touched my kernel code since, so I have no solution either. Anyone around who successfully used GRUB mmaps?

Uh, ignore the part about GRUB giving bogus information on real hardware. That was me being stupid in my code. It now works just fine on real hardware. However, it still doesn't work in Bochs. This is annoying, because I use Bochs all the time to test out the kernel without having to restart an actual computer all the time.

I'm glad to hear someone else has had a similar problem... Does anyone know of a workaround?

well, i'd be tempted to say that the BIOS bochs uses doesn't support the method GRUB uses to find the MMAP ... but as i haven't tried GRUB myself (except for loading Linux everyday) nor the MMAP feature, i can't tell for sure ...

That would be my guess too. I think the version of Bochs I'm running may be out of date. Maybe this problem is resolved in the latest version. There is a mention in the ChangeLog for 2.0.2 that they added a function in a BIOS interrupt "get memory size". Maybe that's it? I don't know. At any rate, I'll upgrade to the latest stable, then try the CVS version if that doesn't work.

It seems odd that Bochs doesn't support this BIOS function... One would think this is something pretty much every OS or bootloader would use when booting up.

bochs doesnt support a suprising amount of things.. I find it really not worth the time to try and wrestle with it.

Latest bochs version supports that fine at least. Just upgrade your bochs..

Yup, Bochs 2.1 does it just fine. I can say that without any doubts whatsoever because I spent the afternoon playing with the GRUB example kernel and using Bochs to test (The example kernel dumps out the memory map).

It's strange you should have a problem though. GRUB (afaik) uses e820, and that has been working fine for quite a while.

***

Taking advice is all well and good, but it's ME who has to re-learn C :'(.