[coreboot] PC Engines apu2 boot regression

[Marshall Dawson]

>
> 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 at coreboot.org> wrote:

> On Fri, May 4, 2018 at 11:16 AM, Kyösti Mälkki <kyosti.malkki at gmail.com>
> wrote:
> > On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki <kyosti.malkki at gmail.com>
> wrote:
> >> On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin <adurbin at 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 at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180504/e0903814/attachment.html>