[LinuxBIOS] LNXI Merge: lnxi-patch-15/16
yinghai.lu at amd.com
Tue Sep 6 22:50:00 CEST 2005
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
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
> 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
More information about the coreboot