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 Marc -- http://se-eng.com -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
