[coreboot] "WARNING: BIOS bug: CPU MTRRs don't cover all of memory" loosing 2048MB of ram
enok at lysator.liu.se
Tue Oct 4 23:43:15 CEST 2011
On 10/04/2011 06:45 PM, Marc Jones wrote:
> On Tue, Oct 4, 2011 at 7:14 AM, Oskar Enoksson<enok at 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
>> (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
>> 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
>> 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.
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.
More information about the coreboot