How do I find the starting address of free memory in GRUB?

[Caffeine]

Hi, I am trying to find out how to find the address where free memory starts while booting with GRUB. And how would I find it using the information from the memory mapping buffer in the mbi specifications?

[Octocontrabass]

The Multiboot specification includes example code showing how to find the base address and type of each memory region. (The example code attempts to print the addresses, but it has a bug: it will not print values above 4GB correctly.)

There will be more than one free memory region.

Your kernel is located inside one of the free memory regions. You will need to use the address of the start and end of your kernel to avoid the memory containing your kernel.

[Caffeine]

The Multiboot specification includes example code showing how to find the base address and type of each memory region. (The example code attempts to print the addresses, but it has a bug: it will not print values above 4GB correctly.)

There will be more than one free memory region.

Your kernel is located inside one of the free memory regions. You will need to use the address of the start and end of your kernel to avoid the memory containing your kernel.

Thanks, I must have missed it.

[Caffeine]

I'm having trouble finding where the Kernel is in memory and how I would avoid it. Which one of the address fields would I use?

[thewrongchristian]

I'm having trouble finding where the Kernel is in memory and how I would avoid it. Which one of the address fields would I use?

You can put symbols in your linker script to find the limits of your kernel. The multiboot loader will load your kernel into memory according to the ELF header. SO when your kernel gets control, you know where your kernel is, and you can define symbols at the start and end of your loaded kernel, then just ignore the kernel memory ranges when making the usable memory referenced by the multiboot header available to your physical memory manager.

Linker_Scripts

[Caffeine]

I'm having trouble finding where the Kernel is in memory and how I would avoid it. Which one of the address fields would I use?

You can put symbols in your linker script to find the limits of your kernel. The multiboot loader will load your kernel into memory according to the ELF header. SO when your kernel gets control, you know where your kernel is, and you can define symbols at the start and end of your loaded kernel, then just ignore the kernel memory ranges when making the usable memory referenced by the multiboot header available to your physical memory manager.

Linker_Scripts

Where should I put the symbols and what blocks? .text, .rodata, .data, or .bss?

[thewrongchristian]

I'm having trouble finding where the Kernel is in memory and how I would avoid it. Which one of the address fields would I use?

You can put symbols in your linker script to find the limits of your kernel. The multiboot loader will load your kernel into memory according to the ELF header. SO when your kernel gets control, you know where your kernel is, and you can define symbols at the start and end of your loaded kernel, then just ignore the kernel memory ranges when making the usable memory referenced by the multiboot header available to your physical memory manager.

Linker_Scripts

Where should I put the symbols and what blocks? .text, .rodata, .data, or .bss?

By way of example, here is my linker script:

linked.ld

Code: Select all

SECTIONS
{
	/* Begin putting sections at 1 MiB, a conventional place for kernels to be
	   loaded at by the bootloader. */
	. = 1M;
	_bootstrap_start = .; 
...
/* Bootstrap code in low memory */
...
	/* Rest of the kernel lives in high memory */
	_kernel_offset_bootstrap = .;
	. += kernel_offset;
	_kernel_offset = .;

	/* Next we'll put the .text section. */
	.text ALIGN(4K) : AT(ADDR(.text) - kernel_offset)
...
/* Kernel code in high memory */
...
	_bootstrap_nextalloc = .;
	. -= kernel_offset;
	_bootstrap_end = .; 

I can reference the symbols:

• _bootstrap_start - start of bootstrap code in low memory.
• _kernel_offset_bootstrap - end of bootstrap code in low memory.
• _kernel_offset - Start of kernel code in high memory.
• _bootstrap_nextalloc - End of .bss section, start of kernel heap data.
• _bootstrap_end - end of kernel in low memory

in code using declarations:

Code: Select all

extern char _bootstrap_start[];
extern char _bootstrap_end[];

In this case, the memory between _bootstrap_start and _bootstrap_end is data loaded by the bootloader, so when releasing pages of memory to the physical memory manager, you'd skip releasing memory between _bootstrap_start and _bootstrap_end.

[Caffeine]

Awesome! Thanks!