Re: No compression technique of zImage/uImage detected - ARM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>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

Are there special kernel configuration options I have to enable/disable which influences the zImage header?

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




[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux