Hello, This patch adds a new socket for FCPGA370 and PGA370 CPU's. This new socket (called socket_FC_PGA370) will make the CAR transition alot easier. When done transitioning all the boards and cpu's the old socket_PGA370 (kind of misleading for the FC's) can be deleted as well as model_6xx. I will be testing a bunch of 370 cpu's this week so hopefully the model_6xx will be no longer needed. This patch also includes first CAR support for model_68x FCPGA CPU's.
Build and boot tested.
Signed-off by: Joseph Smith joe@settoplinux.org
On 6/20/10 10:04 AM, Joseph Smith wrote:
with two caveats:
Acked-by: Stefan Reinauer stepan@coresystems.de
FCPGA
FCPGA
FCPGA
FCPGA
FCPGA
This should be FCPGA370 or mFCPGA370
[..]
Do add 680 here too. In fact, if you add 680 all the others can be omitted.
On 06/20/2010 07:46 AM, Stefan Reinauer wrote:
I wanted to keep them separated because Socket 370 supports PGA370 and FCPGA370 processors, this way they are both covered.
No, "m" means mobile chip. Socket 370 is not a mobile chip.
ok, why? 680 will cover everything?
On 20.06.2010, at 14:44, Joseph Smith joe@settoplinux.org wrote:
Hm ok
Afaik the m in mfcpga means micro
Yes. It will mask the ID with fff0
Hmm. If I add 0x0680 and delete the others I get:
Initializing CPU #0 CPU: vendor Intel device 68a CPU: family 06, model 08, stepping 0a Using generic cpu ops (good) Enabling cache microcode_info: sig = 0x0000068a pf=0x00000010 rev = 0x00000000 microcode updated to revision: 00000001 from revision 00000000
---- Before I did not get the "Using generic cpu ops (good)" is that ok?
On Mon, 21 Jun 2010 09:57:36 +0200, Peter Stuge peter@stuge.se wrote:
Hmm, to me it suggests it is using a _fail_safe_ because it can't find the correct (0x068a) device. It works fine eithor way but I don't think the _fail_safe_ is supposed to be the "normal" method.
Joseph Smith wrote:
It says "generic" and "good" - not even "default" nor anything else that might suggest a failure to me. :)
As could be expected from the code, that message is printed after the CPU is known when disregarding stepping.
$ grep -rn 'Using generic cpu ops' .|grep -v '/.svn/' ./arch/i386/lib/cpu.c:253: printk(BIOS_DEBUG, "Using generic cpu ops (good)\n");
//Peter
On Mon, 21 Jun 2010 11:48:33 +0200, Peter Stuge peter@stuge.se wrote:
Ok, now lets look at the whole function:
/* Lookup the cpu's operations */ set_cpu_ops(cpu);
if(!cpu->ops) { /* mask out the stepping and try again */ cpu->device -= c.x86_mask; set_cpu_ops(cpu); cpu->device += c.x86_mask; if(!cpu->ops) die("Unknown cpu"); printk(BIOS_DEBUG, "Using generic cpu ops (good)\n"); }
Hmm, to me this is a _fail_safe_ or _fall_back_. cpu->ops fails because it is not able to find cpu->device so it runs this function to "try again".
On 6/21/10 12:15 PM, Joseph Smith wrote:
Yes, it tries without the mask, i.e for 681 - 68f it tries 680. Then, if that does not match, it dies with "Unknown CPU". There is no failsafe nor fallback involved. What makes you think there is? It just means adding 1 entry to the table instead of 16.
Stefan.
On Mon, 21 Jun 2010 12:35:13 +0200, Stefan Reinauer stepan@coresystems.de wrote:
this
Ok, if it is not a _fail_safe_ or _fall_back_ why don't we just always do this as a default? Why print out a "generic" message?
My understanding is that barring errata, the stepping shouldn't matter. Just in case it does, we check it. If there isn't a specific entry for the stepping, we go to the "normal" case of using the ops without the stepping information.
Why print out a "generic" message?
I think it just means "not-stepping-specific"
Thanks, Myles
On 06/20/2010 08:52 AM, Stefan Reinauer wrote:
Done, thanks r5636
FYI, after a little reading it looks like the Tualatin was actually the first unofficial micro cpu. The first official micro cpu's started with the mobile PIII and Celerons. That is probably why I got the two confused :-)
-
Joseph Smith -
Myles Watson -
Peter Stuge -
Stefan Reinauer -
Stefan Reinauer