GRUB memory map location

[giszo]

Hi!

I just run throught the multiboot specificaiton in the hope that I found something about the location of the memory map provided by the GRUB, but unfortunately I didn't found anything. Was I a bit of cursory and missed something or it's really not specified and can be everywhere?

I just use the memory right after my kernel binary to manage memory pages (this is some kind of bitmap) and if the GRUB memory map can be everywhere I may override it with my bitmap. My question is that should I create a backup of the GRUB memory map before I initialize my bitmap or the map is located in a specified location and I can make sure somehow that I won't override it?

Thanks,
giszo

[Hangin10]

The address and length of the memory map (which GRUB gets using a BIOS interrupt) are provided in the multiboot
structure passed in EBX to your kernel.

If I remember correctly, the address is the 12th 32bit value, and the length is the 11th (and is in bytes).

EDIT: http://www.gnu.org/software/grub/manual ... ion-format

[giszo]

The address and length of the memory map (which GRUB gets using a BIOS interrupt) are provided in the multiboot
structure passed in EBX to your kernel.

If I remember correctly, the address is the 12th 32bit value, and the length is the 11th (and is in bytes).

EDIT: http://www.gnu.org/software/grub/manual ... ion-format

Thanks, but as I meant before I've read the multiboot documentation. I just wanted to know if the possible addresses for the GRUB memory map is limited to a range (for example to the lower 1mb of memory, etc.) or not.

[Hangin10]

, totally misread.

It's usually under 1MB, because it's just the results of a BIOS interrupt.
I don't think GRUB ever moves it elsewhere.

EDIT: If anyone else has more specific info on this, it would be appreciated.
I've had similar thoughts, as I've wondered what area would be not
used by GRUB, but provide for a nice, large stack before paging is ready.

[Brendan]

Hi,

EDIT: If anyone else has more specific info on this, it would be appreciated.
I've had similar thoughts, as I've wondered what area would be not
used by GRUB, but provide for a nice, large stack before paging is ready.

My thoughts are that if you're writing a "multi-boot compliant" kernel (or boot loader or whatever), then you can't assume the boot manager will be GRUB and won't be something else that behaves completely differently. You'd only be able to rely on what the multi-boot specification says, and the multi-boot specification doesn't say anything about the permitted location/s for anything. To get around this I only touch data in my code's ".data" and ".bss" sections until memory management is setup (to make sure I can't trash data provided by the boot manager before I need it).


Cheers,

Brendan