On Sat, May 5, 2018 at 3:06 AM, Marshall Dawson <[email protected]> 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. Kyösti -- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
