Hi, Holger,
On 26.01.2009 18:57 Uhr, Holger Hesselbarth wrote:
the time has come to contribute some real code. i decided to start with a generic cpu detection routine that at a later point should be able to detect all cpus from the original Pentium upwards. my next step is to write configuration functions for all models depending on the manufacturer. the first goal is to make L2 cache available for all Slot1/Socket370 processors. i already took a look at the L2 init code from coreboot v1 and i guess i got it. some official intel document on L2 cache init would help though. the benefit of a generic would be that exchanging the cpu wouldn't rise the need to compile a new bios first. even if changing from one manufacturer to another. the drawback of a generic init routine would be that all init routines would be included in the final bios. so the routines should be kept as short as possible. to make some things user-configurable i propose a new section in the options file: cpu settings. mttr configuration could be called from the configuration routines or included in them. any thoughts on that? i also propose to enforce maximum performance settings on VIA/Cyrix, Centaur and older AMD processors as they have feature control registers which where meant to disable some advanced functions to maintain Intel Pentium compatibility. talking about Cyrix: i'll use the famous 5/2 division to identify the 6x86 with switched off cpuid and enable it by writing its internal configuration registers.
Can you explain a little bit how this is going to be different from what we do in coreboot v2 today?
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 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 - sets up the CPU's local APIC - loads CPU microcode - puts CPU to full speed via SpeedStep at al - enables errata fixes - sets up MTRRs according to your CPU, RAM and UMA graphics memory - starts secondary cores - and potentially does other things, like enable certain C4 settings, virtualization, cpu temperature sensors, ... (Especially this part could use some brush-up)
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.
Best regards, Stefan