On Tue, Aug 13, 2019 at 7:01 PM Maikel Coenen <maikel.coenen@xxxxxxxxx> wrote: > > >02/08/2019, 11:39, "kexec on behalf of Maikel Coenen" <kexec-bounces@xxxxxxxxxxxxxxxxxxx on behalf of maikel.coenen@xxxxxxxxx> wrote:> >31/07/2019, 14:30, "Bhupesh Sharma" <bhsharma@xxxxxxxxxx> wrote:> On Mon, Jul 29, 2019 at 1:36 PM Maikel Coenen <maikel.coenen@xxxxxxxxx> wrote: > > > > > > > > > On 29/07/2019, 07:02, "Bhupesh Sharma" <bhsharma@xxxxxxxxxx> wrote:> > > > > > > > > > Hi Maikel, > > > > > > > > > > I have a couple of queries (so that I can help you better). Please see > > > > > them in-line: > > > > > > > > > > On 07/24/2019 02:43 PM, Maikel Coenen wrote: > > > > > > Hi, > > > > > > > > > > > > I have met an issue during loading a new kernel with Kexec on an ARMv5 SoC. The kernel is a 4.19 with Gzip compression but during loading Kexec does not recognize the compression. > > > > > > > > > > > > If I load the new kernel and dtb with: > > > > > > > > > > > > kexec -l /boot/zImage -d --dtb=/boot/u-boot.dtb > > > > > > > > > > Can you please show the output of the following command: > > > > > $ file /boot/zImage > > > > > > > > zImage: Linux kernel ARM boot executable zImage (little-endian) > > > > > > > > I also performed a binwalk with following output: > > > > DECIMAL HEXADECIMAL DESCRIPTION > > > > -------------------------------------------------------------------------------- > > > > 0 0x0 Linux kernel ARM boot executable zImage (little-endian) > > > > 16424 0x4028 gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date) > > > > > > > > > Also can you please make sure that the zImage has the right gzip header > > > > > : magic header 0x1f, 0x8b (\037 \213) > > > > > > > > As you can see in the binwalk output, is the magic header found at 0x4028. This because of the zImage header. > > > > When I check the zImage manually, it is indeed at that location. > > > > > > > > > > The output is: > > > > > > > > > > > > Try gzip decompression. > > > > > > Try LZMA decompression. > > > > > > lzma_decompress_file: read on /boot/zImage of 65536 bytes failed > > > > > > kernel: 0xb6a68008 kernel_size: 0x494d30 > > > > > > MEMORY RANGES > > > > > > 0000000000000000-000000000fffffff (0) > > > > > > zImage header: 0x016f2818 0x00000000 0x00494d30 > > > > > > zImage size 0x494d30, file size 0x494d30 > > > > > > kexec_load: entry = 0x8000 flags = 0x280000 > > > > > > nr_segments = 2 > > > > > > segment[0].buf = 0xb6a68008 > > > > > > segment[0].bufsz = 0x494d30 > > > > > > segment[0].mem = 0x8000 > > > > > > segment[0].memsz = 0x495000 > > > > > > segment[1].buf = 0x1fcf060 > > > > > > segment[1].bufsz = 0x245b > > > > > > segment[1].mem = 0x16f2000 > > > > > > segment[1].memsz = 0x3000 > > > > > > > > > > > > Looking at the debug, the function gzdirect returns “1” which indicates the kernel compression is not of gzip but I definitely use gzip. > > > > > > I also tested it with LZMA compression and uImage instead of zImage but all with the same outcome. > > > > > > > > > > > > To be complete, I use Kexec-tools 2.0.19 and zlib 1.2.11. > > > > > > > > > > > > Did I implement something wrong or how can I debug this further? > > > > > > > > > > I don't have a armv5 hardware and my attempt to setup a qemu + buildroot > > > > > setup for ARMv5 (926t) lead to a failure to boot the latest upstream kernel. > > > > > > > > > > I will try to fix up the setup and come back with more details. > > > > > In the meanwhile if you can share the above, I can have further look at > > > > > the same. > > > > > > Well, I can't reproduce the issue you reported at my end. > > > Here is my environment: > > > > > > $ qemu-system-arm --version > > > QEMU emulator version 2.11.2(qemu-2.11.2-5.fc28) > > > Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers > > > > > > # uname -rn > > > buildroot 4.19.16 > > > > > > # kexec -v > > > kexec-tools 2.0.18 > > > > > > # kexec -l zImage -d --dtb=versatile-pb.dtb > > > Try gzip decompression. > > > kernel: 0xb6c46008 kernel_size: 0x29cb48 > > > MEMORY RANGES > > > 0000000000000000-0000000007ffffff (0) > > > zImage header: 0x016f2818 0x00000000 0x0029cb48 > > > zImage size 0x29cb48, file size 0x29cb48 > > > zImage requires 0x002adb48 bytes > > > offset 0x00003934 tag 0x5a534c4b size 8 > > > Decompressed kernel sizes: > > > text+data 0x0050fe30 bss 0x00031de4 total 0x00541c14 > > > Resulting kernel space: 0x007bd978 > > > Kernel: address=0x00008000 size=0x007bd978 > > > DT : address=0x007c7000 size=0x00002278 > > > kexec_load: entry = 0x8000 flags = 0x280000 > > > nr_segments = 2 > > > segment[0].buf = 0xb6c46008 > > > segment[0].bufsz = 0x29cb4c > > > segment[0].mem = 0x8000 > > > segment[0].memsz = 0x29d000 > > > segment[1].buf = 0x47ca8 > > > segment[1].bufsz = 0x2278 > > > segment[1].mem = 0x7c7000 > > > segment[1].memsz = 0x3000 > > > > > > As you can see from the logs above the zImage format is correctly > > > recognized and decompressed. > > > > > > When I run 'kexec -e', I can launch the new kernel just fine. > > > > > > I don't see any new patches in 'kexec/arch/arm' folder between > > > kexec-tools 2.0.18 (at my end) and kexec-tools 2.0.19 (which you use), > > > so I am of the view that the issue is of the zImage image generation > > > probably. > > > > > > Since, 'kexec/arch/arm/kexec-zImage-arm.c' also supports uncompressed > > > kernel Image, you can try loading the Image file directly and see if > > > that makes a difference (you can find it here in the kernel tree: > > > arch/arm/boot/Image): > > > > > > # kexec -l Image -d --dtb=versatile-pb.dtb > > > Try gzip decompression. > > > kernel: 0xb5f3a008 kernel_size: 0xfc4f20 > > > MEMORY RANGES > > > 0000000000000000-0000000007ffffff (0) > > > zImage header: 0xeb00005a 0xeb000044 0xeb000009 > > > zImage requires 0x00fd5f20 bytes > > > Kernel: address=0x00008000 size=0x04f2dba0 > > > DT : address=0x04f37000 size=0x00002278 > > > kexec_load: entry = 0x8000 flags = 0x280000 > > > nr_segments = 2 > > > segment[0].buf = 0xb5f3a008 > > > segment[0].bufsz = 0xfc4f24 > > > segment[0].mem = 0x8000 > > > segment[0].memsz = 0xfc5000 > > > segment[1].buf = 0x47ca8 > > > segment[1].bufsz = 0x2278 > > > segment[1].mem = 0x4f37000 > > > segment[1].memsz = 0x3000 > > > > > > Thanks, > > > Bhupesh > > > > I previously build my kernel within the Yocto environment but now did it manually (Torvalds git 4.19) with the same result. Also checked my kernel configuration without positive results. > > I can successfully boot this kernel from u-boot. > > > > Also the uncompressed Image file gives the following result: > > > > # kexec -l /boot/Image -d --dtb=/boot/u-boot.dtb > > Try gzip decompression. > > Try LZMA decompression. > > lzma_decompress_file: read on /boot/Image of -1093035632 bytes failed > > kernel: 0xb6658008 kernel_size: 0x700f8c > > MEMORY RANGES > > 0000000000000000-000000000fffffff (0) > > zImage header: 0xeb00005a 0xeb000044 0xeb000009 > > zImage requires 0x00711f8c bytes > > Kernel: address=0x00008000 size=0x02359dbc > > DT : address=0x02363000 size=0x0000245b > > kexec_load: entry = 0x8000 flags = 0x280000 > > nr_segments = 2 > > segment[0].buf = 0xb6658008 > > segment[0].bufsz = 0x700f90 > > segment[0].mem = 0x8000 > > segment[0].memsz = 0x701000 > > segment[1].buf = 0x515058 > > segment[1].bufsz = 0x245b > > segment[1].mem = 0x2363000 > > segment[1].memsz = 0x3000 The output generated is correct. Do you still see an issue with 'kexec -e' invocation after this? Can you paste the output of the same? > > Are there special kernel configuration options I have to enable/disable which influences the zImage header? > > Tried to reproduce my problems with buildroot, as you did. Normally, buildroot does not enable lzma libraries and therefore these outputs are not shown. When I enable it, the output is similar as shown above. > > # uname -a > # buildroot 4.19.60-cip7 > > # kexec -v > kexec-tools 2.0.18 > > Within Qemu the system reboots successfully into the new kernel, even if the same output is generated: > > root@qemuarm:~# kexec -e > [12139.308548] kexec_core: Starting new kernel > [12139.313709] Bye! > vpb_sic_write: Bad register offset 0x2c > [ 0.000000] Booting Linux on physical CPU 0x0 > [ 0.000000] Linux version 4.18.33-yocto-second (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 PREEMPT Tue Aug 13 06:50:57 UTC 2019 Well, you can easily enable gzip compression and test the resulting zImage on qemu + buildroot via the following documentation (for versatile express board): https://github.com/maximeh/buildroot/tree/master/board/qemu/arm-versatile I run the model via the following qemu command-line: $ qemu-system-arm -M versatilepb -kernel zImage -dtb versatile-pb.dtb -drive file=rootfs.ext2,if=scsi,format=raw -append "root=/dev/sda console=ttyAMA0,115200" -serial stdio -net nic,model=rtl8139 -net user > Can someone explain what the slurp_decompress_file exactly does? It basically takes a compressed kernel image (zImage) and decompresses the same (via lzma or zlib decompression libraries) and returns the same to the caller to be passed later via the .probe() and .load() function pointers. BTW, since you are not even able to load and kexec into an uncompressed kernel Image, I don't suspect issues with the zlib library version or slurp_decompress_file() implementation. Also do you see the same issue with the latest kexec-tools - kexec-tools 2.0.20? Thanks, Bhupesh _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
