Question

我正在研究微型7010主板，我有manualy编译内核，u-boot，fsbl和.bit（vivado）。所有设置都可以启动电路板（不使用petalinux）。但我注意到内核不是解压缩内核... 与zImage和uImage。而我可以看到与petalinux图像的bootlogs。

INPUT：

1。 zImage env是

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

2。启动日志是=＆gt;

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。组成

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

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

任何帮助将不胜感激。

谢谢和问候， Pritam

Answer 1

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

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

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

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

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

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

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

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

来自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 ......它们是一样的...... ???

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

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

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

有趣的是，我无法在shell提示符下复制您的声明。 zImage 重命名为 zImage.gz 无法进行gunzip：

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压缩算法压缩Image文件，即更广泛的大小与时间权衡的选择。

哪种更好的压缩方法无论是在u-boot还是内核（zImage）。

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

Plz用实际例子解释我（如果有任何h / w要求）...... !!!

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

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

如果我被误解，请纠正我。

使用u-boot启动时，zImage不会发生解压缩

2 个答案: