[LinuxBIOS] LNXI Merge: lnxi-patch-15/16

[Lu, Yinghai]

I tried to make cache_as_ram_auto.c more smaller, the problem is 
I can not use jmp __cpu_reset, and I need use goto cpu_reset_x

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Tuesday, September 06, 2005 1:26 PM
To: Lu, Yinghai
Cc: Jason Schildt; linuxbios at openbios.org
Subject: Re: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16

"Lu, Yinghai" <yinghai.lu at amd.com> writes:

> I think CAR for AMD Opteron MB esp Tyan MBs are validated.
>
> I don't understand the #ifdef cause problem....
>
> And I didn't enable that on other MB that I can test.
>
> Also I didn't enable dual support for other MB too.
>
> You should know some MB don't support dual core because VRM
problem....,
> you could burn out the MB...
>
> So you could enable the dual core support for the MB that is not
> validated or talk to HW engineers of the MB vendors....

Agreed.  And we have not.  CONFIG_MAX_SIBLINGS is not defined.

A better explanation is that we had fundamental code cleanups
that conflict with the current CAR implementation.  In particular
look at k8_init_and_stop_secondaries() from patch 4/16.

It dramatically reduces the code duplication in auto.c by factoring
out a common function.  It was felt that maintainable code was
preferable to an optional feature.

The problem is that our method of detecting an init in
early_mtrr_init_detected() while general purpose doesn't work
if you have already played with the mttrs as the CAR code does.
So either a new technique init detection is needed or we need to
pass in a flag.

It should only be a few days work to fix the CAR code, to work
with the greatly simplified code base.

There was also a practical concern with the CAR in that you cannot
test changes to it except by flashing fallback which is contrary to
the spirit of fallback/normal image separation.

Again all minor practical problems, and not a criticism on the
technique itself.

Eric