CPU refactoring status....

Eric W. Biederman ebiederman at lnxi.com
Wed Jun 30 23:20:00 CEST 2004


Ok before I head to bed and get some sleep here is a quick status
update of my refactoring the cpu initialization code.

The cpu tree for x86 cpu now looks like:

cpu/x86/mtrr
cpu/x86/lapic
cpu/x86/fpu
cpu/x86/mmx
cpu/x86/sse
... One directory for each generic feature we may want to reuse

cpu/intel/model_f0x/
cpu/intel/model_f1x/
cpu/intel/model_f2x/
cpu/intel/model_f3x/
... One directory for each core that is supported.
    The numbers are the significant bits from cpuid.
    Stepping differences are conglerated together.

cpu/intel/socket_mPGA603/
cpu/intel/socket_mPGA604_533Mhz/
cpu/intel/socket_mPGA604_800Mhz/
... One directory for each socket we support.
    These will use the dir directive to suck in the appropriate cores.

cpu/amd/model_fxx/ 
... So far for Opteron AMD really only has one core, with multiple steppings

cpu/amd/socket_940/
cpu/amd/socket_939/
cpu/amd/socket_754/
... But there are currently 3 sockets I need to support.

cpu/x86/socket7
... Generic sockets supported my multiple vendors go here.


arch/i386/lib/cpu.c now computes the vendor and device information
of each cpu with cpuid.  And then looks up the appropriate code in a
table.

I have sorted out cpus in the device tree and assigning their
apic id's in the static tree.

The next big task is to get make the SMP cpu initialization methods
normal device tree methods.  I have everything ready to do that
except I need a good way to get the information in the struct
mem_range array by sizeram().   My gut feel is that I want to
incorporate the sizeram functionality into the resource allocator,
we will see.

As for the rest of the pieces I have started on there are still
a lot of details to flesh out but the with the structure there
it is just a matter of taking the time to do everything.

Eric



More information about the coreboot mailing list