> > 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: diff --git a/src/vendorcode/amd/pi/00730F01/binaryPI/gcccar.inc b/src/vendorcode/amd/pi/00730F01/binaryPI/gcccar.inc index 5a4f7b9..fd3bf81 100644 --- a/src/vendorcode/amd/pi/00730F01/binaryPI/gcccar.inc +++ b/src/vendorcode/amd/pi/00730F01/binaryPI/gcccar.inc @@ -1151,6 +1151,7 @@ SetupStack: or %edi, %edx # #.endif # 0: + or $0x1e000000, %eax # force 30000-40000 for cbmem access _WRMSR # # Enable MTRR defaults as UC type -- Ugh. Why do we allow the APs to run through all these stages? Is this > for parallel node memory training? Can we ring fence where the APs > actually run better? > Aaron, on Stoney Ridge all cores needed to be alive in order to do memory training. It wasn't that they were used in the algorithm (as far as I've seen); they simply had to be there to prevent the northbridge from blowing up. I've long since forgotten what internal designs AMD used for Family 15h and 16h, but it seems likely the same limitation applies on Family 16h too. We occasionally discuss a different methodology of shutting down the APs immediately when they're released, and not letting them run through to InitEarly(). It seems like that ought to allow the northbridge to behave as expected during training in InitPost(). Thanks, Marshall On Fri, May 4, 2018 at 11:22 AM, Aaron Durbin via coreboot < coreboot@coreboot.org> wrote: > On Fri, May 4, 2018 at 11:16 AM, Kyösti Mälkki <kyosti.mal...@gmail.com> > wrote: > > On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki <kyosti.mal...@gmail.com> > wrote: > >> On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin <adur...@google.com> > wrote: > >>>> > >>>> Any idea what can be result of such weird behavior? > >>> > > > > 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. > > > > Ugh. Why do we allow the APs to run through all these stages? Is this > for parallel node memory training? Can we ring fence where the APs > actually run better? > > > > > diff --git a/src/console/init.c b/src/console/init.c > > index 8f71b09..4731e7e 100644 > > --- a/src/console/init.c > > +++ b/src/console/init.c > > @@ -35,7 +35,7 @@ static int console_loglevel = CONFIG_DEFAULT_CONSOLE_ > LOGLEVEL; > > > > static inline int get_log_level(void) > > { > > - if (car_get_var(console_inited) == 0) > > + if (boot_cpu() && car_get_var(console_inited) == 0) > > return -1; > > if (CONSOLE_LEVEL_CONST) > > return get_console_loglevel(); > > > > Kyösti > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot