[coreboot] generic cpu detection proposal

Holger Hesselbarth popkonserve at gmx.de
Tue Jan 27 19:05:06 CET 2009

Hi Stefan (and all others, too),

> At the moment a mainboard specifies one or more "CPU sockets" in the
> Config.lb file. Each socket "knows" which CPUs fit in there, and pulls

currently socket 370 is a synonym for all slot 1 and socket 370 processors which 
is quite okay since they are - at least in terms of configuration - the same. 
but currently socket 370 (and slot 2) is also a synonym for intel model_6xx 
which is not quite correct. VIA cpus could run on those, too. so socket 370 
should include at least VIA's init routines, too.
on the other hand: the init routines for most (all?) intel processors can be 
made generic so that they support the range from Pentium 1 on socket 7 to Core2 
on LGA775. at least the range from Pentium II to Pentium III including all 
Celeron models can be initialized with one quite simple routine. this would 
include all Xeon models, too.
the same accounts for VIA processors: the init routines for the onboard models 
are quite the same for the socket 370 models because they have similar/same cores.
we could have manufacturer wide init routines. or at least divide the 
manufacturer routines into groups. slot1/s370 should be one and contain routines 
for Intel (Celeron,Pentium II, Pentium III) and VIA (Cyrix III, C3) processors.
the intel routines could be reused in the slot 2 group (containing all Xeons 
really) and in future groups like LGA775.

> in the configuration/initialization code for those CPUs. During run-time
> the correct code for your cpu is chosen via the cpuid. That code
> - enables cpu cache

currently only the L1 cache is switched on. the L2 cache is left unconfigured 
and disabled at least for all socket 370 / slot 2 processors. there is a way to 
determine the size of the L2 cache on intel processors by reading the 
information the cpuid command supplies. it makes a generic L2 cache init routine 
quite easy. an intel document on L2 cache initialization could come in handy. it 
would be better than following the resourced v1 inititalization code.

> - sets up the CPU's local APIC
> - loads CPU microcode

currently only two microcode files are included. we could either include all 
microcodes supplied by intel resulting in a huge increase of codesize or dissect 
the file supplied by intel and only include updates that could affect cpus 
possibly be used on the socket. or we could ignore microcode updates completely 
as they are loaded by the OS (windows by default, linux by additional tool) anyway.
the file by intel currently contains microcode updates for all their processors 
from the pentium II upto their latest processor. they can be divided into groups 
of cores (by cpu id) and sockets (by platform id).

> It's not recommendable to make the MTRR user configurable, as they have
> to be set up according to the RAM in the machine. There's not much (or
> nothing?) to optimize by doing it manually.

sorry i didn't make myself clear. i was not talking about the MTRR but about the 
L2 cache latency. it can be made user configurable on intel Pentium II / III 
processors. abit's bios supports this feature, too. however there's no great 
impact on the performance. on the pentium iii the serial number can be 
enabled/disabled. and on VIA/Cyrix/Centaur cpus there are some performance 
features that could be user configurable. on those cpus one could even alter the 
processor name string but i'm not sure we should support things like that.

More information about the coreboot mailing list