[coreboot] [PATCH] Streamline CPU_ADDR_BITS usage

[Uwe Hermann]

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
suggests that:

/*
 * 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).

Something like

  select CPU_REPORTS_INVALID_ADDR_BITS_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.

 
Uwe.
-- 
http://hermann-uwe.de     | http://sigrok.org
http://randomprojects.org | http://unmaintained-free-software.org