On Tue, Oct 4, 2011 at 7:14 AM, Oskar Enoksson enok@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