> 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