Kexec on arm64

[Geoff Levand]

Hi Arun,

On Fri, 2014-07-11 at 21:13 +0530, Arun Chandran wrote:
> I tried kexec reboot with my modified kexec-tools and got a nice kernel panic.
> Please find the error log attached.
> There is only dtb file related change in the kernel sources, as given below.
> 
> ###########
>                         cpu-release-addr = <0x1 0x0000fff8>;
> -                       cpu-return-addr = <0 0>
> +                       cpu-return-addr = <0x0 0x0>;
> ###########
> 
> I just assigned a random value to "cpu-return-addr" in my dtb file;

You need the proper cpu-return-addr value.  Because cpu-return-addr
was zero, kexec sent all your secondary processors back to
secondary_startup, and is why you see that in your error log.

I put in a hack for zero cpu-return-addr in my latest version.  Please
try it.  If you use the same kernel for both the 1st and 2nd stage it
should work.

> Do you have any idea how to find out that value for my hardware?

It is a property of your bootloader, not hardware.  Ask your
bootloader maintainer if you can, or check the bootloader sources.

For the rtsm_ve_aemv8a model bootwrapper I set cpu-return-addr to
<0x0 0x80000000> because the bootwrapper linker script puts _start
at PHYS_OFFSET, which is 0x80000000 for that platform.

https://git.kernel.org/cgit/linux/kernel/git/mark/boot-wrapper-aarch64.git/tree/model.lds.S#n30

> My hardware uses spin-table method for SMP. As you said there
> is a bug in kexec for spin-table method, what about trying it without
> CONFIG_SMP? Does your code support that?

CONFIG_SMP=n should work, but I haven't tried it in a long time.

-Geoff