On Fri, May 4, 2018 at 8:49 PM, Kyösti Mälkki kyosti.malkki@gmail.com wrote:
On Fri, May 4, 2018 at 8:22 PM, Aaron Durbin adurbin@google.com wrote:
On Fri, May 4, 2018 at 11:16 AM, Kyösti Mälkki kyosti.malkki@gmail.com wrote:
On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki kyosti.malkki@gmail.com wrote:
On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin adurbin@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?