* 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? 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
