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.
It looks strange because there's no space between the length and the type. When I add that space (and convert the numbers to hexadecimal to make it easier for me to read), the memory map looks fine.
Don't forget, the base address and length are 64-bit values. Your OS will fail on real hardware if you don't handle it correctly.
I think it's better to always print addresses (and most other things as well) in hexadecimal format because it's much easier to understand.
For example it makes it way easier to see if something is page aligned (just check the last 3 digits) or below 1 MiB (0x00100000) or any memory barrier for that matter.
The memory map doesn't tell you that, it only tells you which areas are reserved and which are free to use.
To find out which devices are mapped where you'd have to do a PCI scan and check all the BARs.
if(CHECK_FLAG(multiboot->flags, 0)){
kprintf("Lower Memory: %dMB (or less than 1 MB)\n", multiboot->memoryLower / 1000, multiboot->memoryLower / 100);
kprintf("Upper Memory: %dMB (or less than 1 MB)\n", multiboot->memoryUpper / 1000);
kprintf("Total Memory: %dMB (or less than 1 MB)\n", (multiboot->memoryUpper + multiboot->memoryLower) / 1000);
}else{
kprintf("Bit 0 of multiboot->flags is unset. Not trusting memory map values.\n");
}
Where multiboot is a multiboot_info_t* structure, passed by pushing ebx.
You can then do what you are doing to conduct/read memory map, but make sure that bit 6 of multiboot->flags is set. Otherwise you can't trust any values
if(CHECK_FLAG(multiboot->flags, 0)){
kprintf("Lower Memory: %dMB (or less than 1 MB)\n", multiboot->memoryLower / 1000, multiboot->memoryLower / 100);
kprintf("Upper Memory: %dMB (or less than 1 MB)\n", multiboot->memoryUpper / 1000);
kprintf("Total Memory: %dMB (or less than 1 MB)\n", (multiboot->memoryUpper + multiboot->memoryLower) / 1000);
}else{
kprintf("Bit 0 of multiboot->flags is unset. Not trusting memory map values.\n");
}
That's wrong!
There are 2 different pieces of "memory" information. The first piece is the "memoryLower" and "memoryUpper" fields. On modern hardware, these fields are mostly just a worthless joke that can't work properly and shouldn't be used. The problem is that you can have multiple areas of RAM above 0x00100000 and it can only report one of them as "upper memory". The other problem is that they don't tell you anything useful (like which areas are safe for the OS to use for memory mapped PCI devices, which areas need special attention for ACPI to work, etc).
The second piece of "memory" information is the memory map, which gives you a list of "address, length, type" entries that describe the physical address space (excluding areas used by devices). This is the only usable option on modern hardware.
The flag you're talking about determines if the memory map is present (and has nothing to do with the "memoryLower" and "memoryUpper" fields). If this flag says that there's no memory map, then you can assume the computer is ancient (e.g. an 80486 or older that doesn't support the "int 0x15, eax=0xE820" BIOS function), and you can either use the "memoryLower" and "memoryUpper" fields as a fall-back or refuse to boot.
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.
That makes more sense. I was wondering about that, thanks for clearing it up. So the proper way would be to use the memory map and calculate the amount of available memory using the entries?
wxwsk8er wrote:That makes more sense. I was wondering about that, thanks for clearing it up. So the proper way would be to use the memory map and calculate the amount of available memory using the entries?
Yes - depending on how you define "available memory", it'd be something roughly similar to a "for each entry { if (entry.type == usable_RAM) total += entry.length; }" loop.
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.
I'd say that total memory would be the amount of undamaged memory installed (even if it is unavailable to the OS)
I'd say usable memory would be memory that is installed and available to the OS.
Thanks for the clarification! I've been reading and trying to grasp some memory-management concepts, so the explanations are great
wxwsk8er wrote:I'd say that total memory would be the amount of undamaged memory installed (even if it is unavailable to the OS)
In that case, you can't really determine total memory from the memory map alone (because you can't know which "reserved by firmware" areas are actually RAM) and would probably need to use system management BIOS tables to get the total memory installed (and then subtract any "faulty" RAM reported by the memory map).
wxwsk8er wrote:I'd say usable memory would be memory that is installed and available to the OS.
In that case, you'd probably want to include "ACPI reclaimable" area/s, and exclude partial pages (e.g. if there's a page at 0x9F000 that is half RAM and half reserved and OS can't use it because OS only uses whole pages, then it wouldn't be counted as "available").
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.
