First free memory address after multiboot data

[BasdP]

Hi,

I'm struggling with finding the first free physical memory address after the multiboot data including modules etc.
This is the multiboot struct i'm using:

Code: Select all

struct {
    uint32_t flags;
    uint32_t mem_lower;
    uint32_t mem_upper;
    uint32_t boot_device;
    uint32_t cmdline;
    uint32_t mods_count;
    uint32_t mods_addr;
    uint32_t num;
    uint32_t size;
    uint32_t addr;
    uint32_t shndx;
    uint32_t mmap_length;
    uint32_t mmap_addr;
    uint32_t drives_length;
    uint32_t drives_addr;
    uint32_t config_table;
    uint32_t boot_loader_name;
    uint32_t apm_table;
    uint32_t vbe_control_info;
    uint32_t vbe_mode_info;
    uint32_t vbe_mode;
    uint32_t vbe_interface_seg;
    uint32_t vbe_interface_off;
    uint32_t vbe_interface_len;
}

And I'm booting with the latest version of GRUB 2.

Can anyone help me out?

Thanks!

[Brendan]

Hi,

I'm struggling with finding the first free physical memory address after the multiboot data including modules etc.

Why?

Note that the multiboot spec gives no guarantees about the location of the multiboot info structure. For example, it's perfectly fine for the multiboot instruction structure to be at "top of RAM" so that there is no free physical memory after it.


Cheers,

Brendan

[BasdP]

Hi,

I'm struggling with finding the first free physical memory address after the multiboot data including modules etc.

Why?

Note that the multiboot spec gives no guarantees about the location of the multiboot info structure. For example, it's perfectly fine for the multiboot instruction structure to be at "top of RAM" so that there is no free physical memory after it.


Cheers,

Brendan

Ah thanks! I get it. I've found out about the memory map. But how can I know what areas of that memory map is used by multiboot data? Is it guaranteed to be continuous?

[Brendan]

Hi,

Ah thanks! I get it. I've found out about the memory map. But how can I know what areas of that memory map is used by multiboot data? Is it guaranteed to be continuous?

The boot loader tells you where the multiboot info structure is (via. EBX), and the structure itself is contiguous. However, anything "pointed to" by fields in the structure (e.g. the boot loader name, the VBE controller info, the VBE mode info, etc) are not guaranteed to be anywhere near the multiboot info structure itself.

Also; the memory map is just what the firmware told the boot loader and doesn't include special entries representing "used by multiboot info" or "used by your kernel" or "used by modules". Note that there's also other potential problems (entries in "random" order, entries describing "zero length" areas, entries describing overlapping areas, multiple areas describing adjacent areas of the same type, etc); so (for "100% bullet proof" code) you want to process the memory map (e.g. sort it and sanitise it).

The combination of these things means it's painful to allocate more memory very early during boot - initially, the only memory you're able to use safely is memory that's part of your ".bss" section.

My advice is to copy any data you want to keep from the multiboot information structure into your own ".bss" so that you don't have to worry about accidentally overwriting data you need; then process/sanitise the memory map (while moving it into your ".bss"); then initialise a physical memory manager while making sure that you don't include "usable but already used by kernel or modules" pages as free pages. Mostly; only use memory in your own ".bss" until your physical memory manager is initialised, and only after your physical memory manager is initialised can you (safely) allocate pages/memory without accidentally overwriting something.


Cheers,

Brendan