[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