Page 1 of 1

Doing an E820 memory map from BIOS while writing a loader

Posted: Mon Apr 02, 2018 5:20 am
by NatureOS
I am writing a bootloader for my OS, but I need help with the BIOS E820 function for getting a memory map. I know how to do it, but what I don't understand is how to interpret this into RAM that I can feed into my kernel(For the functions malloc, etc). Plus for telling the user how much RAM is installed, I want to know how to know the amount of RAM(Not a map just the amount of MB) for the user's knowledge.

http://www.uruk.org/orig-grub/mem64mb.html
https://wiki.osdev.org/Detecting_Memory_(x86)

None of the above help me.

Re: Doing an E820 memory map from BIOS while writing a loade

Posted: Mon Apr 02, 2018 6:18 am
by Brendan
Hi,
NatureOS wrote:I am writing a bootloader for my OS, but I need help with the BIOS E820 function for getting a memory map. I know how to do it, but what I don't understand is how to interpret this into RAM that I can feed into my kernel(For the functions malloc, etc). Plus for telling the user how much RAM is installed, I want to know how to know the amount of RAM(Not a map just the amount of MB) for the user's knowledge.
Mostly; "int 0x15, eax=0xE820" needs to be called many times to get one entry at a time; and these entries have a "type" field that indicates if it's usable RAM or not.

Notes:

1) "usable RAM" may already be in use by your code, so when you're initialising your physical memory manager you need to be careful

2) one (or more) areas are likely to be reported as "ACPI reclaimable". This means that after you're finished parsing ACPI tables and don't need them anymore, you can use the RAM as free RAM.

3) it's impossible to accurately determine "total installed RAM" from the information that "int 0x15, eax=0xE820" returns. The reason is that different parts of RAM gets stolen for different things, including SMM, "shadow ROMs" and integrated video. Also, if an area is reported as "system" there's no sane/easy way to tell if it's RAM that has been used for firmware/system or if it's not RAM at all.

4) It's nice to combine information from various places (e.g. "int 0x15, eax=0xE820" if you're using BIOS or the "getMemoryMap()" UEFI function; plus APCI's SLIT table, the physical address space size from CPUID, all the information from PCI configuration space, etc) and convert it into your own "standard for your OS" format, and do all the sanity checks, and sort it in a useful order (e.g. ascending address). In this case boot code would/could do all the work so that kernel doesn't need much "only used once bloat", and so that kernel can (e.g.) initialise its physical memory manager without caring what the firmware was and (e.g.) kernel can use the same information to figure out which areas are (or can/can't) be used for PCI devices.

5) To accurately determine the total amount of RAM installed, it's probably best to use SMBIOS tables (which will also tell you other information that a user/admin might also want, like what kind of RAM it is).


Cheers,

Brendan