Uncompressing is not happening with zImage while b

问题:

I am working on microzed 7010 board, I have manualy compiled kernel, u-boot, fsbl, and .bit (vivado). Board is booting well with all setup (without using petalinux). But i have noticed that kernel is not Uncompressing kernel... with zImage nor uImage. whereas i can see bootlogs with that of petalinux's images.

INPUT :

1 . zImage env is

zImage=tftpboot 0x3000000 zImage && tftpboot 0x2A00000 system.dtb && bootz 0x3000000 - 0x2A00000

2 . Boot log is =>

Zynq> run zImage
[2017-10-25 15:57:11
ethernet@e000b000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
[2017-10-25 15:57:15
Zynq> run zImage 
[2017-10-25 15:57:22
Using ethernet@e000b000 device
TFTP from server 172.16.9.187; our IP address is 172.16.9.25
Filename 'zImage'.
Load address: 0x3000000
    Loading:#####################################################################################################################################################################################################################################

3.9 MiB/s
    done
Bytes transferred = 3913840 (3bb870 hex)
    Using ethernet@e000b000 device
    TFTP from server 172.16.9.187; our IP address is 172.16.9.25
    Filename 'system.dtb'.
    Load address: 0x2a00000
    Loading: #
    3.3 MiB/s
    done
Bytes transferred = 13644 (354c hex)
    Kernel image @ 0x3000000 [ 0x000000 - 0x3bb870 ]
## Flattened Device Tree blob at 02a00000
    Booting using the fdt blob at 0x2a00000
    Loading Device Tree to 1fff9000, end 1ffff54b ... OK

    Starting kernel ...

    Booting Linux on physical CPU 0x0
    Linux version 4.6.0-xilinx-00003-g2762bc9 (pritam@pritam) (gcc version 5.2.1 20151005 (Linaro GCC 5.2-2015.11-2) ) #3 SMP PREEMPT Wed Oct 25 10:28:387
    [2017-10-25 15:57:24
    CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d

3 . In u-boot I have given bootz support

4 . uImage is formed by

mkimage -A arm -O linux -T kernel -C none -a 0x10000000 -e 0x10000000 -n "Linux kernel" -d arch/arm/boot/zImage uImage                                                             

What causing it not to uncompress kernel ? Is u-boot compressing the kernel and booting ?

Any help will be appreciated.

Thanks and regards, Pritam

回答1:

Board is booting well with all setup (without using petalinux). But i have noticed that kernel is not Uncompressing kernel... with zImage nor uImage.

Some kernels can perform this step silently. The fact that you load a zImage (or a zImage in a uImage), and then see the Linux kernel version line means that the kernel has been uncompressed successfully and is executing

What causing it not to uncompress kernel ?

Your presumption that the kernel is not being uncompressed is simply wrong.
The zImage or uImage files that you are using are compressed kernel images. Since the kernel is actually executing (as evidenced by the boot log that you posted), the kernel must have silently uncompressed and proceeded to boot.
If the kernel did not uncompress (as you assert), then the kernel could not boot successfully (as you reported).

Is u-boot compressing the kernel and booting ?

No, U-Boot is not involved in uncompressing a zImage file.
A zImage is a self-extracting compressed Image file.
Depending on how the kernel was configured, the uncompression of the zImage file can be silent or verbose.

I have cloned the source codes from petalinux downloads. The boot logs, I got from images built by petalinux, shows Uncompressing kernel .... message. " Starting kernel ... Uncompressing Linux... done, booting the kernel. Booting Linux on physical CPU 0x0 Linux version 4.6.0-xilinx (pritam@pritam) (gcc version 5.2.1" So i am expecting it to show "uncompressing kernel " message

Using the same source code is only one requisite for building a duplicate kernel.
You also need to build with the same configuration.
The silent or verbose uncompression is selected by kernel configuration.

From arch/arm/Kconfig.debug:

menu "Kernel hacking"
...      
config DEBUG_LL
    bool "Kernel low-level debugging functions (read help!)"
    depends on DEBUG_KERNEL
    help
      Say Y here to include definitions of printascii, printch, printhex
      in the kernel.  This is helpful if you are debugging code that
      executes before the console is initialized.

      Note that selecting this option will limit the kernel to a single
      UART definition, as specified below. Attempting to boot the kernel
      image on a different platform *will not work*, so this option should
      not be enabled for kernels that are intended to be portable. 
    ...
    prompt "Kernel low-level debugging port"

    ...  


    config DEBUG_ZYNQ_UART0
        bool "Kernel low-level debugging on Xilinx Zynq using UART0"
        depends on ARCH_ZYNQ
        help
          Say Y here if you want the debug print routines to direct
          their output to UART0 on the Zynq platform.

    config DEBUG_ZYNQ_UART1
        bool "Kernel low-level debugging on Xilinx Zynq using UART1"
        depends on ARCH_ZYNQ
        help
          Say Y here if you want the debug print routines to direct
          their output to UART1 on the Zynq platform.

If you expect a verbose uncompression, then you need to select CONFIG_DEBUG_KERNEL, CONFIG_DEBUG_LL, and an appropriate serial port.

---

ADDENDUM (response to comment)

Which one is better way to compress the kernel. zImage or gzipping arch/arm/Image ... are they same ... ???

What metric are you going to use to measure "better"?
In the end, the result is the same: a compressed kernel Image.
How many of these image files to you have to save?
How crucial is saving space and load times (if any) versus self-extraction?

In mkimage if I specified -C "gzip", I noticed that at time of loading image in ram, u-boot uncompresses the gzipped image ... !!!

As I already commented, that is a mislabeling of a zImage file, and therefore wrong. The zImage is self-extracting, and should be labeled as "uncompressed" so that U-Boot does not try to perform uncompression.

Interestingly I cannot duplicate your claim at the shell prompt. A zImage renamed to zImage.gz cannot be gunzip'd:

gzip: zImage.gz: not in gzip format.

More importantly, I cannot replicate the results that you claim you got.

=> bootm 20080000 - 22000000
## Booting kernel from Legacy Image at 20080000 ...
   Image Name:   Linux kernel
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    5774280 Bytes = 5.5 MiB
   Load Address: 20008000
   Entry Point:  20008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 22000000
   Booting using the fdt blob at 0x22000000
   Uncompressing Kernel Image ... Error: Bad gzipped data
gzip compressed: uncompress error -1
Must RESET board to recover
resetting ...

Does u-boot contains external decompresser ... ???

If you had bothered to read the link I had provided previously, the answer would be obvious.
U-Boot can be configured to have gzip, bzip2, lzma, and lzo compression algorithms.
However the Linux kernel supports compressing the Image file using gzip, lzo, lzma, xz, and lz4 compression algorithms, that is, a wider selection of size versus time tradeoffs.

Which one better compression method whether in u-boot or kernel (zImage).

Again, what metric are you going to use to measure "better"?
Of course Wolfgang Denk has his opinion.

Plz explain me with actual example (If any h/w requirement) ... !!!

Example of what?
I've already answered your question, and explained how you can configure your kernel to get the expected message.

回答2:

The issue was with specifying the compression type "-C" as none.

mkimage -A arm -O linux -T kernel **-C none** -a 0x10000000 -e 0x10000000 -n "Linux kernel" -d arch/arm/boot/zImage uImage

So I tried with vmlinux. and converted it to gzip

mkimage -A arm -O linux -T kernel **-C gzip** -a 0x10008000 -e 0x10008000 -n 'Test' -d vmlinux.bin.gz  uImage.

So I have noticed size of both images . first one is of vmlinux and another of zImage

So please correct me if i am misunderstood .