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