RE: [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: [e-mail] [mailto:[e-mail]] 
Sent: Tuesday, September 06, 2005 1:26 PM
To: Lu, Yinghai
Cc: Jason Schildt; [e-mail]
Subject: Re: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16

"Lu, Yinghai"  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

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

"Lu, Yinghai"  writes:
> 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

The practical problem was not how much the code had to do
(except for failover.c) but instead how little of that code
was in common functions, and instead was per-motherboard.
Implementing on one motherboard while experimenting is fine but when
you go multi-board too much cut and paste is dangerous.

The first round of dual core and cache as ram code feels
like an old style adventure game:

You have now entered a twisty maze of ifdefs.

Eric

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

[yhlu]

I agree.

The cache_as_ram_auto.c should be the same to all Opteron MB except for 
1 spd rom related.
2 superio related

Other thing is need to consider apic id lifting.

So i consider change that to

#include "auto_1.c"
int someting spd and superio related
#include "auto_2.c"

YH

On 9/6/05, Eric W. Biederman  wrote:
> "Lu, Yinghai"  writes:
> > 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
>
> The practical problem was not how much the code had to do
> (except for failover.c) but instead how little of that code
> was in common functions, and instead was per-motherboard.
> Implementing on one motherboard while experimenting is fine but when
> you go multi-board too much cut and paste is dangerous.
>
> The first round of dual core and cache as ram code feels
> like an old style adventure game:
>
> You have now entered a twisty maze of ifdefs.
>
> Eric

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

yhlu  writes:
> I agree.
>
> The cache_as_ram_auto.c should be the same to all Opteron MB except for
> 1 spd rom related.
> 2 superio related
>
> Other thing is need to consider apic id lifting.
>
> So i consider change that to
>
> #include "auto_1.c"
> int someting spd and superio related
> #include "auto_2.c"

Boards can get weird and wonderful when their designers are creative.
So I would like to keep this as a matter of common subroutines we
can call, rather than magic includes.  The practical difference is
minimal, but common subroutines are much more readable.

Eric