在使用u-boot启动时，zImage不会发生解压缩。
我正在微型7010板上工作，我已经手动编译了内核，u，fsbl和.bit (vivado)。板引导与所有设置良好(不使用petalinux)。但我注意到内核不是解压缩的内核..。zImage和uImage。而我可以看到引导文件和petalinux的图像。
投入：
1.zImage env是
zImage=tftpboot 0x3000000 zImage && tftpboot 0x2A00000 system.dtb && bootz 0x3000000 - 0x2A000002.引导日志是=>
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=18c5387d3.在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引导正在压缩内核并引导吗？
任何帮助都将不胜感激。
谢谢和问候，普利坦
回答 2
Stack Overflow用户
发布于 2017-10-30 07:07:51
板引导与所有设置良好(不使用petalinux)。但我注意到内核不是解压缩的内核..。zImage和uImage。
一些内核可以默默地执行这一步骤。加载一个zImage (或者在uImage中加载一个zImage )，然后查看Linux内核版本行，这意味着内核已经成功地被压缩并正在执行。
是什么原因导致它不解压缩内核？
您认为内核没有被解压缩的假设是完全错误的。
您正在使用的zImage或uImage文件是压缩的内核映像。因为内核实际上正在执行(正如您发布的引导日志所证明的那样)，内核必须已经悄无声息地解压缩并继续启动。
如果内核没有解压缩(正如您断言的那样)，那么内核就无法成功引导(正如您所报告的)。
U引导正在压缩内核并引导吗？
不，U没有参与解压缩zImage文件.
zImage是一个自解压缩的图像文件.
根据内核的配置方式，zImage文件的解压缩可以是静默的，也可以是冗长的。
我从petalinux下载中克隆了源代码。我从petalinux构建的图像中得到的引导日志显示了未压缩内核.消息。启动内核.解压缩Linux .完成，启动内核。在物理CPU 0x0 Linux版本4.6.0-xilinx上引导Linux (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和适当的串行端口。
增编(对评论的答复)
哪一种方法能更好地压缩内核。zImage或拉链拱/臂/图像.他们是一样的吗？
你打算用什么标准来衡量“更好”
最后，结果是相同的:一个压缩的内核映像。
这些图像文件中有多少要保存？
与自抽取相比，节省空间和负载时间(如果有的话)有多重要？
在of映像中，如果我指定了-C "gzip"，我注意到在以ram加载映像时，u引导解压缩压缩的图像.！
正如我已经评论过的，这是zImage文件的错误标记，因此是错误的。zImage是自解压缩的，应该被标记为“未压缩的”，这样U就不会尝试执行解压缩。
有趣的是，我不能在shell提示符下重复您的要求。将zImage改名为zImage.gz，不能对其进行压缩：
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引导是否包含外部解压器？
如果你费心阅读我之前提供的链接，答案将是显而易见的。
U可以配置为具有gzip、bzip2、lzma和lzo压缩算法。
但是，Linux内核支持使用gzip、lzo、lzma、xz和lz4压缩算法压缩图像文件，即更广泛地选择大小与时间的权衡。
哪一种更好的压缩方法，无论是在u引导还是内核(zImage)。
再说一遍，你打算用什么标准来衡量“更好”
当然，沃尔夫冈·登克( Wolfgang Denk )有他的意见。
请用实际例子解释我(如果有任何h/w要求).
什么的例子？
我已经回答了您的问题，并解释了如何配置您的内核以获得预期的消息。
Stack Overflow用户
发布于 2017-10-26 06:35:54
问题是将压缩类型"-C"指定为none。
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。
所以，如果我被误解了，请纠正我。
https://stackoverflow.com/questions/46930346
复制相似问题
腾讯云开发者
