<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My current guess is AP CPUs do not see initialised memory for<br>
_car_region_start .. _end. That region is set up using fixed MTRRs in<br>
low memory and probably not synced between cores so early in romstage.

<br></blockquote><div><br></div><div>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:<br><br>


diff --git a/src/vendorcode/amd/pi/<wbr>00730F01/binaryPI/gcccar.inc b/src/vendorcode/amd/pi/<wbr>00730F01/binaryPI/gcccar.inc<br>index 5a4f7b9..fd3bf81 100644<br>--- a/src/vendorcode/amd/pi/<wbr>00730F01/binaryPI/gcccar.inc<br>+++ b/src/vendorcode/amd/pi/<wbr>00730F01/binaryPI/gcccar.inc<br>@@ -1151,6 +1151,7 @@ SetupStack:<br>         or      %edi, %edx                #<br>     #.endif                       <wbr>       #<br>     0:<br>+    or $0x1e000000, %eax                # force 30000-40000 for cbmem access<br>     _WRMSR                        <wbr>      #<br> <br>     # Enable MTRR defaults as UC type<br>-- <br>

<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Ugh.  Why do we allow the APs to run through all these stages? Is this<br>
for parallel node memory training? Can we ring fence where the APs<br>
actually run better?

<br></blockquote><br></div><div>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().<br></div><div><br></div><div>Thanks,<br></div><div>Marshall<br></div><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 4, 2018 at 11:22 AM, Aaron Durbin via coreboot <span dir="ltr"><<a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, May 4, 2018 at 11:16 AM, Kyösti Mälkki <<a href="mailto:kyosti.malkki@gmail.com">kyosti.malkki@gmail.com</a>> wrote:<br>
> On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki <<a href="mailto:kyosti.malkki@gmail.com">kyosti.malkki@gmail.com</a>> wrote:<br>
>> On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin <<a href="mailto:adurbin@google.com">adurbin@google.com</a>> wrote:<br>
>>>><br>
>>>> Any idea what can be result of such weird behavior?<br>
>>><br>
><br>
> My current guess is AP CPUs do not see initialised memory for<br>
> _car_region_start .. _end. That region is set up using fixed MTRRs in<br>
> low memory and probably not synced between cores so early in romstage.<br>
><br>
<br>
</span>Ugh.  Why do we allow the APs to run through all these stages? Is this<br>
for parallel node memory training? Can we ring fence where the APs<br>
actually run better?<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> diff --git a/src/console/init.c b/src/console/init.c<br>
> index 8f71b09..4731e7e 100644<br>
> --- a/src/console/init.c<br>
> +++ b/src/console/init.c<br>
> @@ -35,7 +35,7 @@ static int console_loglevel = CONFIG_DEFAULT_CONSOLE_<wbr>LOGLEVEL;<br>
><br>
>  static inline int get_log_level(void)<br>
>  {<br>
> -       if (car_get_var(console_inited) == 0)<br>
> +       if (boot_cpu() && car_get_var(console_inited) == 0)<br>
>                 return -1;<br>
>         if (CONSOLE_LEVEL_CONST)<br>
>                 return get_console_loglevel();<br>
><br>
> Kyösti<br>
<br>
-- <br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/<wbr>mailman/listinfo/coreboot</a></div></div></blockquote></div><br></div>