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

[Oskar Enoksson]

On 10/05/2011 12:30 AM, Marc Jones wrote:
> On Tue, Oct 4, 2011 at 3:43 PM, Oskar Enoksson<enok at lysator.liu.se>  wrote:
>> 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
>>>> 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.
>>> 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.