[coreboot] kconfig option VAR_MTRR_HOLE prevents write combining when 4GB or more DRAM is used

Scott Duplichan scott at notabs.org
Fri Nov 12 07:49:29 CET 2010


The kconfig option VAR_MTRR_HOLE prevents some linux kernel
versions from making the video frame buffer write combining when
4GB or more DRAM is used. These linux kernel versions add a WC
variable MTRR range to make the video frame buffer write
combining. With VAR_MTRR_HOLE disabled, it works as expected:

cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xe0000000 (3584MB), size=  16MB: write-combining, count=1
(linux added the third range)

When VAR_MTRR_HOLE is enabled, linux does not add the WC range,
and logs a warning message:

cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
reg01: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
dmesg
mtrr: type mismatch for e0000000,1000000 old: write-back new: write-combining

The reason it fails in the second example is that linux knows
memory covered by a variable MTRR range of type UC cannot be
changed to a different type by overlapping a new MTRR range.
For this reason, VAR_MTRR_HOLE should be not be used. The 
justification for the VAR_MTRR_HOLE method is to conserve
variable MTRR pairs. There are other ways to conserve MTRR ranges.
For example, AMD systems can use Tom2ForceMemTypeWB to avoid
the need for MTRR ranges above 4GB. Intel systems could sacrifice
a small abount of DRAM when very small holes cause excessive MTRR
consumption.

Here is a non-coreboot example of the same problem:
https://bugs.launchpad.net/linux/+bug/210780

I am thinking that once the AMD Tom2ForceMemTypeWB support is in
place, we should switch the default for AMD systems so that
this linux write combining problem can be avoided.

Thanks,
Scott





More information about the coreboot mailing list