Re: [coreboot] PC Engines apu2 boot regression

[Kyösti Mälkki]

On Sat, May 5, 2018 at 3:06 AM, Marshall Dawson
 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