[PATCH] Split model_67x CPU support from model_6xx, with microcode / L2 cache code question

[Keith Hui]

On Tue, Oct 12, 2010 at 7:23 PM, Uwe Hermann  wrote:
> Can you post an extra patch for splitting off CPUs to make it easier to
> review? The last one was merged into the already huge L2 patch which
> made it really hard to read.

And you shall receive, in small delicious pieces. :D

Attached patch adds support for Katmai Slot 1 CPUs (model_67x).
abuild-tested. Boot tested on P2B-LS.

Signed-off-by: Keith Hui

Similar patch for Deschutes(65x) and Klamath (63x) to come, but I need
someone else to boot test them.
> After the split, your L2 patch should be relatively small and clean,
> please repost that too then.

As we already know the L2 patch is a huge chunk of code, so let's
figure out where best to place that code. It is specific to 63x,65x
and 67x CPUs. There are some small code path differences between these
CPU families. I'm trying to minimize duplication; if these code can be
put in one .c file and be linked from a few other places, that's how
I'd prefer it.

Thanks
Keith

[Uwe Hermann]

On Tue, Oct 12, 2010 at 11:41:24PM -0400, Keith Hui wrote:
> Attached patch adds support for Katmai Slot 1 CPUs (model_67x).
> abuild-tested. Boot tested on P2B-LS.
>
> Signed-off-by: Keith Hui

Thanks, r5950 with some small whitespace changes.

I also dropped the name.o from Makefile.inc, the functions provided
there are not (yet?) used in model_67x I think.

Also, you added 671 as CPU ID to model_67x which was not in there yet.
Can you point me to the document where this one is listed, so we can
reference it in a code comment?
> As we already know the L2 patch is a huge chunk of code, so let's
> figure out where best to place that code. It is specific to 63x,65x
> and 67x CPUs. There are some small code path differences between these
> CPU families. I'm trying to minimize duplication;

Yep.
> if these code can be
> put in one .c file and be linked from a few other places, that's how
> I'd prefer it.

Yes, that would be great.

Uwe.

[Keith Hui]

On Wed, Oct 13, 2010 at 1:03 PM, Uwe Hermann  wrote:
> On Tue, Oct 12, 2010 at 11:41:24PM -0400, Keith Hui wrote:
> > Attached patch adds support for Katmai Slot 1 CPUs (model_67x).
> > abuild-tested. Boot tested on P2B-LS.
> >
> > Signed-off-by: Keith Hui
>
> Thanks, r5950 with some small whitespace changes.
>
> I also dropped the name.o from Makefile.inc, the functions provided
> there are not (yet?) used in model_67x I think.
>
> Also, you added 671 as CPU ID to model_67x which was not in there yet.
> Can you point me to the document where this one is listed, so we can
> reference it in a code comment?

There are two references of that CPU ID that I know of. I found a
microcode update for a 0x671 CPU from the Intel file. Then I remember
looking at Intel's processor finder website and found mentions of it.
Now that site has been reorganized as ark.intel.com I can no longer
easily confirm which S-spec CPUs will identify as 0x671. It's there
for completeness.
> > As we already know the L2 patch is a huge chunk of code, so let's
> > figure out where best to place that code. It is specific to 63x,65x
> > and 67x CPUs. There are some small code path differences between these
> > CPU families. I'm trying to minimize duplication;
>
> Yep.
> > if these code can be
> > put in one .c file and be linked from a few other places, that's how
> > I'd prefer it.
>
> Yes, that would be great.

So the question now is where in the tree? This can for example be
potentially placed in
cpu/intel/slot_1 because only slot 1 CPUs need the setup
cpu/intel/model_67x because I'm going to start here first
among a few other candidates.

Thanks
Keith

[PATCH] Split model_67x CPU support from model_6xx, with microcode / L2 cache code question

[Peter Stuge]

Keith Hui wrote:
> > > if these code can be put in one .c file and be linked from a few
> > > other places, that's how I'd prefer it.
> >
> > Yes, that would be great.
>
> So the question now is where in the tree? This can for example be
> potentially placed in
> cpu/intel/slot_1 because only slot 1 CPUs need the setup

If the code will be used by several slot 1 CPUs and no others then I
think this is where it should go.

//Peter