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

[Marc Jones]

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


Marc


-- 
http://se-eng.com