Kexec on arm64

Kexec on arm64

[Arun Chandran]

Hi,

I found the kexec development on arm64 here
http://www.spinics.net/lists/arm-kernel/msg329563.html

Went to try it on my armv8 hardware after cloning

git://git.linaro.org/people/geoff.levand/linux-kexec.git and
https://git.linaro.org/people/geoff.levand/kexec-tools.git

Did
1) ~/work/aarch64-kernel/kexec-tools$ ./bootstrap
2)~/work/aarch64-kernel/kexec-tools$ ./configure
--prefix=/tmp/kexec_install --host=aarch64-linux-gnu
3) make

and got this error

elf-arm64.o kexec/arch/arm64/kexec-elf-arm64.c
kexec/arch/arm64/kexec-elf-arm64.c: In function ‘elf_arm64_probe’:
kexec/arch/arm64/kexec-elf-arm64.c:32:24: error: ‘EM_AARCH64’
undeclared (first use in this function)
  if (ehdr.e_machine != EM_AARCH64) {
                        ^
kexec/arch/arm64/kexec-elf-arm64.c:32:24: note: each undeclared
identifier is reported only once for each function it appears in
make: *** [kexec/arch/arm64/kexec-elf-arm64.o] Error 1

Am I missing something here?

--Arun

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kexec on arm64

[Arun Chandran]

On Wed, Jul 9, 2014 at 3:43 PM, Arun Chandran <achandran@mvista.com> wrote:
> Hi,
>
> I found the kexec development on arm64 here
> http://www.spinics.net/lists/arm-kernel/msg329563.html
>
> Went to try it on my armv8 hardware after cloning
>
> git://git.linaro.org/people/geoff.levand/linux-kexec.git and
> https://git.linaro.org/people/geoff.levand/kexec-tools.git
>
> Did
> 1) ~/work/aarch64-kernel/kexec-tools$ ./bootstrap
> 2)~/work/aarch64-kernel/kexec-tools$ ./configure
> --prefix=/tmp/kexec_install --host=aarch64-linux-gnu
> 3) make
>
> and got this error
>
> elf-arm64.o kexec/arch/arm64/kexec-elf-arm64.c
> kexec/arch/arm64/kexec-elf-arm64.c: In function ‘elf_arm64_probe’:
> kexec/arch/arm64/kexec-elf-arm64.c:32:24: error: ‘EM_AARCH64’
> undeclared (first use in this function)
>   if (ehdr.e_machine != EM_AARCH64) {
>                         ^
> kexec/arch/arm64/kexec-elf-arm64.c:32:24: note: each undeclared
> identifier is reported only once for each function it appears in
> make: *** [kexec/arch/arm64/kexec-elf-arm64.o] Error 1
>

I compiled kexec-tools(
https://git.linaro.org/people/geoff.levand/kexec-tools.git)
by commenting that "machine check"

--- a/kexec/arch/arm64/kexec-elf-arm64.c
+++ b/kexec/arch/arm64/kexec-elf-arm64.c
@@ -28,12 +28,13 @@ int elf_arm64_probe(const char *kernel_buf, off_t
kernel_size)
                dbgprintf("Not an ELF executable.\n");
                goto on_exit;
        }
-
+#if 0
        if (ehdr.e_machine != EM_AARCH64) {
                dbgprintf("Not an AARCH64 executable.\n");
                result = -EINVAL;
                goto on_exit;
        }
+#endif

        result = 0;


After copying the resulting binaries to my target; I tried loading the
kernel Image

# kexec -l /Image
Modified cmdline: root=/dev/nfs
Unable to find /proc/device-tree//chosen/linux,stdout-path, printing
from purgatory is diabled
Cannot determine the file type of /Image

It failed to load the kernel Image. Any pointers?

--Arun














> Am I missing something here?
>
> --Arun

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kexec on arm64

[Geoff Levand]

Hi Arun,

On Wed, 2014-07-09 at 19:28 +0530, Arun Chandran wrote:
> After copying the resulting binaries to my target; I tried loading the
> kernel Image
> 
> # kexec -l /Image
> Modified cmdline: root=/dev/nfs
> Unable to find /proc/device-tree//chosen/linux,stdout-path, printing
> from purgatory is diabled
> Cannot determine the file type of /Image
> 
> It failed to load the kernel Image. Any pointers?

My kexec-tools [1] only supports loading of arm64 elf files, so
vmlinux, or a stripped version of it.  Image is a raw binary, and
is not yet supported.

Maybe something like this is what you need:

 ./kexec -d --load /boot/vmlinux.strip --append="console=ttyAMA0 earlyprintk=pl011,0x1c090000 root=/dev/vda rw --verbose" --dtb=/boot/fdt.dtb
 ./kexec -d -e

Also, my current master branch will only work reliably with PSCI
boot.  Spin-table boot has a bug and will be unstable for the next
few days.  Spin-table will re-boot, but only the primary cpu will
come up.

[1] https://git.linaro.org/people/geoff.levand/kexec-tools.git
 https://git.linaro.org/people/geoff.levand/linux-kexec.git

-Geoff


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kexec on arm64

[Arun Chandran]

Hi Geoff,

Finally I am able to get my kernel loaded with the patch below.


diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 894e0e1..bfca40d 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -327,7 +327,7 @@ static int get_memory_ranges_dt(struct
memory_range *array, unsigned int *count)
                        dbgprintf("%s:  RAM: %016llx - %016llx\n", __func__,
                                r.start, r.end);

-                       if (!arm64_mem.memstart || r.start < arm64_mem.memstart)
+                       if ((region->size) && (!arm64_mem.memstart ||
r.start < arm64_mem.memstart))
                                arm64_mem.memstart = r.start;
                }
        }


I suspect it was due to zero sized memory ranges in my dtb followed by the
actual region.

get_memory_ranges_dt: node_1676 memory
get_memory_ranges_dt:  RAM: 0000004000000000 - 0000004400000000
get_memory_ranges_dt:  RAM: 0000000000000000 - 0000000000000000
get_memory_ranges_dt:  RAM: 0000000000000000 - 0000000000000000
get_memory_ranges_dt:  RAM: 0000000000000000 - 0000000000000000
get_memory_ranges_dt:  RAM: 0000000000000000 - 0000000000000000

As a result of that arm64_mem.memstart was getting overwritten with zero.
and I was stuck at the error

kexec: kexec/arch/arm64/kexec-arm64.c:242: virt_to_phys: Assertion
`arm64_mem.memstart' failed.

So check the validity of region before updating the 'memstart'

I will try with kexec -e next.

--Arun






On Thu, Jul 10, 2014 at 12:19 AM, Geoff Levand <geoff@infradead.org> wrote:
> Hi Arun,
>
> On Wed, 2014-07-09 at 19:28 +0530, Arun Chandran wrote:
>> After copying the resulting binaries to my target; I tried loading the
>> kernel Image
>>
>> # kexec -l /Image
>> Modified cmdline: root=/dev/nfs
>> Unable to find /proc/device-tree//chosen/linux,stdout-path, printing
>> from purgatory is diabled
>> Cannot determine the file type of /Image
>>
>> It failed to load the kernel Image. Any pointers?
>
> My kexec-tools [1] only supports loading of arm64 elf files, so
> vmlinux, or a stripped version of it.  Image is a raw binary, and
> is not yet supported.
>
> Maybe something like this is what you need:
>
>  ./kexec -d --load /boot/vmlinux.strip --append="console=ttyAMA0 earlyprintk=pl011,0x1c090000 root=/dev/vda rw --verbose" --dtb=/boot/fdt.dtb
>  ./kexec -d -e
>
> Also, my current master branch will only work reliably with PSCI
> boot.  Spin-table boot has a bug and will be unstable for the next
> few days.  Spin-table will re-boot, but only the primary cpu will
> come up.
>
> [1] https://git.linaro.org/people/geoff.levand/kexec-tools.git
>  https://git.linaro.org/people/geoff.levand/linux-kexec.git
>
> -Geoff
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kexec on arm64

[Geoff Levand]

Hi Arun,

On Fri, 2014-07-11 at 14:53 +0530, Arun Chandran wrote:
> Finally I am able to get my kernel loaded with the patch below.

OK, great.

> I suspect it was due to zero sized memory ranges in my dtb followed by the
> actual region.

Could you please send me your dts?  If you don't want to post it to the
list, could you send it to me in a private mail?

-Geoff


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kexec on arm64

[Arun Chandran]

Hi Geoff,

This is a minor "NULL check" issue in the code.

kexec fails to load, without kernel command line option (--append).

The below code fixes that issue (missing null check.

diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 894e0e1..0ca0df4 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -135,8 +135,10 @@ int arm64_load_other_segments(struct kexec_info *info)

        /* Processing for arm64_opts.dtb and arm64_opts.command_line. */

-       strncpy(command_line, arm64_opts.command_line, sizeof(command_line));
-       command_line[sizeof(command_line) - 1] = 0;
+       if (arm64_opts.command_line != NULL) {
+               strncpy(command_line, arm64_opts.command_line,
sizeof(command_line));
+               command_line[sizeof(command_line) - 1] = 0;
+       }


--Arun







On Thu, Jul 10, 2014 at 12:19 AM, Geoff Levand <geoff@infradead.org> wrote:
> Hi Arun,
>
> On Wed, 2014-07-09 at 19:28 +0530, Arun Chandran wrote:
>> After copying the resulting binaries to my target; I tried loading the
>> kernel Image
>>
>> # kexec -l /Image
>> Modified cmdline: root=/dev/nfs
>> Unable to find /proc/device-tree//chosen/linux,stdout-path, printing
>> from purgatory is diabled
>> Cannot determine the file type of /Image
>>
>> It failed to load the kernel Image. Any pointers?
>
> My kexec-tools [1] only supports loading of arm64 elf files, so
> vmlinux, or a stripped version of it.  Image is a raw binary, and
> is not yet supported.
>
> Maybe something like this is what you need:
>
>  ./kexec -d --load /boot/vmlinux.strip --append="console=ttyAMA0 earlyprintk=pl011,0x1c090000 root=/dev/vda rw --verbose" --dtb=/boot/fdt.dtb
>  ./kexec -d -e
>
> Also, my current master branch will only work reliably with PSCI
> boot.  Spin-table boot has a bug and will be unstable for the next
> few days.  Spin-table will re-boot, but only the primary cpu will
> come up.
>
> [1] https://git.linaro.org/people/geoff.levand/kexec-tools.git
>  https://git.linaro.org/people/geoff.levand/linux-kexec.git
>
> -Geoff
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kexec on arm64

[Geoff Levand]

Hi Arun,

On Fri, 2014-07-11 at 16:56 +0530, Arun Chandran wrote:
> The below code fixes that issue (missing null check.

I just pushed out a fix for this, slightly different
from yours.  Please let me know if you still have a
problem with it.

-Geoff 


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kexec on arm64

[Arun Chandran]

Hi Geoff,

On Sat, Jul 12, 2014 at 5:49 AM, Geoff Levand <geoff@infradead.org> wrote:
> Hi Arun,
>
> On Fri, 2014-07-11 at 16:56 +0530, Arun Chandran wrote:
>> The below code fixes that issue (missing null check.
>
> I just pushed out a fix for this, slightly different
> from yours.  Please let me know if you still have a
> problem with it.
>

Got it. The loading part is fine with it.

kexec -e still giving troubles.


--Arun

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kexec on arm64

[Arun Chandran]

[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]

On Thu, Jul 10, 2014 at 12:19 AM, Geoff Levand <geoff@infradead.org> wrote:
> Hi Arun,
>
> On Wed, 2014-07-09 at 19:28 +0530, Arun Chandran wrote:
>> After copying the resulting binaries to my target; I tried loading the
>> kernel Image
>>
>> # kexec -l /Image
>> Modified cmdline: root=/dev/nfs
>> Unable to find /proc/device-tree//chosen/linux,stdout-path, printing
>> from purgatory is diabled
>> Cannot determine the file type of /Image
>>
>> It failed to load the kernel Image. Any pointers?
>
> My kexec-tools [1] only supports loading of arm64 elf files, so
> vmlinux, or a stripped version of it.  Image is a raw binary, and
> is not yet supported.
>
> Maybe something like this is what you need:
>
>  ./kexec -d --load /boot/vmlinux.strip --append="console=ttyAMA0 earlyprintk=pl011,0x1c090000 root=/dev/vda rw --verbose" --dtb=/boot/fdt.dtb
>  ./kexec -d -e
>

Hi ,

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;
Do you have any idea how to find out that value for my hardware?


> Also, my current master branch will only work reliably with PSCI
> boot.  Spin-table boot has a bug and will be unstable for the next
> few days.  Spin-table will re-boot, but only the primary cpu will
> come up.
>

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?


--Arun

[-- Attachment #2: error_log.txt --]
[-- Type: text/plain, Size: 11059 bytes --]

# kexec -l vmlinux.strip --dtb=dtb.dtb -d --command-line="console=ttyS0,115200"
random: nonblocking pool is initialized
kexec version: 14.07.10.11.38-g426996b
arch_process_options:83: command_line: console=ttyS0,115200
arch_process_options:85: initrd: (null)
arch_process_options:86: dtmachine_kexec_prepare:547:
b:  kexec image info:
     type:        0
dt    start:       4000080000
    head:        0
b.    nr_segments: 2
dt      segment[0]: 0000004000080000 - 000000400084d000, 7cd000h bytes, 1997 pages
kexec_is_dtb:136: magic: 10000014 : 14000010 : no

      segment[1]: 0000004000860000 - 0000004000862000, 2000h bytes, 2 pages
kekexec_is_dtb:136: magic: d00dfeed : edfe0dd0 : yes
rnkexec_is_dtb:136: magic: 10000014 : 14000010 : no
ekexec_is_dtb:136: magic: d00dfeed : edfe0dd0 : yes
l:kexec_boot_info_init:459: cpu_count: 8
 0x7f7d7kexec_cpu_info_init:422: cpu-0: 'spin-table', release_addr: 0x000000400000fff8, return_addr: 0x0000000000000000
29kexec_cpu_info_init:422: cpu-1: 'spin-table', release_addr: 0x000000400000fff8, return_addr: 0x0000000000000000
01kexec_cpu_info_init:422: cpu-2: 'spin-table', release_addr: 0x000000400000fff8, return_addr: 0x0000000000000000
0 kexec_cpu_info_init:422: cpu-3: 'spin-table', release_addr: 0x000000400000fff8, return_addr: 0x0000000000000000
kekexec_cpu_info_init:422: cpu-4: 'spin-table', release_addr: 0x000000400000fff8, return_addr: 0x0000000000000000
rnkexec_cpu_info_init:422: cpu-5: 'spin-table', release_addr: 0x000000400000fff8, return_addr: 0x0000000000000000
elkexec_cpu_info_init:422: cpu-6: 'spin-table', release_addr: 0x000000400000fff8, return_addr: 0x0000000000000000
_skexec_cpu_info_init:422: cpu-7: 'spin-table', release_addr: 0x000000400000fff8, return_addr: 0x0000000000000000
izkexec_boot_info_init:459: cpu_count: 8
e:kexec_cpu_info_init:422: cpu-0: 'spin-table', release_addr: 0x000000010000fff8, return_addr: 0x0000000000000000
 0kexec_cpu_info_init:422: cpu-1: 'spin-table', release_addr: 0x000000010000fff8, return_addr: 0x0000000000000000
x7kexec_cpu_info_init:422: cpu-2: 'spin-table', release_addr: 0x000000010000fff8, return_addr: 0x0000000000000000
adkexec_cpu_info_init:422: cpu-3: 'spin-table', release_addr: 0x000000010000fff8, return_addr: 0x0000000000000000
22kexec_cpu_info_init:422: cpu-4: 'spin-table', release_addr: 0x000000010000fff8, return_addr: 0x0000000000000000
kexec_cpu_info_init:422: cpu-5: 'spin-table', release_addr: 0x000000010000fff8, return_addr: 0x0000000000000000

Mkexec_cpu_info_init:422: cpu-6: 'spin-table', release_addr: 0x000000010000fff8, return_addr: 0x0000000000000000
odkexec_cpu_info_init:422: cpu-7: 'spin-table', release_addr: 0x000000010000fff8, return_addr: 0x0000000000000000
ified cmdline: root=/dev/nfs 
Unable to find /proc/device-tree//chosen/linux,stdout-path, printing from purgatory is diabled
get_memory_ranges_dt: node_1676 memory
get_memory_ranges_dt:  RAM: 0000004000000000 - 0000004400000000
get_memory_ranges_dt:  RAM: 0000000000000000 - 0000000000000000
get_memory_ranges_dt:  RAM: 0000000000000000 - 0000000000000000
get_memory_ranges_dt:  RAM: 0000000000000000 - 0000000000000000
get_memory_ranges_dt: Success
p_paddr: ffffffc000080000
p_vaddr: ffffffc000080000
p_filesz: 000000000079cc08
p_memsz: 00000000007cce28
p_offset: 0000000000010000
text_offset: 0000000000080000
page_offset: ffffffc000000000
memstart: 0000004000000000
p_vaddr: ffffffc000080000
virt_to_phys: ffffffc000080000 -> 0000004000080000
text_offset: 0000000000080000
page_offset: ffffffc000000000
memstart:    0000004000000000
entry:       0x4000080000
virt_to_phys: ffffffc000080000 -> 0000004000080000
add_segment_phys_virt: 0000007f7d739010 - 0000007f7ded5c18 (0079cc08) -> 0000004000080000 - 000000400084d000 (007cd000)
dtb:    base 4000860000, size 1c36h (7222)
add_segment_phys_virt: 000000002cc78510 - 000000002cc7a146 (00001c36) -> 0000004000860000 - 0000004000862000 (00002000)
kexec_load: entry = 0x4000080000 flags = 0xb70000
nr_segments = 2
segment[0].buf   = 0x7f7d739010
segment[0].bufsz = 0x79cc08
segment[0].mem   = 0x4000080000
segment[0].memsz = 0x7cd000
segment[1].buf   = 0x2cc78510
segment[1].bufsz = 0x1c36
segment[1].mem   = 0x4000860000
segment[1].memsz = 0x2000
#  
# 
# 
# kexec -e -d
kexekvm: exiting hardware virtualization
c veStarting new kernel
rssmp_spin_table_cpu_die:125: id: 1, holding count: 0
smp_spin_table_cpu_die:125: id: 7, holding count: 0
smp_spin_table_cpu_die:125: id: 6, holding count: 0
smp_spin_table_cpu_die:125: id: 4, holding count: 0
smp_spin_table_cpu_die:125: id: 3, holding count: 0
smp_spin_table_cpu_die:125: id: 2, holding count: 0
smp_spin_table_cpu_die:125: id: 5, holding count: 0
machine_kexec:612: smp_processor_id = 0
Bad mode in Synchronous Abort handler detected, code 0x86000005
machine_kexec:614:
CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.15.0-rc4+ #44
  kexec image info:
task: ffffffc3ef143340 ti: ffffffc3ef160000 task.ti: ffffffc3ef160000
    type:        0
    start:       4000080000
PC is at 0x4000489f80
    head:        43edaef002
LR is at 0xffffffc0000802e8
    nr_segments: 2
pc : [<0000004000489f80>] lr : [<ffffffc0000802e8>] pstate: 600001c5
      segment[0]: 0000004000080000 - 000000400084d000, 7cd000h bytes, 1997 pages
sp : ffffffc3ef163d90
x29: ffffffc3ef163d90 x28: 0000008000000000 
kexec_is_dtb:136: magic: 0 : 0 : no

      segment[1]: 0000004000860000 - 0000004000862000, 2000h bytes, 2 pages
x27: ffffffc3ef160000 x26: ffffffc000604000 
kexec_is_dtb:136: magic: 0 : 0 : no

machine_kexec:622: control_code_page:        ffffffbcedbfc6f8
x25: ffffffc000602000 
machine_kexec:624: reboot_code_buffer_phys:  00000043eda69000
x24: ffffffc000587000 
machine_kexec:626: reboot_code_buffer:       ffffffc3eda69000

machine_kexec:628: relocate_new_kernel:      ffffffc000093158
x23: ffffffc000c72000 
machine_kexec:630: relocate_new_kernel_size: b8h(184) bytes
x22: 00000000500f0000 
machine_kexec:633: kexec_dtb_addr:           0000004000860000

machine_kexec:635: kexec_kimage_head:        00000043edaef002
x21: 0000000000000000 
machine_kexec:637: kexec_kimage_start:       0000004000080000
x20: 0000000000000000 
machine_kexec:639: kexec_entry_dump:

  I 43edaef002 = 43edaef000 (ffffffc3edaef000)
x19: ffffffc00048a8b0 
  D 4000080001 = 4000080000 (ffffffc000080000)
x18: 0000007fd31cc6e0 
x17: 00000000004a6c60 x16: ffffffc00017a834 
  I 43ed4f4002 = 43ed4f4000 (ffffffc3ed4f4000)

x15: 0000000000000006 x14: 00000000000fdb04 
x13: 0000000000000054 x12: 0000004000489f80 
  I 43ed6f4002 = 43ed6f4000 (ffffffc3ed6f4000)

x11: 00000000000024fc x10: ffffffffffffffff 
x9 : 0000000000000033 x8 : ffffffc3fee8153f 
  I 43ed0f4002 = 43ed0f4000 (ffffffc3ed0f4000)

x7 : 0000000000000000 x6 : 00000000000f0000 
x5 : 00000000000f0000 
  D 4000860001 = 4000860000 (ffffffc000860000)
x4 : ffffffc000caa208 
  DONE 0000000004


  kexec_entry_dump: 0 pages
x3 : ffffffc000c72000 x2 : ffffffc0000805d8 
x1 : 0000000000000000 x0 : ffffffc000c72000 
dump_cpus: all:        0 1 2 3 4 5 6 7

Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP
dump_cpus: possible:   0 1 2 3 4 5 6 7
Modules linked in:
dump_cpus: present:    0 1 2 3 4 5 6 7
CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.15.0-rc4+ #44
dump_cpus: active:     0 1 2 3 4 5 6 7
task: ffffffc3ef143340 ti: ffffffc3ef160000 task.ti: ffffffc3ef160000
dump_cpus: online:     0
PC is at 0x4000489f80
LR is at 0xffffffc0000802e8
dump_cpus: not online: 1 2 3 4 5 6 7
pc : [<0000004000489f80>] lr : [<ffffffc0000802e8>] pstate: 600001c5
Bye!
sp : ffffffc3ef163d90
x29: ffffffc3ef163d90 x28: 0000008000000000 
x27: ffffffc3ef160000 x26: ffffffc000604000 
x25: ffffffc000602000 x24: ffffffc000587000 
x23: ffffffc000c72000 x22: 00000000500f0000 
x21: 0000000000000000 x20: 0000000000000000 
x19: ffffffc00048a8b0 x18: 0000007fd31cc6e0 
x17: 00000000004a6c60 x16: ffffffc00017a834 
x15: 0000000000000006 x14: 00000000000fdb04 
x13: 0000000000000054 x12: 0000004000489f80 
x11: 00000000000024fc x10: ffffffffffffffff 
x9 : 0000000000000033 x8 : ffffffc3fee8153f 
x7 : 0000000000000000 x6 : 00000000000f0000 
x5 : 00000000000f0000 x4 : ffffffc000caa208 
x3 : ffffffc000c72000 x2 : ffffffc0000805d8 
x1 : 0000000000000000 x0 : ffffffc000c72000 

Process swapper/7 (pid: 0, stack limit = 0xffffffc3ef160058)
Stack: (0xffffffc3ef163d90 to 0xffffffc3ef164000)
3d80:                                     ef163dc0 ffffffc3 0008ed2c ffffffc0
3da0: 00caa170 ffffffc0 00000007 00000000 00c5ea98 ffffffc0 0008ecb8 ffffffc0
3dc0: ef163e10 ffffffc3 000812d0 ffffffc0 0000200c ffffff80 ef163e40 ffffffc3
3de0: 00cc2700 ffffffc0 00002010 ffffff80 60000145 00000000 00ca871a ffffffc0
3e00: ef163e40 ffffffc3 00000003 00000000 ef163f60 ffffffc3 00083da4 ffffffc0
3e20: ef160000 ffffffc3 ef160000 ffffffc3 ef163f60 ffffffc3 000852b4 ffffffc0
3e40: 00000007 00000000 00597e48 ffffffc0 ef163ef0 ffffffc3 00000001 00000000
3e60: 0000004e 00000000 14000000 00000000 25c17d03 00000002 00000000 00000000
3e80: 00000018 00000000 ef163d70 ffffffc3 00000400 00000000 00000400 00000000
3ea0: 00000000 00000000 ffffffff ffffffff ffffffff ffffffff 981e8598 0000007f
3ec0: 0017a834 ffffffc0 004a6c60 00000000 d31cc6e0 0000007f ef160000 ffffffc3
3ee0: ef160000 ffffffc3 00caf500 ffffffc0 0048d000 ffffffc0 00587a68 ffffffc0
3f00: 00ca871a ffffffc0 0058d200 ffffffc0 00000001 00000000 ef160000 ffffffc3
3f20: 00000000 00000080 ef163f60 ffffffc3 000852b0 ffffffc0 ef163f60 ffffffc3
3f40: 000852b4 ffffffc0 60000145 00000000 ef160000 ffffffc3 ef160000 ffffffc3
3f60: ef163f70 ffffffc3 000e10a4 ffffffc0 ef163fd0 ffffffc3 0008e81c ffffffc0
3f80: 00000007 00000000 00000000 00000000 00caa1b0 ffffffc0 500f0000 00000000
3fa0: 00c72000 00000040 00000000 00000040 0007b000 00000040 0007d000 00000040
3fc0: 00080300 ffffffc0 0008e7fc ffffffc0 00000000 00000000 000802e8 00000040
3fe0: 00002000 00000000 00000000 00000000 08d0b004 05101514 a688cdaa 2620a80f
Call trace:
[<0000004000489f80>] 0x4000489f80
[<ffffffc00008ed28>] handle_IPI+0x1a8/0x1b0
[<ffffffc0000812cc>] gic_handle_irq+0x78/0x80
Exception stack(0xffffffc3ef163e20 to 0xffffffc3ef163f40)
3e20: ef160000 ffffffc3 ef160000 ffffffc3 ef163f60 ffffffc3 000852b4 ffffffc0
3e40: 00000007 00000000 00597e48 ffffffc0 ef163ef0 ffffffc3 00000001 00000000
3e60: 0000004e 00000000 14000000 00000000 25c17d03 00000002 00000000 00000000
3e80: 00000018 00000000 ef163d70 ffffffc3 00000400 00000000 00000400 00000000
3ea0: 00000000 00000000 ffffffff ffffffff ffffffff ffffffff 981e8598 0000007f
3ec0: 0017a834 ffffffc0 004a6c60 00000000 d31cc6e0 0000007f ef160000 ffffffc3
3ee0: ef160000 ffffffc3 00caf500 ffffffc0 0048d000 ffffffc0 00587a68 ffffffc0
3f00: 00ca871a ffffffc0 0058d200 ffffffc0 00000001 00000000 ef160000 ffffffc3
3f20: 00000000 00000080 ef163f60 ffffffc3 000852b0 ffffffc0 ef163f60 ffffffc3
[<ffffffc000083da0>] el1_irq+0x60/0xd0
[<ffffffc0000e10a0>] cpu_startup_entry+0x118/0x180
[<ffffffc00008e818>] secondary_start_kernel+0x10c/0x11c
Code: bad PC value
---[ end trace 7467eabc0e0787f2 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 1 seconds..Reboot failed -- System halted


[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: 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



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kexec on arm64

[Arun Chandran]

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@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
>
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kexec on arm64

[Geoff Levand]

Hi Arun,

On Wed, 2014-07-09 at 15:43 +0530, Arun Chandran wrote:
> and got this error
> 
> elf-arm64.o kexec/arch/arm64/kexec-elf-arm64.c
> kexec/arch/arm64/kexec-elf-arm64.c: In function ‘elf_arm64_probe’:
> kexec/arch/arm64/kexec-elf-arm64.c:32:24: error: ‘EM_AARCH64’
> undeclared (first use in this function)
>   if (ehdr.e_machine != EM_AARCH64) {
>                         ^
> kexec/arch/arm64/kexec-elf-arm64.c:32:24: note: each undeclared
> identifier is reported only once for each function it appears in
> make: *** [kexec/arch/arm64/kexec-elf-arm64.o] Error 1
> 
> Am I missing something here?

Your toolchain is old, or built incorrectly.  Try to upgrade
it.  You need headers that define EM_AARCH64.

As a work-around, maybe you can do something like:

  make CFLAGS=-DEM_AARCH64=183'

-Geoff




_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec