[PATCH] ARM: omap2+: Revert omap-smp.c changes resetting cpu1 during boot

[Tony Lindgren]

* Tony Lindgren <tony at atomide.com> [170216 08:11]:
> * Tony Lindgren <tony at atomide.com> [170215 14:28]:
> > * Andrew F. Davis <afd at ti.com> [170215 14:14]:
> > > On 02/15/2017 01:12 PM, Tony Lindgren wrote:
> > > > And also the same issue happens doing kexec on beagle-x15 naturally if
> > > > the cpu1 reset is removed.
> > > > 
> > > 
> > > When a core actually powers up it idles in ROM code waiting for
> > > OMAP_AUX_CORE_BOOT_0 to be set. When we shutdown a core it is not really
> > > powered off, we just let it spin in omap4_cpu_die() or
> > > omap4_secondary_startup() waiting on OMAP_AUX_CORE_BOOT_0, just like if
> > > it were still trapped in ROM after a reset.
> 
> OK so I debugged this a bit more. We have CPU1 in omap_do_wfi()
> as we don't currently have omap5_secondary_startup() or any deeper
> idle mode support beyond retention for omap5 or dra7 in the mainline
> kernel.
> 
> > > The issue with this fake startup idle loop is that, unlike the ROM based
> > > startup idle loop, these do *not* jump to the address we stored in
> > > OMAP_AUX_CORE_BOOT_1, they just make the assumption that they can safely
> > > jump to the kernel startup function.
> 
> This does not seem to be the case here.
> 
> > > So when we tell this core to boot, and it is not in the real ROM startup
> > > loop, it breaks stuff as it jumps to the old kernel's
> > > secondary_startup() even though we gave it the correct address in
> > > OMAP_AUX_CORE_BOOT_1.
> 
> And this is not happening. I think this is what I was seeing earlier,
> but it's not the omap5/dra7 issue.
> 
> What we have is cpu1 returning from previous kernel's omap_do_wfi()
> in the kexec booted kernel's code and that's when things go wrong.
> 
> So if cpu1 was configured for idle for any reason, it will never gets
> to omap5_secondary_startup without the reset currently.
> 
> The reason kexec and suspend/resume mostly works for omap4 without
> cpu1 reset is that we usually enter off mode for cpu1 and the context
> is lost and then we properly go through omap4_secondary_startup. Or
> that's my theory so far for the occasional flakeyness I've been seeing :)
> 
> Any ideas what we should try to check to see if cpu1 is in idle
> mode so we can do the reset if needed?

Maybe we should do the reset if OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET
is not 0?

Regards,

Tony