>02/08/2019, 11:39, "kexec on behalf of Maikel Coenen" ><[email protected] on behalf of [email protected]> >wrote:> >31/07/2019, 14:30, "Bhupesh Sharma" <[email protected]> wrote:> On >Mon, Jul 29, 2019 at 1:36 PM Maikel Coenen <[email protected]> wrote: > > > > > > > On 29/07/2019, 07:02, "Bhupesh Sharma" <[email protected]> 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 > > 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 Can someone explain what the slurp_decompress_file exactly does? _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
