So ive finished up pretty much everything for my memory detection, mapping and physical memory manager and sofar it's all great.
It has full e820 and acpi3 support, handles all the funny conditions that have been pointed out in terms of sorting,overlapping, zero or contained regions etc etc..
It does the fallbacks to other detection methods.
Now where I have a question is this..
I'm using a dell box that has 512Mb of memory (one of my test machines).
The whole range/mapping thing is perfect.. I try to calculate the total installed physical memory (IE: 512Mb) by taking the e820 map after processing and finding the highest start address that's not reserved, adding the length.
I then also check this against the values from the e801 function. On bochs/qemu and my laptop it works out perfectly to report the exact Mb installed. However on this one dell machine both methods yield 502.5Mb and there is a 9.5Mb reserved area from the e820 map.
So the question is how do i determine the EXACT amount of installed mem correctly, as this method although practical in terms of what the manager needs to do, yields odd values. I can't see any other way to calculate the total from the e820 map as a number of the start addresses (for non type 1 available) might not be physical addresses but just mapped into the address range < 4Gib even though the machine may have only 1Gb of physical mem.
Memory Map / Detect Issues
Re: Memory Map / Detect Issues
Additionally to this, I was wondering if it would be possible to get this total from ACPI tables, as well as more detailed info perhaps like the memory slots and what type of module is fitted in each, ddr2/3, ecc, speed, size... etc etc..
Re: Memory Map / Detect Issues
OpenBSD has that kind of detection for ram slots
like this is what I get:
As far as I can tell it reads this information from an EEPROM controlled by an i2c bus(or it could be the SMBus)
I attached the relevant source file, maybe it can give you a hint as to how to do what you wish.
like this is what I get:
Code: Select all
spdmem0 at iic0 addr 0x50: 512MB DDR SDRAM non-parity PC2700CL2.5
I attached the relevant source file, maybe it can give you a hint as to how to do what you wish.
- Attachments
-
- spdmem.c
- (22.24 KiB) Downloaded 68 times
Re: Memory Map / Detect Issues
I know on my Mac if I look at the system info it shows me a detailed view like that.. something along these lines:
slot 0: PC4200, 1024Mb, ECC, 533Mhz.
slot 1: empty
etc..
This information would be great to have in the os, although not essential really.. I just need a way to know how much memory is actually installed for now..
as all the boot/int functions seem to reduce this value.. I checked again on my laptop and it is the same as the dell desktop machine, it reports 2036Mb, so its also about 10Mb off..
Another thing that occurred to me is the following, on a machine with 512Mb->3Gb you seem to lose about 10Mb of installed memory according to these ints, but I would guess if you had 4Gig you would lose even more due to the other memory mapped devices etc now being forced to map over what would be useable address ranges.. as when the system starts up it cannot/should not map anything above 4gig as it can't make the assumption that the os will be 64bit even if the machine is capable of it.
slot 0: PC4200, 1024Mb, ECC, 533Mhz.
slot 1: empty
etc..
This information would be great to have in the os, although not essential really.. I just need a way to know how much memory is actually installed for now..
as all the boot/int functions seem to reduce this value.. I checked again on my laptop and it is the same as the dell desktop machine, it reports 2036Mb, so its also about 10Mb off..
Another thing that occurred to me is the following, on a machine with 512Mb->3Gb you seem to lose about 10Mb of installed memory according to these ints, but I would guess if you had 4Gig you would lose even more due to the other memory mapped devices etc now being forced to map over what would be useable address ranges.. as when the system starts up it cannot/should not map anything above 4gig as it can't make the assumption that the os will be 64bit even if the machine is capable of it.
Re: Memory Map / Detect Issues
Well, OpenBSD on this computer detects 504mb of usable memory out of 512mb actual memory, I assume that some tiny portion of memory is going to the onboard graphics card. I really think it's negligible to try to get exactly how much RAM they have rather than try to figure out how much you can usejohnsa wrote:I know on my Mac if I look at the system info it shows me a detailed view like that.. something along these lines:
slot 0: PC4200, 1024Mb, ECC, 533Mhz.
slot 1: empty
etc..
This information would be great to have in the os, although not essential really.. I just need a way to know how much memory is actually installed for now..
as all the boot/int functions seem to reduce this value.. I checked again on my laptop and it is the same as the dell desktop machine, it reports 2036Mb, so its also about 10Mb off..
Another thing that occurred to me is the following, on a machine with 512Mb->3Gb you seem to lose about 10Mb of installed memory according to these ints, but I would guess if you had 4Gig you would lose even more due to the other memory mapped devices etc now being forced to map over what would be useable address ranges.. as when the system starts up it cannot/should not map anything above 4gig as it can't make the assumption that the os will be 64bit even if the machine is capable of it.
Re: Memory Map / Detect Issues
"Installed memory" is one of those fairly useless things that is reported by SMBios code. You can't get there from an E820 map. An E820 map only tells you info that is useful to a kernel.
-
- Member
- Posts: 204
- Joined: Thu Apr 12, 2007 8:15 am
- Location: Michigan
Re: Memory Map / Detect Issues
It can and it might. If (assuming an x86 architecture) the CPUID instruction indicates the PAE feature, then the processor supports 36-bit physical addressing. The bios technically cannot assume that the OS will even be 32-bit, but even so it still maps many devices around 4GBs. What's more important is if the devices being mapped have a wide enough decoder to support a certain address, and that the processor can generate those addresses as well.johnsa wrote:as when the system starts up it cannot/should not map anything above 4gig as it can't make the assumption that the os will be 64bit even if the machine is capable of it.
Some people are offended by the verifiable truth; such people tend to remain blissfully unencumbered by fact.
If you are one of these people, my posts may cause considerable discomfort. Read at your own risk.
If you are one of these people, my posts may cause considerable discomfort. Read at your own risk.
Re: Memory Map / Detect Issues
Point taken, it could map things in above 4gig.. but i don't think it's very common yet, most probably due to the added complication of pae to address who knows what, extended bios, device memory etc if it might be needed pre pae enable.
The stuff ive got with my memory setup sofar works perfectly for returning the usable memory information (ie what would actually be of value to the os).
I just thought it would be nice / of interest to be able to additionally report the physical memory configuration as opposed to just the logic map.. ie slots/modules etc. It might be possible to use that info for some sort of optimization as well at some point, knowing up front what sort of memory type/speed is used without having to test it manually for performance. In any event it's not critical.. just nice to know
The stuff ive got with my memory setup sofar works perfectly for returning the usable memory information (ie what would actually be of value to the os).
I just thought it would be nice / of interest to be able to additionally report the physical memory configuration as opposed to just the logic map.. ie slots/modules etc. It might be possible to use that info for some sort of optimization as well at some point, knowing up front what sort of memory type/speed is used without having to test it manually for performance. In any event it's not critical.. just nice to know