* Tero Kristo <t-kristo@xxxxxx> [170314 00:32]: > On 13/03/17 22:52, Tony Lindgren wrote: > > Additionally we also need to fix the hot-unplug code to properly park CPU1 > > to the bootrom loop so it's not affected by SDRAM changes done by kexec > > booting kernel. > > Imo, we are doing too much bandaid hackery for this issue now. How much do > we care if the older kernels don't work properly with kexec? I know I don't > care a bit myself. It means you just need to do 1 cold-boot for the system > to fix it. Well kexec is a standard Linux feature and it is currently working and at least I care. And if the CPU1 start-up address is programmed to be in the currently booting kernel's area by something else, it's almost certainly totally broken. Note that this still does not remove the need to park CPU1 properly to bootrom loop. > If we just drop all the cpu1 reset code and park cpu1 properly at end when > executing kexec we should be just fine, and the implementation will be much > cleaner. > > Does the wakeup issue for cpu1 ever happen with suspend, so that you > actually must reset the cpu so that it comes up? If that is the case, it is > going to be a tricky situation overall and we should understand the root > cause for it before trying to fix it. Yes omap4 CPU1 can fail occasional suspend/resume cycle. But let's assume that's a separate issue or a side effect of not properly initializing CPU1 during kexec before the suspend/resume cycle. I can do some more tests on that. 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
