OSDev.wiki

Detecting Memory (x86): Difference between revisions

Page Discussion

Detecting Memory (x86) (view source)

Revision as of 01:23, 23 January 2017

3 bytes added ,  7 years ago
→‎Memory Map Via GRUB
[unchecked revision][unchecked revision]
VisualWikitext
Line 284:
==Memory Map Via GRUB==
 
[[GRUB]], or any bootloader implementing [http://www.gnu.org/software/grub/manual/multiboot/multiboot.html The Multiboot Specification] provides a convenient way of detecting the amount of RAM your machine has. Rather than re-invent the wheel, you can ride on the hard work that others have done by utilizing the multiboot_info structure. When GRUB runs, it loads this structure into memory and leaves the address of this structure in the EBX register. You may also view this structure at the GRUB command-line with the GRUB command <tt>displaymem</tt> and GRUB2GRUB 2 command <tt>lsmmap</tt>.
 
The methods it uses are:
Line 331:
* "size" is the size of the associated structure in bytes, which can be greater than the minimum of 20 bytes. base_addr_low is the lower 32 bits of the starting address, and base_addr_high is the upper 32 bits, for a total of a 64-bit starting address. length_low is the lower 32 bits of the size of the memory region in bytes, and length_high is the upper 32 bits, for a total of a 64-bit length. type is the variety of address range represented, where a value of 1 indicates available RAM, and all other values currently indicated a reserved area.
* 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 uint32_t (with the "ignore this entry" bit), or clean up the table in any other way.
* One of the problems you have to deal with is that grubGRUB can theoretically place its multibootMultiboot information, and all the tables it references (elf sections, mmap and modules) anywhere in memory, according to the multibootMultiboot specification. In reality, in current grubGRUB legacy, they are allocated as parts of the grubGRUB program itself, below 1MB, but that is not guaranteed to remain the same. For that reason, you should try to protect these tables before you start using a certain bit of memory. (You might scan the tables to make sure their addresses are all below 1M.)
* 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 GRUB2GRUB 2 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 "GRUB2GRUB 2", unless it adopts the new multi-boot header and becomes incompatible with GRUB-legacy).
 
==Memory Detection in Emulators==
Anonymous user
Retrieved from "https://osdev.wiki/wiki/Special:MobileDiff/4765"