使用 u-boot 启动时，zImage 未进行解压缩

Question

我正在开发 microzed 7010 板，我手动编译了内核、u-boot、fsbl 和 .bit (vivado)。主板在所有设置下都能正常启动（不使用 petalinux）。但我注意到内核不是解压缩内核... 与 zImage 或 uImage。而我可以看到带有 petalinux 图像的引导日志。

输入：

1 . zImage 环境是

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

2 。启动日志是 =>

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 .在 u-boot 我已经给了 bootz 支持

4 。 uImage由

组成

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

是什么导致它不解压缩内核？ u-boot 是否压缩内核并启动？

任何帮助将不胜感激。

感谢和问候， 普里坦

Answer 1

Board 在所有设置下都能正常启动（不使用 petalinux）。但我注意到内核不是解压缩内核...使用 zImage 或 uImage。

某些内核可以静默执行此步骤。加载一个 zImage（或 uImage 中的 zImage），然后看到 Linux 内核版本行意味着内核已成功解压并正在执行

是什么导致它不解压缩内核？

您假设内核没有被解压缩是完全错误的。
您使用的 zImage 或 uImage 文件是压缩的内核映像。由于内核实际上正在执行（正如您发布的引导日志所证明的那样），内核必须静默解压缩并继续引导。
如果内核没有解压缩（如您所说），则内核无法成功启动（如您所报告）。

u-boot是在压缩内核并启动吗？

不，U-Boot 不涉及解压缩 zImage 文件。
zImage 是一个自解压的压缩图像文件。
根据内核的配置方式，zImage 文件的解压缩可以是静默的或冗长的。

我已经从 petalinux 下载中克隆了源代码。我从 petalinux 构建的映像中获得的引导日志显示 Uncompressing kernel .... 消息。 “正在启动内核...解压 Linux...完成，启动内核。在物理 CPU 0x0 Linux 版本 4.6.0-xilinx (pritam@pritam)（gcc 版本 5.2.1）上启动 Linux”所以我期待它显示“解压内核”消息

使用相同的源代码只是构建重复内核的必要条件之一。
您还需要使用相同的配置进行构建。
静默或详细解压缩由内核配置选择。

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

如果您希望进行详细解压缩，则需要选择 CONFIG_DEBUG_KERNEL、CONFIG_DEBUG_LL 和适当的串行端口。

---

ADDENDUM（回复评论）

哪一种是压缩内核的更好方法。 zImage 或 gzipping arch/arm/Image ......它们是一样的...... ???

您打算使用什么指标来衡量“更好”？
最后，结果是一样的：一个压缩的内核映像。
您必须保存多少这些图像文件？
与自提取相比，节省空间和加载时间（如果有）有多重要？

在 mkimage 中，如果我指定 -C "gzip"，我注意到在 ram 中加载图像时，u-boot 会解压缩 gzip 压缩的图像 ... !!!

正如我已经评论过的，这是 zImage 文件的错误标签，因此是错误的。 zImage 是自解压的，应标记为“未压缩”，以便 U-Boot 不会尝试执行解压缩。

有趣的是，我无法在 shell 提示符下复制您的声明。重命名为 zImage.gz 的 zImage 不能被枪压缩：

gzip: zImage.gz: not in gzip format.

更重要的是，我无法复制您声称获得的结果。

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

u-boot 是否包含外部解压器... ???

如果您费心阅读我之前提供的链接，答案将是显而易见的。
U-Boot 可以配置为具有 gzip、bzip2、lzma 和 lzo 压缩算法。
然而，Linux 内核支持使用 gzip、lzo、lzma、xz 和 lz4 压缩算法压缩图像文件，也就是说，在大小与时间之间进行权衡的选择范围更广。

在 u-boot 或内核 (zImage) 中哪种压缩方法更好。

再次，您将使用什么指标来衡量“更好”？
当然 Wolfgang Denk 有his opinion。

请用实际例子解释我（如果有任何硬件要求）...... !!!

什么例子？
我已经回答了您的问题，并解释了如何配置内核以获得预期的消息。

Answer 2

问题在于将压缩类型 "-C" 指定为无。

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

所以我尝试使用 vmlinux。并将其转换为 gzip

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

所以我注意到两个图像的大小。 第一个是vmlinux，另一个是zImage

所以如果我被误解了，请纠正我。