* Andrew F. Davis <afd@xxxxxx> [170327 09:36]:
> On 03/14/2017 01:05 PM, Tony Lindgren wrote:
> > Commit 3251885285e1 ("ARM: OMAP4+: Reset CPU1 properly for kexec") started
> > unconditionally resetting CPU1 because of a kexec boot issue I was seeing
> > earlier on omap4 when doing kexec boot between two different kernel
> > versions.
> >
> > This caused issues on some systems. We should only reset CPU1 as a last
> > resort option, and try to avoid it where possible. Doing an unconditional
> > CPU1 reset causes issues for example when booting a bootloader configured
> > secure OS running on CPU1 as reported by Andrew F. Davis <afd@xxxxxx>.
> >
> > We can't completely remove the reset of CPU1 as it would break kexec
> > booting from older kernels. But we can limit the CPU1 reset to cases
> > where CPU1 is wrongly parked within the memory area used by the booting
> > kernel. Then later on we can add support for parking CPU1 for kexec out
> > of the SDRAM back to bootrom.
> >
> > So let's first fix the regression reported by Andrew by making CPU1 reset
> > conditional. To do this, we need to:
> >
> > 1. Save configured AUX_CORE_BOOT_1 for later
> >
> > 2. Modify AUX_CORE_BOOT_0 reading code to for HS SoCs to return
> > the whole register instead of the CPU mask
> >
> > 3. Check if CPU1 is wrongly parked into the booting kernel by the
> > previous kernel and reset if needed
> >
>
> I still don't like this style of workaround, if kexec cannot regain
> control of core1 without a hard core reset than kexec should BUG() and
> force the user to reboot to a sane state.
Yes problems still remains. I think the immediate fix there is to
disable kexec during runtime based on some criteria for your use
case rather than BUG() though. Somehow kexec needs to know if CPU1
reset is acceptable, then reset CPU1 before kexec.
> Anyway, this patch does remove the unconditional reset and fixes my
> use-case is some situations (when not using kexec) so:
>
> Tested-by: Andrew F. Davis <afd@xxxxxx>
OK thanks for testing.
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
