BIOS Memory Map (from GRUB) Errors

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
blobmiester
Member
Member
Posts: 45
Joined: Fri Jul 16, 2010 9:49 am

BIOS Memory Map (from GRUB) Errors

Post by blobmiester »

Hey all, I recently acquired a more modern machine for os testing (core i5, 4 GiB ram, etc) and when trying to start my OS, the memory manager starts overwriting the kernel and all mayhem breaks loose. :shock:

I tracked the bug down to the memory map I received from GRUB (picture of monitor below). It looks fine with several entries describing the whole 4 GiB of ram. But then we get to this last entry that seems to re-describe the first GiB or so as completely available. Which is of course wrong as there's all sorts of stuff in 0x9f000 to 0xfffff (at least).

Image

And here is the code I'm using to read the memory map in case i'm making some obvious mistake :oops:

Code: Select all

void initialize(multiboot_info_t* multiboot, unsigned int multiboot_magic)
{
    // Initialize the console (used only during preinitialization)
    console& cout = console::instance();

    // Clear the console
    cout.clear();

    // Print progress message
    cout << "Preparing to boot... \r\n"
         << "Validating received multiboot information... \r\n";

    // Validate the multiboot magic number
    if (multiboot_magic != MULTIBOOT_BOOTLOADER_MAGIC)
    {
        // Error: we can't boot (yet) if we can't rely on the multiboot
        // information integrity.
        cout << "Error: multiboot validation failure";

        // Return (and halt)
        return;
    }

    // Print progress messages
    cout << "Searching for reserved areas of physical memory... \r\n";
    cout << "Parsing multiboot memory map... \r\n";

    // Parse the multiboot memory map and append free memory to the
    // direct memory stack
    for (auto offset = multiboot->mmap_addr;
         offset < multiboot->mmap_addr + multiboot->mmap_length;
         offset += sizeof (unsigned int))
    {
        // Get memory map
        auto mmap = reinterpret_cast<multiboot_memory_map_t*>(offset);

        // Print information
        cout << "\tFrom 0x"
             << reinterpret_cast<const void*>(mmap->addr)
             << " to 0x"
             << reinterpret_cast<const void*>(mmap->addr + mmap->len)
             << ": " << mmap->type << " ("
             << static_cast<unsigned int>(mmap->len / 1024)
             << " KiB)"
             << "\r\n";

        // Advance to next memory map entry
        offset += mmap->size;
    }
}
So my question is: what is the deal with the last region reported by the bios? And is there a systematic way of dealing with this kind of thing ?
User avatar
blobmiester
Member
Member
Posts: 45
Joined: Fri Jul 16, 2010 9:49 am

Re: BIOS Memory Map (from GRUB) Errors

Post by blobmiester »

#-o

Thanks, I see that now. I've been too lazy to write the 64-bit math functions in order to display 64-bit values.

Now, to figure out how to make this work with my stack allocator. My memory manager keeps the address of the first free page (which then points to the next one and so on) which won't work for the PAE memory (as i'm in 32-bit long mode). Hmmm... any ideas on storing the free pages for PAE (memory above 4 GiB) ? Or do I need to combine the stack with a bitmap for the space above 4 GiB ?

EDIT: Nevermind, I figured it out. I just need to reorganize the stack initialization and it can work without a bitmap. Thanks.
Post Reply