On Fri, May 4, 2018 at 8:49 PM, Kyösti Mälkki <kyosti.mal...@gmail.com> wrote: > On Fri, May 4, 2018 at 8:22 PM, Aaron Durbin <adur...@google.com> 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? >> > > I have to check closer, but for apu2 this would be in AMD_INIT_EARLY > already, so AP CPUs run way before (the only) memory controller is > configured. I believe there is microcode updates and some CPU > registers that are also synced during AMD_INIT_EARLY. So it is doing > more than just bringing an idle AP task engine. > > I find it particularly hard to be civil on your first question, so > trying with sarcasm instead. After 5000 or so development hours and > direct support from AMD, is the boot sequence for soc/stoneyridge > prototypes equally bad, that is, AP CPUs execute through bootblock and > verstage?
They currently jump to where they are told at the moment. See bootblock_c_entry() in src/soc/amd/stoneyridge/bootblock/bootblock.c. There is no running through multiple stages within coreboot. I think you are right that guarding things w/ boot_cpu() would work. Is CONFIG_SQUELCH_EARLY_SMP set for all those types of boards? Or do we have a weird mix? Or should we have a Kconfig that says 'CAR' is not symmetric across cpus thus can't be used? -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot