GRUB's physical-memory amounts in Qemu

[alethiophile]

I am currently working on setting up paging and a heap. In the so doing, I decided to try to make my paging manager use all available physical memory, instead of just a small constant amount. I use the mem_upper member of the multiboot info struct that GRUB gives me. The assembly wrapper of my C kernel is just as that in the 'Bare bones' tutorial. Code:

Code: Select all

void kmain(multiboot_t *mbd, u32int magic)
{
  if ( magic != 0x2BADB002 ) {
    panic("Boot sequence invalid");
  }

  u32int avail_mem = mbd->mem_upper + 0x100000; // add 1M because it's upper memory
  ...
  init_paging(avail_mem); // also creates kernel heap                                                                                                        
  ...
}

When I run this, it panics with 'no available frames'. (Note that I am loosely following JamesM's tutorial.) When I run it in Qemu's GDB stub and print mbd->mem_upper, it gives me 0x1fbc0, which is obviously wrong. Does anyone know why this would be?

[salil_bhagurkar]

Assuming you are properly passing ebx and eax to your kmain function:

push eax
push ebx
call _kmain

try checking the flag bit 0 in the multiboot header. The grub multiboot header says:

If bit 0 in the `flags' word is set, then the `mem_*' fields are valid. `mem_lower' and `mem_upper' indicate the amount of lower and upper memory

[Owen]

mem_upper is more of a guideline than anything. For all you know, in a system with 31MB of upper ram, 15MB may run from 1MB to 16MB, and then there will be a 16MB gap, then another 16MB of RAM. It's unlikely, but this kind of thing (Plus ACPI tables in that RAM) happens, and you really should be using GRUB's memory map instead