Hi Geoff, I think we should better discuss this in the arm mailing list as it is getting more arm64 specific. I will post my reply there. --Arun On Tue, Jul 15, 2014 at 3:35 AM, Geoff Levand <geoff at infradead.org> wrote: > 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 > >
