No compression technique of zImage/uImage detected - ARM

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

 



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

Thanks!

>     Thanks,
>     Bhupesh


_______________________________________________
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