On 10/04/2011 06:45 PM, Marc Jones wrote:
On Tue, Oct 4, 2011 at 7:14 AM, Oskar Enoksson<[email protected]> 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.
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
