"Lu, Yinghai" yinghai.lu@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