[coreboot] "WARNING: BIOS bug: CPU MTRRs don't cover all of memory" loosing 2048MB of ram

Oskar Enoksson enok at lysator.liu.se
Tue Oct 4 15:14:18 CEST 2011


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/attachment-0001.txt 
by Scott Duplichan tries to explain something, but I'm still not sure 
what to do.






More information about the coreboot mailing list