On Wed, Mar 21, 2018 at 02:25:48PM +0100, Arthur LAMBERT wrote:

Le Tuesday 20 Mar 2018 ? 19:12:59 (+0000), Russell King - ARM Linux wrote :

quoted

They're all included there.  Please try running kexec in debug mode
when loading the kernel, and report the output.

No more dtb argument with device tree file path and debug enable now.

Kexec output :

# sh kx.sh
Try gzip decompression.
kernel: 0x768cf008 kernel_size: 0x64a480
MEMORY RANGES
0000000080000000-000000009fffffff (0)
zImage header: 0x016f2818 0x00000000 0x0064a480
zImage size 0x64a480, file size 0x64a480
zImage requires 0x0065b480 bytes
Reserved memory ranges
0000000088000000-000000008b1fffff (0)
Coredump memory ranges
0000000080000000-0000000087ffffff (0)
000000008b200000-000000009fffffff (0)
kernel symbol _stext vaddr =         80100000
phys offset = 0x80000000, page offset = 80000000
Using 32-bit ELF core format
get_crash_notes_per_cpu: crash_notes addr = 8bb3a600, size = 180
Elf header: p_type = 4, p_offset = 0x8bb3a600 p_paddr = 0x8bb3a600 p_vaddr = 0x0 p_filesz = 0xb4 p_memsz = 0xb4
vmcoreinfo header: p_type = 4, p_offset = 0x80fd2610 p_paddr = 0x80fd2610 p_vaddr = 0x0 p_filesz = 0x1024 p_memsz = 0x1024
Elf header: p_type = 1, p_offset = 0x80000000 p_paddr = 0x80000000 p_vaddr = 0x80000000 p_filesz = 0x8000000 p_memsz = 0x8000000
Elf header: p_type = 1, p_offset = 0x8b200000 p_paddr = 0x8b200000 p_vaddr = 0x8b200000 p_filesz = 0x14e00000 p_memsz = 0x14e00000
elfcorehdr: 0x8b100000
crashkernel: [0x88000000 - 0x8b1fffff] (50M)
memory range: [0x80000000 - 0x87ffffff] (128M)
memory range: [0x8b200000 - 0x9fffffff] (334M)
kernel command line: "console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw  maxcpus=1 reset_devices init=/sbin/init elfcorehdr=0x8b100000 mem=50176K"
Kernel: address=0x88008000 size=0x01fc8680
DT    : address=0x89fd2000 size=0x0000904c
kexec_load: entry = 0x88008000 flags = 0x280001
nr_segments = 3
segment[0].buf   = 0x768cf008
segment[0].bufsz = 0x64a484
segment[0].mem   = 0x88008000
segment[0].memsz = 0x64b000
segment[1].buf   = 0x996578
segment[1].bufsz = 0x904c
segment[1].mem   = 0x89fd2000
segment[1].memsz = 0xa000
segment[2].buf   = 0x996100
segment[2].bufsz = 0x400
segment[2].mem   = 0x8b100000
segment[2].memsz = 0x1000
kx.sh: kexec: success, dump kernel loaded.

From the debug output of kexec, I think the problem has been located

with these two lines:

kernel symbol _stext vaddr =         80100000
segment[0].mem   = 0x88008000

It is standard with Linux kernels that they are loaded with a 32kB
offset to allow room for data including the page tables below the
kernel image.  kexec-tools knows about this offset.  It seems,
however, that the kernel tree you're using omits this offset and
builds the kernel to execute at a 1MB offset.

This difference is sufficient that the kernel will crash as a result.

All the offsets established to date in arch/arm/Makefile include
this 32kB offset, except, it seems, for your case - which is
presumably a vendor supplied (NXP?) or modified kernel tree.

That's the root of the problem, and I'm afraid I can't help you any
further - please complain to the vendor about this.

I suspect that they wanted to load the kernel at 1MB to avoid data
in the low 1MB of RAM, but have forgotten that both the decompressor
and the kernel itself will scribble over the 16 to 32k of memory
_below_ where it's loaded.

One way to fix this is to change the initialiser for extra_size in
kexec-tools/kexec/arch/arm/kexec-zImage-arm.c to reflect this offset,
but that will be at the expense of having to increase the crashdump
memory to allow for this offset.  It also makes kexec incompatible
with other kernels in the same way as stock kexec is incompatible
with your kernel.

The other solution is to include the 32k offset into the 1MB offset
in arch/arm/Makefile as per all the other textofs settings therein.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up