Counting memory using 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
User avatar
AlfaOmega08
Member
Member
Posts: 226
Joined: Wed Nov 07, 2007 12:15 pm
Location: Italy

Counting memory using grub

Post by AlfaOmega08 »

How can I count memory using the multiboot header leaved by grub?

I've always believed that mb->mem_upper + mb->mem_lower = total memory. But it isn't there is always a difference of 1 - 2 MiBs

Then I've tried using the memory map of grub. I've printed the results:

Code: Select all

size: 0x14; base_addr_low: 0x9FC00; base_addr_high: 0x0: length_low: 0x400; length_high: 0x0; type: 0x2

size: 0x14; base_addr_low: 0xE8000; base_addr_high: 0x0: length_low: 0x18000; length_high: 0x0; type: 0x2

size: 0x14; base_addr_low: 0x100000; base_addr_high: 0x0: length_low: 0x1EF0000; length_high: 0x0; type: 0x1

size: 0x14; base_addr_low: 0x1FF0000; base_addr_high: 0x0: length_low: 0x10000; length_high: 0x0; type: 0x3

...
But I don't what that number means[/code]
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: Counting memory using grub

Post by Brendan »

Hi,
AlfaOmega08 wrote:I've always believed that mb->mem_upper + mb->mem_lower = total memory. But it isn't there is always a difference of 1 - 2 MiBs
The mb->mem_upper and mb->mem_lower fields tell you how much continguous RAM is at 0x00000000 and at 0x00100000, and comes from legacy BIOS functions. It doesn't include any of the RAM under "ROMs" from 0x000A0000 to 0x000FFFFF, or the EBDA, or the ACPI tables. If there's a memory hole somewhere it won't include anything above the memory hole. For e.g. if there's 256 MB of RAM and a memory hole from 0x00F00000 to 0x00FFFFFF it'll probably only tell you about 639 KB at 0x0000000 and 14 MB at 0x00100000. Also, depending on which legacy BIOS function GRUB actually gets the information from, it could be limited due to backward compatability and/or range problems (e.g. the BIOS function might return the number of 1 KB chunks as a 16-bit value, which can't work for more than 65535 KB).
AlfaOmega08 wrote:Then I've tried using the memory map of grub. I've printed the results:

Code: Select all

size: 0x14; base_addr_low: 0x9FC00; base_addr_high: 0x0: length_low: 0x400; length_high: 0x0; type: 0x2

size: 0x14; base_addr_low: 0xE8000; base_addr_high: 0x0: length_low: 0x18000; length_high: 0x0; type: 0x2

size: 0x14; base_addr_low: 0x100000; base_addr_high: 0x0: length_low: 0x1EF0000; length_high: 0x0; type: 0x1

size: 0x14; base_addr_low: 0x1FF0000; base_addr_high: 0x0: length_low: 0x10000; length_high: 0x0; type: 0x3

...
But I don't what that number means[/code]
0x400 bytes of "system area" at 0x9FC00 = EBDA
0x18000 bytes of "system area" at 0xE8000 = BIOS ROM
0x1EF0000 bytes of usable RAM at 0x100000
0x10000 bytes of "ACPI reclaimable" at 0x1FF0000 = ACPI tables (RAM you can use if you've finished with the ACPI tables)

For some reason it looks like you're missing an entry for 639 KB of RAM from 0x00000000 to 0x0009FBFF, and at least one entry for "system area" just below 4 GB (e.g. 128 KB of ROM at 0xFFFE0000).

If you want "total size of RAM chips installed", then don't bother - it's only useful for display purposes. However, if you want you can probably get this information from SMBIOS (e.g. size of each RAM chip, type of RAM chip, etc), which is designed to be used by hardware technicians for tracking a list of hardware for maintenance/upgrade purposes, and isn't designed to be used by an OS for initialization/configuration purposes.


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Post Reply