无法从 FIT 映像启动
Cannot boot from FIT image
我正在使用 Xilinx Zynq-7000 SoC，我正在尝试从 "legacy"（uImage + DTB + initramfs 映像）过渡到 "modern"（FIT 映像）启动流动。这是我用来启动开发板的当前命令序列（省略输出）：
setenv bootargs "console=ttyPS0,115200 root=/dev/ram rw ramdisk_size=0x1600000 earlyprintk init=/sbin/init"
tftpboot 0x2000000 devicetree.dtb
tftpboot 0x2080000 uImage
tftpboot 0x4000000 initramfs.img
bootm 0x2080000 0x4000000 0x2000000
我正在处理现有项目，据我所知，TFTP 加载地址（0x2080000 等）是任意的。我 认为 它们不重要，除了它们被映射到 RAM 并且不与加载地址重叠这一事实。如果我在这里错了，请纠正我。
执行 bootm 命令生成以下输出：
Zynq> bootm 0x2080000 0x4000000 0x2000000
## Booting kernel from Legacy Image at 02080000 ...
Image Name: Linux-4.0.0-00011-gcfd1f62
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3297728 Bytes = 3.1 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 04000000 ...
Image Name: Ramdisk Image
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 22569621 Bytes = 21.5 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 02000000
Booting using the fdt blob at 0x2000000
Loading Kernel Image ... OK
Loading Ramdisk to 1ea79000, end 1ffff295 ... OK
Loading Device Tree to 1ea73000, end 1ea78ba1 ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
[Omitted]
换句话说，bootm 正确引导内核。
现在，我不想加载每个图像并将它们的地址传递到 bootm，而是想创建一个包含所有三个图像的 FIT 图像。如有必要，我可以提供 .its 源，但我指定了所有三个图像（uImage、DTB 和 initramfs），这是 mkimage 输出：
FIT description: Test FIT Image
Created: Mon Dec 19 13:13:06 2016
Image 0 (kernel@1)
Description: Linux Kernel
Created: Mon Dec 19 13:13:06 2016
Type: Kernel Image
Compression: uncompressed
Data Size: 3297792 Bytes = 3220.50 kB = 3.15 MB
Architecture: ARM
OS: Linux
Load Address: 0x00008000
Entry Point: 0x00008000
Image 1 (fdt@1)
Description: Device Tree Blob
Created: Mon Dec 19 13:13:06 2016
Type: Flat Device Tree
Compression: uncompressed
Data Size: 11170 Bytes = 10.91 kB = 0.01 MB
Architecture: ARM
Image 2 (ramdisk@1)
Description: initramfs
Created: Mon Dec 19 13:13:06 2016
Type: RAMDisk Image
Compression: gzip compressed
Data Size: 22569685 Bytes = 22040.71 kB = 21.52 MB
Architecture: ARM
OS: Linux
Load Address: 0x00000000
Entry Point: 0x00000000
Default Configuration: 'conf@1'
Configuration 0 (conf@1)
Description: Boot Linux kernel with FDT blob
Kernel: kernel@1
Init Ramdisk: ramdisk@1
FDT: fdt@1
加载地址和入口点与我之前引导程序的 bootm 输出一致。这就是我尝试使用新 .itb 文件启动的方式（省略输出）：
setenv bootargs "console=ttyPS0,115200 root=/dev/ram rw ramdisk_size=0x1600000 earlyprintk init=/sbin/init"
tftpboot 0x2000000 image.itb
bootm 0x2000000
这是 bootm 的输出：
Zynq> bootm 0x2000000
## Loading kernel from FIT Image at 02000000 ...
Using 'conf@1' configuration
Verifying Hash Integrity ... OK
Trying 'kernel@1' kernel subimage
Description: Linux Kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x020000c4
Data Size: 3297792 Bytes = 3.1 MiB
Architecture: ARM
OS: Linux
Load Address: 0x00008000
Entry Point: 0x00008000
Verifying Hash Integrity ... OK
## Loading ramdisk from FIT Image at 02000000 ...
Using 'conf@1' configuration
Trying 'ramdisk@1' ramdisk subimage
Description: initramfs
Type: RAMDisk Image
Compression: gzip compressed
Data Start: 0x02327f88
Data Size: 22569685 Bytes = 21.5 MiB
Architecture: ARM
OS: Linux
Load Address: 0x00000000
Entry Point: 0x00000000
Verifying Hash Integrity ... OK
## Loading fdt from FIT Image at 02000000 ...
Using 'conf@1' configuration
Trying 'fdt@1' fdt subimage
Description: Device Tree Blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x02325370
Data Size: 11170 Bytes = 10.9 KiB
Architecture: ARM
Verifying Hash Integrity ... OK
Booting using the fdt blob at 0x2325370
Loading Kernel Image ... OK
Loading Ramdisk to 1ea79000, end 1ffff2d5 ... OK
Loading Device Tree to 1ea73000, end 1ea78ba1 ... OK
Starting kernel ...
undefined instruction
pc : [<0000800c>] lr : [<3ff2b834>]
reloc pc : [<c40dd00c>] lr : [<04000834>]
sp : 3f30acb0 ip : 0000000c fp : 3ff2b8c0
r10: 00000000 r9 : 3f30aee0 r8 : 020000c4
r7 : 00000000 r6 : 00008000 r5 : 3ff9c868 r4 : 00000000
r3 : 00002ba2 r2 : 1ea73000 r1 : 00000000 r0 : 3f30afb0
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
这是我第一次使用 FIT 图像，但在崩溃之前的一切对我来说都很好。加载点和入口点地址对齐，直到 Starting kernel... 的输出或多或少与我的旧引导对齐。
我是否误解了如何 create/use FIT 图片？
我很确定，对于 FIT 映像，U-Boot 正在将 uImage 加载到加载地址 0x8000。我在 U-Boot 中使用 md 进行了测试：
加载适合图像之前
Zynq> md 0x8000
00008000: dfdc3ffc dd5ffbfe ff7fbabe ffffd7fe .?...._.........
00008010: 777fccfb fbbfeefb dde9f8cf ffffeee7 ...w............
00008020: ffcefebc f76ffffb ffadf2ed f5f776ff ......o......v..
00008030: eb31fdd9 fff28fff df5fb77f ffdbeeeb ..1......._.....
00008040: dedfef7f ebeffebe fddfbbbf f7f7d4ff ................
00008050: ddcfaed7 e7fe33ee ff8eb89f fedd3df7 .....3.......=..
00008060: ffdffd7f 75bff5ad f2dff52b ffb7f03f .......u+...?...
00008070: f7fffef3 ff9fbffb bf7fabfe ff96db5f ............_...
00008080: f777feff f6b7bf5b fb27dffb e5beb98f ..w.[.....'.....
00008090: ffbdf8f7 f3fefce7 e8fefdf6 ffc639ef .............9..
000080a0: f6ef8bfe f6bffcfd ffffd4cf defffdff ................
000080b0: edbf46bf ffdfbdbf 7edff6b7 fde5afbf .F.........~....
000080c0: b7cdf9bf fffefdbb ffbdfa7f eeffffb7 ................
000080d0: c5affdef ffcffbaf e73f6fef fdeff37f .........o?.....
000080e0: f3ffeffb 76af599b ffff7dff 6dafbd8f .....Y.v.}.....m
000080f0: efffaafd fdfff7fe effffbff bebf6cbe .............l..
加载适合图像后
00008000: 56190527 3328f51d dc265858 c0513200 '..V..(3XX&..2Q.
00008010: 00800000 00800000 368dbc5f 00020205 ........_..6....
00008020: 756e694c 2e342d78 2d302e30 31303030 Linux-4.0.0-0001
00008030: 63672d31 66316466 00003236 00000000 1-gcfd1f62......
00008040: e1a00000 e1a00000 e1a00000 e1a00000 ................
00008050: e1a00000 e1a00000 e1a00000 e1a00000 ................
00008060: ea000003 016f2818 00000000 003251c0 .....(o......Q2.
00008070: 04030201 e10f9000 eb000bf8 e1a07001 .............p..
00008080: e1a08002 e10f2000 e3120003 1a000001 ..... ..........
00008090: e3a00017 ef123456 e10f0000 e220001a ....V4........ .
000080a0: e310001f e3c0001f e38000d3 1a000004 ................
000080b0: e3800c01 e28fe00c e16ff000 e12ef30e ..........o.....
000080c0: e160006e e121f000 e16ff009 00000000 n.`...!...o.....
000080d0: 00000000 00000000 00000000 00000000 ................
000080e0: e1a0400f e204433e e2844902 e1a0000f .@..>C...I......
000080f0: e1500004 359f01ac 3080000f 31540000 ..P....5...0..T1
U-Boot 报告内核映像数据从我加载 FIT 映像的位置偏移 0xc4 处开始。如果我在该地址 (0x20000c4) 读取数据，则数据与尝试启动后 0x8000 处的数据相同。所以U-Boot肯定是在加载内核。
这是创建 uImage 时我的内核构建的输出：
/bin/sh ./scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0x8000 -e 0x8000 -n 'Linux-4.0.0-00011-gcfd1f62' -d arch/arm/boot/zImage arch/arm/boot/uImage
Image Name: Linux-4.0.0-00011-gcfd1f62
Created: Mon Dec 19 13:32:30 2016
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3297728 Bytes = 3220.44 kB = 3.14 MB
Load Address: 00008000
Entry Point: 00008000
同样，这里的一切似乎都符合犹太洁食标准。
有什么想法吗？
查看您的 FIT 源可能会证实这一点，但看起来您正在将 uImage 打包到 FIT 中，同时声称它是常规内核映像。应该位于 0x8000 的内核文本在您的转储中位于 0x8040，并且前面的 64 字节看起来非常像 uImage header.
对于 FIT 内核，要么使用纯 arch/arm/boot/Image 或 self-extracting arch/arm/boot/zImage，要么使用各种压缩 arch/arm/boot/Image.* 和 "compression" 之一酌情设置。否则都会有点"Yo dawg, I heard you like U-boot image formats..."
我正在使用 Xilinx Zynq-7000 SoC，我正在尝试从 "legacy"（uImage + DTB + initramfs 映像）过渡到 "modern"（FIT 映像）启动流动。这是我用来启动开发板的当前命令序列（省略输出）：
setenv bootargs "console=ttyPS0,115200 root=/dev/ram rw ramdisk_size=0x1600000 earlyprintk init=/sbin/init"
tftpboot 0x2000000 devicetree.dtb
tftpboot 0x2080000 uImage
tftpboot 0x4000000 initramfs.img
bootm 0x2080000 0x4000000 0x2000000
我正在处理现有项目，据我所知，TFTP 加载地址（0x2080000 等）是任意的。我 认为 它们不重要，除了它们被映射到 RAM 并且不与加载地址重叠这一事实。如果我在这里错了，请纠正我。
执行 bootm 命令生成以下输出：
Zynq> bootm 0x2080000 0x4000000 0x2000000
## Booting kernel from Legacy Image at 02080000 ...
Image Name: Linux-4.0.0-00011-gcfd1f62
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3297728 Bytes = 3.1 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 04000000 ...
Image Name: Ramdisk Image
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 22569621 Bytes = 21.5 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 02000000
Booting using the fdt blob at 0x2000000
Loading Kernel Image ... OK
Loading Ramdisk to 1ea79000, end 1ffff295 ... OK
Loading Device Tree to 1ea73000, end 1ea78ba1 ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
[Omitted]
换句话说，bootm 正确引导内核。
现在，我不想加载每个图像并将它们的地址传递到 bootm，而是想创建一个包含所有三个图像的 FIT 图像。如有必要，我可以提供 .its 源，但我指定了所有三个图像（uImage、DTB 和 initramfs），这是 mkimage 输出：
FIT description: Test FIT Image
Created: Mon Dec 19 13:13:06 2016
Image 0 (kernel@1)
Description: Linux Kernel
Created: Mon Dec 19 13:13:06 2016
Type: Kernel Image
Compression: uncompressed
Data Size: 3297792 Bytes = 3220.50 kB = 3.15 MB
Architecture: ARM
OS: Linux
Load Address: 0x00008000
Entry Point: 0x00008000
Image 1 (fdt@1)
Description: Device Tree Blob
Created: Mon Dec 19 13:13:06 2016
Type: Flat Device Tree
Compression: uncompressed
Data Size: 11170 Bytes = 10.91 kB = 0.01 MB
Architecture: ARM
Image 2 (ramdisk@1)
Description: initramfs
Created: Mon Dec 19 13:13:06 2016
Type: RAMDisk Image
Compression: gzip compressed
Data Size: 22569685 Bytes = 22040.71 kB = 21.52 MB
Architecture: ARM
OS: Linux
Load Address: 0x00000000
Entry Point: 0x00000000
Default Configuration: 'conf@1'
Configuration 0 (conf@1)
Description: Boot Linux kernel with FDT blob
Kernel: kernel@1
Init Ramdisk: ramdisk@1
FDT: fdt@1
加载地址和入口点与我之前引导程序的 bootm 输出一致。这就是我尝试使用新 .itb 文件启动的方式（省略输出）：
setenv bootargs "console=ttyPS0,115200 root=/dev/ram rw ramdisk_size=0x1600000 earlyprintk init=/sbin/init"
tftpboot 0x2000000 image.itb
bootm 0x2000000
这是 bootm 的输出：
Zynq> bootm 0x2000000
## Loading kernel from FIT Image at 02000000 ...
Using 'conf@1' configuration
Verifying Hash Integrity ... OK
Trying 'kernel@1' kernel subimage
Description: Linux Kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x020000c4
Data Size: 3297792 Bytes = 3.1 MiB
Architecture: ARM
OS: Linux
Load Address: 0x00008000
Entry Point: 0x00008000
Verifying Hash Integrity ... OK
## Loading ramdisk from FIT Image at 02000000 ...
Using 'conf@1' configuration
Trying 'ramdisk@1' ramdisk subimage
Description: initramfs
Type: RAMDisk Image
Compression: gzip compressed
Data Start: 0x02327f88
Data Size: 22569685 Bytes = 21.5 MiB
Architecture: ARM
OS: Linux
Load Address: 0x00000000
Entry Point: 0x00000000
Verifying Hash Integrity ... OK
## Loading fdt from FIT Image at 02000000 ...
Using 'conf@1' configuration
Trying 'fdt@1' fdt subimage
Description: Device Tree Blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x02325370
Data Size: 11170 Bytes = 10.9 KiB
Architecture: ARM
Verifying Hash Integrity ... OK
Booting using the fdt blob at 0x2325370
Loading Kernel Image ... OK
Loading Ramdisk to 1ea79000, end 1ffff2d5 ... OK
Loading Device Tree to 1ea73000, end 1ea78ba1 ... OK
Starting kernel ...
undefined instruction
pc : [<0000800c>] lr : [<3ff2b834>]
reloc pc : [<c40dd00c>] lr : [<04000834>]
sp : 3f30acb0 ip : 0000000c fp : 3ff2b8c0
r10: 00000000 r9 : 3f30aee0 r8 : 020000c4
r7 : 00000000 r6 : 00008000 r5 : 3ff9c868 r4 : 00000000
r3 : 00002ba2 r2 : 1ea73000 r1 : 00000000 r0 : 3f30afb0
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
这是我第一次使用 FIT 图像，但在崩溃之前的一切对我来说都很好。加载点和入口点地址对齐，直到 Starting kernel... 的输出或多或少与我的旧引导对齐。
我是否误解了如何 create/use FIT 图片？
我很确定，对于 FIT 映像，U-Boot 正在将 uImage 加载到加载地址 0x8000。我在 U-Boot 中使用 md 进行了测试：
加载适合图像之前
Zynq> md 0x8000
00008000: dfdc3ffc dd5ffbfe ff7fbabe ffffd7fe .?...._.........
00008010: 777fccfb fbbfeefb dde9f8cf ffffeee7 ...w............
00008020: ffcefebc f76ffffb ffadf2ed f5f776ff ......o......v..
00008030: eb31fdd9 fff28fff df5fb77f ffdbeeeb ..1......._.....
00008040: dedfef7f ebeffebe fddfbbbf f7f7d4ff ................
00008050: ddcfaed7 e7fe33ee ff8eb89f fedd3df7 .....3.......=..
00008060: ffdffd7f 75bff5ad f2dff52b ffb7f03f .......u+...?...
00008070: f7fffef3 ff9fbffb bf7fabfe ff96db5f ............_...
00008080: f777feff f6b7bf5b fb27dffb e5beb98f ..w.[.....'.....
00008090: ffbdf8f7 f3fefce7 e8fefdf6 ffc639ef .............9..
000080a0: f6ef8bfe f6bffcfd ffffd4cf defffdff ................
000080b0: edbf46bf ffdfbdbf 7edff6b7 fde5afbf .F.........~....
000080c0: b7cdf9bf fffefdbb ffbdfa7f eeffffb7 ................
000080d0: c5affdef ffcffbaf e73f6fef fdeff37f .........o?.....
000080e0: f3ffeffb 76af599b ffff7dff 6dafbd8f .....Y.v.}.....m
000080f0: efffaafd fdfff7fe effffbff bebf6cbe .............l..
加载适合图像后
00008000: 56190527 3328f51d dc265858 c0513200 '..V..(3XX&..2Q.
00008010: 00800000 00800000 368dbc5f 00020205 ........_..6....
00008020: 756e694c 2e342d78 2d302e30 31303030 Linux-4.0.0-0001
00008030: 63672d31 66316466 00003236 00000000 1-gcfd1f62......
00008040: e1a00000 e1a00000 e1a00000 e1a00000 ................
00008050: e1a00000 e1a00000 e1a00000 e1a00000 ................
00008060: ea000003 016f2818 00000000 003251c0 .....(o......Q2.
00008070: 04030201 e10f9000 eb000bf8 e1a07001 .............p..
00008080: e1a08002 e10f2000 e3120003 1a000001 ..... ..........
00008090: e3a00017 ef123456 e10f0000 e220001a ....V4........ .
000080a0: e310001f e3c0001f e38000d3 1a000004 ................
000080b0: e3800c01 e28fe00c e16ff000 e12ef30e ..........o.....
000080c0: e160006e e121f000 e16ff009 00000000 n.`...!...o.....
000080d0: 00000000 00000000 00000000 00000000 ................
000080e0: e1a0400f e204433e e2844902 e1a0000f .@..>C...I......
000080f0: e1500004 359f01ac 3080000f 31540000 ..P....5...0..T1
U-Boot 报告内核映像数据从我加载 FIT 映像的位置偏移 0xc4 处开始。如果我在该地址 (0x20000c4) 读取数据，则数据与尝试启动后 0x8000 处的数据相同。所以U-Boot肯定是在加载内核。
这是创建 uImage 时我的内核构建的输出：
/bin/sh ./scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0x8000 -e 0x8000 -n 'Linux-4.0.0-00011-gcfd1f62' -d arch/arm/boot/zImage arch/arm/boot/uImage
Image Name: Linux-4.0.0-00011-gcfd1f62
Created: Mon Dec 19 13:32:30 2016
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3297728 Bytes = 3220.44 kB = 3.14 MB
Load Address: 00008000
Entry Point: 00008000
同样，这里的一切似乎都符合犹太洁食标准。
有什么想法吗？
查看您的 FIT 源可能会证实这一点，但看起来您正在将 uImage 打包到 FIT 中，同时声称它是常规内核映像。应该位于 0x8000 的内核文本在您的转储中位于 0x8040，并且前面的 64 字节看起来非常像 uImage header.
对于 FIT 内核，要么使用纯 arch/arm/boot/Image 或 self-extracting arch/arm/boot/zImage，要么使用各种压缩 arch/arm/boot/Image.* 和 "compression" 之一酌情设置。否则都会有点"Yo dawg, I heard you like U-boot image formats..."