Getting memory map from grub

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
songziming
Member
Member
Posts: 71
Joined: Fri Jun 28, 2013 1:48 am
Contact:

Getting memory map from grub

Post by songziming »

I'm getting the memory map from GRUB via multiboot_info structure, the information I got is in the attachment.

the 4 columns are: size, addr, length, type. As of in the multiboot spec.

But where is the info about memory range 0xA0000~0xEFFFF? it's missing from the mmap.
Attachments
mmap.png
mmap.png (5.14 KiB) Viewed 2785 times
Reinventing the Wheel, code: https://github.com/songziming/wheel
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Re: Getting memory map from grub

Post by Combuster »

Would you expect "memory" in that area?
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
User avatar
SpyderTL
Member
Member
Posts: 1074
Joined: Sun Sep 19, 2010 10:05 pm

Re: Getting memory map from grub

Post by SpyderTL »

According to the OSDev Wiki Page: http://wiki.osdev.org/Detecting_Memory_(x86)
Treat unlisted regions as Type 2 -- reserved.
Apparently GRUB doesn't do this for you. You'll have to detect these and actively avoid them.
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
User avatar
SpyderTL
Member
Member
Posts: 1074
Joined: Sun Sep 19, 2010 10:05 pm

Re: Getting memory map from grub

Post by SpyderTL »

Also, from the same page:
GRUB simply uses INT 15h, EAX=E820 to get the detailed memory map, and does not verify the "sanity" of the map. It also will not sort the entries, retrieve any available ACPI 3.0 extended DWORD (with the "ignore this entry" bit), or clean up the table in any other way.
Another problem is that the "type" field is defined as "1 = usable RAM" and "anything else is unusable". Despite what the multi-boot specification says, lots of people assume that the type field is taken directly from INT 15h, EAX=E820 (and in older versions of GRUB it is). However GRUB2 supports booting from UEFI/EFI (and other sources) and code that assumes the type field is taken directly from INT 15h, EAX=E820 will become broken. This means that (until a new multi-boot specification is released) you shouldn't make assumptions about the type, and can't do things like reclaiming the "ACPI reclaimable" areas or supporting S4/hibernate states (as an OS needs to save/restore areas marked as "ACPI NVS" to do that). Fortunately a new version of the multi-boot specification should be released soon which hopefully fixes this problem (but unfortunately, you won't be able to tell if your OS was started from "GRUB-legacy" or "GRUB2", unless it adopts the new multi-boot header and becomes incompatible with GRUB-legacy).
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Post Reply