* Tony Lindgren <tony@xxxxxxxxxxx> [170216 08:11]: > * Tony Lindgren <tony@xxxxxxxxxxx> [170215 14:28]: > > * Andrew F. Davis <afd@xxxxxx> [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
