Re: [coreboot] "WARNING: BIOS bug: CPU MTRRs don't cover all of memory" loosing 2048MB of ram
On 10/04/2011 06:45 PM, Marc Jones wrote:
On Tue, Oct 4, 2011 at 7:14 AM, Oskar Enokssonenok@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
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.
On Tue, Oct 4, 2011 at 2:43 PM, Oskar Enoksson enok@lysator.liu.se wrote:
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.
only cpus after K8 rev F (included), have that feature.
corresponding kernel code:
/* * Newer AMD K8s and later CPUs have a special magic MSR way to force WB * for memory >4GB. Check for that here. * Note this won't check if the MTRRs < 4GB where the magic bit doesn't * apply to are wrong, but so far we don't know of any such case in the wild. */ #define Tom2Enabled (1U << 21) #define Tom2ForceMemTypeWB (1U << 22)
int __init amd_special_default_mtrr(void) { u32 l, h;
if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD) return 0; if (boot_cpu_data.x86 < 0xf) return 0; /* In case some hypervisor doesn't pass SYSCFG through: */ if (rdmsr_safe(MSR_K8_SYSCFG, &l, &h) < 0) return 0; /* * Memory between 4GB and top of mem is forced WB by this magic bit. * Reserved before K8RevF, but should be zero there. */ if ((l & (Tom2Enabled | Tom2ForceMemTypeWB)) == (Tom2Enabled | Tom2ForceMemTypeWB)) return 1; return 0; }
On Tue, Oct 4, 2011 at 3:43 PM, Oskar Enoksson enok@lysator.liu.se wrote:
On 10/04/2011 06:45 PM, Marc Jones wrote:
On Tue, Oct 4, 2011 at 7:14 AM, Oskar Enokssonenok@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
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
-
Marc Jones -
Oskar Enoksson -
yhlu