On Sat, 28 Jan 2017 17:01:05 +0100 Zoran Stojsavljevic zoran.stojsavljevic@gmail.com wrote:
Hello Stefan,
Let me ask you for some other stuff, since I would like to put what I wrote initially to hold (sleep state, for now).
You wrote: *The official specs are not trustworthy IMHO and cpuid(1) and /proc/cpuinfo **show the same physical address width of 36 bits (which would indicate a **maximum of 64 GB).*
Question to you: are you dealing with i686 kernel, (32 bit)? It seems to me that you have Nehalem which complies in IA32 with PAE HW extension, don't you?!
This is very important -> *Enabling PAE (by setting bit 5, PAE, of the system register CR4) causes major changes to this scheme...*
Both CPUs have PAE support, yes, but I think I have never even tried to boot a 32-bit kernel on them :) However, cpuid with an x86_64 kernel shows (assumably via the cpuid op and edx):
physical address extensions = true
But that does only indicate support not use of PAE... I don't see how this would be relevant to memtest or the 64-bit kernels anyway.
Both CPUs have PAE support, yes, but I think I have never even tried to boot a 32-bit kernel on them :)
This is one missing info. Because, so far, if you did not know, there are two types of 32-bit kernels: normal 32 bit, and PAE 32 bit. But, in contrary, x86_64 has only one type of kernel support regarding MMU.
Why? Because for i686 the following is true: Memory Management Unit (MMU) differently are expected to emulate the three-level page tables. For example, on the x86 without PAE enabled, only two page table levels are available.
With non PAE 32 kernels, the PA space is limited to 32 bits, thus making ONLY 4GB to be used/available! With PAE, PA is extended to 64GB. VA is limited (in both cases) to 4GB.
But that does only indicate support not use of PAE... I don't see how this would be relevant to memtest or the 64-bit kernels anyway.
For x86_64 (good that you are using ONLY these types of kernels) VA is 64 bits, but in reality it is limited to 48 bits (256TB).
However, cpuid with an x86_64 kernel shows (assumably via the cpuid op
and edx):
physical address extensions = true
PA supported is 52 bits (1000TBs). So, it is actually limited by number of DIMM memory slots you have in your system (4 X 8GB DIMM slots). In general cases up to 256GB, maybe few TB (server configuration wise). _______
The current raminit for Nehalem in coreboot is not able to train the two 8 GB DIMMs I have tested so far. I have added a debug output to choose_reg178 in the first loop before the margins are compared to STANDARD_MIN_MARGIN that shows that all margins are 0.
I would suggest to you to do the following: to return to the platform true BIOS, and to see if BIOS works with your Arrandale i5-520M (Thinkpad 410). Then you can try several different DIMM configurations, and see if BIOS supports up to maximum of 32GB (4 X 8GB DIMM).
Then, from these BIOS experiments, you can draw obvious conclusions in relations with Coreboot MRC algorithm. :-)
Zoran _______
On Sat, Jan 28, 2017 at 5:41 PM, Stefan Tauner < stefan.tauner@alumni.tuwien.ac.at> wrote:
On Sat, 28 Jan 2017 17:01:05 +0100 Zoran Stojsavljevic zoran.stojsavljevic@gmail.com wrote:
Hello Stefan,
Let me ask you for some other stuff, since I would like to put what I
wrote
initially to hold (sleep state, for now).
You wrote: *The official specs are not trustworthy IMHO and cpuid(1) and /proc/cpuinfo **show the same physical address width of 36 bits (which would indicate a **maximum of 64 GB).*
Question to you: are you dealing with i686 kernel, (32 bit)? It seems to
me
that you have Nehalem which complies in IA32 with PAE HW extension, don't you?!
This is very important -> *Enabling PAE (by setting bit 5, PAE, of the system register CR4) causes major changes to this scheme...*
Both CPUs have PAE support, yes, but I think I have never even tried to boot a 32-bit kernel on them :) However, cpuid with an x86_64 kernel shows (assumably via the cpuid op and edx):
physical address extensions = true
But that does only indicate support not use of PAE... I don't see how this would be relevant to memtest or the 64-bit kernels anyway.
-- Kind regards/Mit freundlichen Grüßen, Stefan Tauner