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: [email protected] [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 06, 2005 1:26 PM To: Lu, Yinghai Cc: Jason Schildt; [email protected] Subject: Re: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16 "Lu, Yinghai" <[EMAIL PROTECTED]> 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 mailing list [email protected] http://www.openbios.org/mailman/listinfo/linuxbios
