-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 05/05/2018 11:53 AM, Kyösti Mälkki wrote:
On Sat, May 5, 2018 at 3:06 AM, Marshall Dawson marshalldawson3rd@gmail.com wrote:
My current guess is AP CPUs do not see initialised memory for _car_region_start .. _end. That region is set up using fixed MTRRs in low memory and probably not synced between cores so early in romstage.
Kyosti, I haven't kept a close watch on CAR changes in the other AMD systems, however in experimenting with CZ using ST source I found that 4 cores had a problem using CAR globals, so I think you're on the right track. AMD's CAR setup code assumes each core only needs fixed MTRRs configured for their own particular region of storage -- they all don't get access to 100% of the CAR area. Going from 2 cores (ST) to 4 cores (CZ), the higher two cores could no longer access the CAR globals at the bottom of the region. Try this hack and see if it improves for you:
Hi Marshall
Thanks, your suggested MTRR change seems to solve the regression. It was definetely about CAR_GLOBALs failing for AP CPUs in general. We just had not hit this case before for typical builds, as use of POSTCAR_STAGE barely avoided the error from triggering.
So did you hit problems with CAR_GLOBAL in agesa_get_dispatcher(), when experimeting CZ vs ST? I don't see why this code works even for dual-core ST but I did not evaluate CAR layout. Documentation part for fixed MTRRs in gcccar.inc appears to be same.
Now, does this MTRR change have potential to actually become _the_ fix? I don't see why it could not. It's pretty much all that we can do with binaryPI, anything else touches the blobs.
Hi Marshall, Kyösti, also confirm that this patch fix regression on recent master. Will you sent patch?
Best Regards, - -- Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com