Moving 440bx to V2

Eric W. Biederman ebiederman at lnxi.com
Wed Jan 12 17:28:04 CET 2005


Richard Smith <smithbone69 at yahoo.com> writes:

> I don't understand the cpu naming scheme in the
> cpu/intel dirctory.
> 
> Our board uses a PIII Celeron in a PGA socket 370 @
> 400 Mhz
> 
> should I just call the directory socket_PGA370 or do I
> need to add speed info?  What about the Celeron,
> non-celeron difference?

The idea is to filter the processors by which processors
will fit into a socket.  With recent Xeons Intel has reused
the same socket with a different pin-out.  The only name associated
with the pin out change is the processor front side bus frequency.
You can look up the appropriate Intel data sheets to figure
out what is socket compatible with what else.

If we fully supported it we would have a lot of potential cpus
and non-intel cpus that could plug into it.  So we would need
to include a bunch of directories.

Socket 370 is the first socket that Intel denied the clone
manufacturers from using I believe.  So the choice in cpus
should be fairly small.

After that I break the functionality by the information returned
by cpuid.  If the processors are significantly different I have
different directories for initializing them.  If the processors are
similar I have the same directory and look at the values cpuid returns
for the changes.

The idea is to differentiate things how it makes sense from a code
perspective, rather than how it makes sense from a vendor marketing
perspective.

As I recall the only real difference with Celerons is their reduction
in cache so we may get a fair amount of code sharing with other
processors.  I don't think the clock cycle changes at that point
caused a different socket pin out to be used.

And of course a lot of functionality is buried in cpu/x86/....
for code that is independent of a given processor model.

It is not a huge leap forward from where we used to be but it
is better, and the code has the very nice property that when
we encounter a new model of cpu (which for Intel almost always
requires a different microcode update) we have to explicitly allow
it to boot.  So the developers get a chance to verify the code is
going to work with the new cpu model.

Eric



More information about the coreboot mailing list