Re: [coreboot] "WARNING: BIOS bug: CPU MTRRs don't cover all of memory" loosing 2048MB of ram
On 10/05/2011 12:30 AM, Marc Jones wrote:
On Tue, Oct 4, 2011 at 3:43 PM, Oskar Enokssonenok@lysator.liu.se wrote:
On 10/04/2011 06:45 PM, Marc Jones wrote:
On Tue, Oct 4, 2011 at 7:14 AM, Oskar Enokssonenok@lysator.liu.se wrote:
I incidently put 5GB RAM in my hp/dl145_g1 motherboard (2x1g+6x512m) and got the following error from Linux when booting:
"WARNING: BIOS bug: CPU MTRRs don't cover all of memory" loosing 2048MB of ram
(The dl145_g1 is a dual-socket amdk8 board with four DIMM's per CPU socket).
After digging around in the coreboot code I noticed that if I changed the last line in src/amd/amd_mtrr.c the generated MTRR was correct and the problem was solved:
/* Now that I have mapped what is memory and what is not * Setup the mtrrs so we can cache the memory. */
- x86_setup_var_mtrrs(address_bits, 0);
- x86_setup_var_mtrrs(address_bits, 1);
In cpu/x86/mtrr/mtrr.c the comments explains the last parameter in great detail:
void x86_setup_var_mtrrs(unsigned int address_bits, unsigned int above4gb) /* this routine needs to know how many address bits a given processor
- supports. CPUs get grumpy when you set too many bits in
- their mtrr registers :( I would generically call cpuid here
- and find out how many physically supported but some cpus are
- buggy, and report more bits then they actually support.
- If above4gb flag is set, variable MTRR ranges must be used to
- set cacheability of DRAM above 4GB. If above4gb flag is clear,
- some other mechanism is controlling cacheability of DRAM above 4GB.
*/
So - what "some other mechanism" is assumed to work on AMD cpu's and what should I do to make it work?
The patch described in
http://www.coreboot.org/pipermail/coreboot/attachments/20101111/7eff5b02/att... by Scott Duplichan tries to explain something, but I'm still not sure what to do.
The Fam10 and K8 have the AMD Tom2ForceMemTypeWB feature to avoid the need for variable MTRR ranges above 4GB. Either that isn't being set on your platform or your kernel is misreporting because it doesn't know about the feature.
Marc
It looks to me like AMD K8 processors don't have this feature.
On pp 314 of AMD Family 10 BKDG the bit is described "Tom2ForceMemTypeWB: top of memory 2 memory type write back. "
On pp 369 of AMD Hammer BKDG bits 22-64 are all Reserved.
So coreboot is wrong assuming there is such mechanism on amdk8.
The feature was added in the reg F, so without a version check there it could do the wrong thing. If you have a rev F or later you must have an old kernel.
http://kerneltrap.org/mailarchive/linux-kernel/2008/1/21/588155
Makes sense. My CPU is old (rev E) and my kernel is new (2.6.37). Coreboot should make variable MTRRs span memory >4GB if for K8 CPU rev <F.
-
Oskar Enoksson