No compression technique of zImage/uImage detected - ARM

No compression technique of zImage/uImage detected - ARM

[Maikel Coenen]

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
 
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?
 
Kind regards,
 
Maikel Coenen

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

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

[Bhupesh Sharma]

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

Also can you please make sure that the zImage has the right gzip header 
: magic header  0x1f, 0x8b (\037 \213)


> 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,
Bhupesh

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

No compression technique of zImage/uImage detected - ARM

[Maikel Coenen]

> On 29/07/2019, 07:02, "Bhupesh Sharma" <bhsharma@redhat.com> 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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[Bhupesh Sharma]

On Mon, Jul 29, 2019 at 1:36 PM Maikel Coenen <maikel.coenen@nedap.com> wrote:
>
> > On 29/07/2019, 07:02, "Bhupesh Sharma" <bhsharma@redhat.com> 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

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

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

[Maikel Coenen]

>31/07/2019, 14:30, "Bhupesh Sharma" <bhsharma@redhat.com> wrote:> On Mon, Jul 29, 2019 at 1:36 PM Maikel Coenen <maikel.coenen@nedap.com> wrote:
> >
> > > On 29/07/2019, 07:02, "Bhupesh Sharma" <bhsharma@redhat.com> 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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

No compression technique of zImage/uImage detected - ARM

[Maikel Coenen]

>02/08/2019, 11:39, "kexec on behalf of Maikel Coenen" <kexec-bounces@lists.infradead.org on behalf of maikel.coenen@nedap.com> wrote:> >31/07/2019, 14:30, "Bhupesh Sharma" <bhsharma@redhat.com> wrote:> On Mon, Jul 29, 2019 at 1:36 PM Maikel Coenen <maikel.coenen@nedap.com> wrote:
> > >
> > > > On 29/07/2019, 07:02, "Bhupesh Sharma" <bhsharma@redhat.com> 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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[Bhupesh Sharma]

On Tue, Aug 13, 2019 at 7:01 PM Maikel Coenen <maikel.coenen@nedap.com> wrote:
>
> >02/08/2019, 11:39, "kexec on behalf of Maikel Coenen" <kexec-bounces@lists.infradead.org on behalf of maikel.coenen@nedap.com> wrote:> >31/07/2019, 14:30, "Bhupesh Sharma" <bhsharma@redhat.com> wrote:> On Mon, Jul 29, 2019 at 1:36 PM Maikel Coenen <maikel.coenen@nedap.com> wrote:
> > > >
> > > > > On 29/07/2019, 07:02, "Bhupesh Sharma" <bhsharma@redhat.com> 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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[Maikel Coenen]

> 4/08/2019, 22:33, "Bhupesh Sharma" <bhsharma@redhat.com> wrote:> On Tue, Aug 13, 2019 at 7:01 PM Maikel Coenen <maikel.coenen@nedap.com> wrote:
> >
> > >02/08/2019, 11:39, "kexec on behalf of Maikel Coenen" <kexec-bounces@lists.infradead.org on behalf of maikel.coenen@nedap.com> wrote:> >31/07/2019, 14:30, "Bhupesh Sharma" <bhsharma@redhat.com> wrote:> On Mon, Jul 29, 2019 at 1:36 PM Maikel Coenen <maikel.coenen@nedap.com> wrote:
> > > > >
> > > > > > On 29/07/2019, 07:02, "Bhupesh Sharma" <bhsharma@redhat.com> 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

Ok, did the exact same thing but still it is trying to decompress with LZMA after GZIP.

# kexec -l /boot/zImage --dtb=/boot/versatile-pb.dtb -d
Try gzip decompression.
Try LZMA decompression.
lzma_decompress_file: read on /boot/zImage of 65536 bytes failed
kernel: 0xb6abe008 kernel_size: 0x287220
MEMORY RANGES
0000000000000000-0000000007ffffff (0)
zImage header: 0x016f2818 0x00000000 0x00287220
zImage size 0x287220, file size 0x287220
zImage requires 0x00298220 bytes
  offset 0x00003934 tag 0x5a534c4b size 8
Decompressed kernel sizes:
 text+data 0x004e6768 bss 0x00031c84 total 0x005183ec
Resulting kernel space: 0x0077e988
Kernel: address=0x00008000 size=0x0077e988
DT    : address=0x00788000 size=0x00002278
kexec_load: entry = 0x8000 flags = 0x280000
nr_segments = 2
segment[0].buf   = 0xb6abe008
segment[0].bufsz = 0x287224
segment[0].mem   = 0x8000
segment[0].memsz = 0x288000
segment[1].buf   = 0x51060
segment[1].bufsz = 0x2278
segment[1].mem   = 0x788000
segment[1].memsz = 0x3000

Probably it does not matter that much because it is working in Qemu afterall. 

# kexec -e
random: crng init done
sd 0:0:0:0: [sda] Synchronizing SCSI cache
kexec_core: Starting new kernel
Bye!
vpb_sic_write: Bad register offset 0x2c
Booting Linux on physical CPU 0x0

Unfortunately, on my Marvell Feroceon 88FR131 it is stuck after "Bye!". How can I debug this behaviour?
Already tried GDB but that one stops with stepping after initiating the reboot. Also JTAG is an option but
probably very complicated because of using Kexec and also two kernels.

> > 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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

No compression technique of zImage/uImage detected - ARM

[Maikel Coenen]

> 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
>  
> 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?
>  
> Kind regards,
>  
> Maikel Coenen

Did some more testing and as far as I can see, it tries to decompress the kernel before removing the decompressing stub and header of the zImage/uImage. Therefore, it is not able to find the magic numbers of a gzip file at the beginning of the file. 

Function gz_look, called from gzdirect at zlib_decompress_file, checks the first byte of the stream to be equal to 31 and the second equal to 139. Because it did not strip the header, the first and second byte are 39 and 5. These are the first bytes of the uImage.

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