[coreboot] [PATCH] Streamline CPU_ADDR_BITS usage
uwe at hermann-uwe.de
Mon Oct 4 09:39:55 CEST 2010
On Sun, Oct 03, 2010 at 10:58:30PM -0700, Warren Turkal wrote:
> Are there processors where that CPU_ADDR_BITS_MASK cannot be reliably
> retrieved from CPUID? What is the harm in using a value that is too
Looks like there are, at least a code comment which was in there
* This routine needs to know how many address bits a given processor supports
* (CONFIG_CPU_ADDR_BITS). CPUs get grumpy when you set too many bits in
* their MTRR registers. We could generically use CPUID here and find out how
* many are physically supported, but some CPUs are buggy, and report more
* bits than they actually support.
But I agree with you, I'd personally have no objections to using CPUID
per default, and allowing a "black-list" via kconfig variables which
use a value from the CPU's Kconfig if this CPU is known-bad (i.e.
reports an incorrect bit number).
> small for the CAR setup? In other words could we use the least common
> value for any CPU instead of having a different setting on each
> different chip?
What do you mean with "chip" here? The value is CPU-specific (not
socket-specific or board-specific). It's also implemented using a
per-CPU mechanism via kconfig in my patch.
http://hermann-uwe.de | http://sigrok.org
http://randomprojects.org | http://unmaintained-free-software.org
More information about the coreboot