了解嵌入式板上经过验证的 Uboot
Understanding Verified Uboot on Embedded Board
我已经搜索了验证 u-boot 的演示文稿和文档，但有几个问题。我会尝试引导任何用户了解我所在的位置，因为我怀疑我不是唯一一个在理解验证 u-boot 过程时遇到一些轻微困难的人。
我有一个已编译的 zImage，它有一个工作的外部 DTB，无需验证即可使用。它启动并工作（让我们称之为正常-board.dts）
其次，我使用以下配置条目编译了 u-boot：
CONFIG_ARM=y
CONFIG_ARCH_AT91=y
CONFIG_TARGET_AT91SAM9260EK=y
CONFIG_SYS_EXTRA_OPTIONS="AT91SAM9G20,SYS_USE_DATAFLASH_CS1"
CONFIG_SYS_PROMPT="#> "
# CONFIG_CMD_BDI is not set
CONFIG_CMD_IMI=y
# CONFIG_CMD_IMLS is not set
# CONFIG_CMD_LOADS is not set
# CONFIG_CMD_FPGA is not set
# CONFIG_CMD_SOURCE is not set
CONFIG_CMD_SETEXPR=y
CONFIG_DEFAULT_DEVICE_TREE="myboard"
CONFIG_CMD_MMC=y
CONFIG_CMD_FAT=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_RSA=y
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_OF_CONTROL=y
我的板有一个分区方案类似于：
... boot strap, uboot and env
0xD00084000 (zImage)
0xD0020AA00 (normal-board.dtb)
The rootfs is on NAND (external to this chip)
可以使用以下命令以标准配置启动设备：
cp.b 0xD0084000 0x22000000 0x186A00;cp.b 0xD020AA00 0x28000000 0x61A8;bootm 0x22000000 - 0x28000000
此时，我已经重新编译了 u-boot，但是由于有几个元素，命名有点混乱。
- FIT Control DTS（我假设这是u-boot使用的，需要在自己的分区）
- FIT DTB（与非 FIT 或多或少相同的 DTB（正常-board.dtb），但其中某处具有 FIT 魔法）
- FIT 内核映像（我假设这里的 zImage 也添加了一些魔法？）
看到有uboot控制FIT FDT，请问这个需要单独分区吗？ FIT DTB 是否与工作内核 DTB 相同（只需刷写这个而不是非 FIT 的）？？？
接下来，根据我开始从各种文档和幻灯片中提取的这个脚本，我们可以看到 u-boot.{dts,dtb} 是控制 FDT，而 ITS 文件是合适的（我假设它与 normal-board.dts 相同，但添加了一个 FIT 节点。
例如。你-boot.dts
/dts-v1/;
/ {
model = "Keys";
compatible = "myboard";
signature {
dev_key {
required = "conf";
algo = "sha1,rsa2048";
key-name-hint = "dev_key";
};
};
};
现在 myboard 的示例 DTS 带有适合部分：
/dts-v1/;
/ {
description = "Linux kernel2";
#address-cells = <1>;
images {
kernel@1 {
description = "Linux kernel";
data = /incbin/("../linux/arch/arm/boot/zImage");
arch = "arm";
os = "linux";
type = "kernel_noload";
compression = "none";
load = <0x80080000>;
entry = <0x80080000>;
kernel-version = <1>;
hash@1 {
algo = "sha1";
};
};
};
configurations {
default = "conf@1";
conf@1 {
description = "Boot Linux kernel";
kernel = "kernel@1";
signature@1 {
algo = "sha1, rsa2048 ";
key-name-hint = "dev_key";
sign-images = "kernel";
};
};
};
};
但是，fitImage 到底是什么（见下面的脚本 - 这是来自示例）？是zImage吗？我找不到任何描述它的第一次提及的文档 - 它是什么，它来自哪里等......或者它是由 ITS 内部的参考生成的 incbin 的输出？
#!/bin/bash
key_dir=/tmp/keys
key_name=dev_key
FIT_IMG="fitImage"
rm -rf ${key_dir}
mkdir ${key_dir}
MKIMG="/home/dev/lede/staging_dir/host/bin/mkimage"
DTC="/usr/bin/dtc"
#Generate a private signing key (RSA2048):
openssl genrsa -F4 -out \
"${key_dir}"/"${key_name}".key 2048
# Generate a public key:
openssl req -batch -new -x509 \
-key "${key_dir}"/"${key_name}".key \
-out "${key_dir}"/"${key_name}".crt
# Control FDT (u-boot.dts) - hits uboot to have keys etc...
CTRL_FDT="u-boot.dts"
# FIT image ITS - describes the node
FIT_ITS="fit-image.its"
#Assemble control FDT for U-Boot with space for public key:
$DTC -p 0x1000 $CTRL_FDT -O dtb -o u-boot.dtb
# Generate fitImage with space for signature:
$MKIMG -D "-I dts -O dtb -p 2000" \
-f f$FIT_ITS $FIT_IMG
# Sign fitImage and add public key into u-boot.dtb:
$MKIMG -D "-I dts -O dtb -p 2000" -F \
-k "${key dir}" -K u-boot.dtb -r $FIT_IMG
# Signing subsequent fitImage:
$MKIMG -D "-I dts -O dtb -p 2000" \
-k "${key dir}" -f $FIT_ITS -r $FIT_IMG
Iminfo 让我走到这一步：
#> iminfo
## Checking Image at 20000000 ...
FIT image found
FIT description: Configuration to load a Basic Kernel
Image 0 (linux_kernel@1)
Description: Linux zImage
Type: Kernel Image
Compression: uncompressed
Data Start: 0x200000dc
Data Size: 1465544 Bytes = 1.4 MiB
Architecture: ARM
OS: Linux
Load Address: 0x20000000
Entry Point: 0x20008000
Hash node: 'hash@1'
Hash algo: sha256
Hash value: bf1d62a9ac777310746c443f2500cf197967f1e7c9cb56ff5c33206670e12d8f
Hash len: 32
Image 1 (fdt@1)
Description: FDT blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x20165ea4
Data Size: 21681 Bytes = 21.2 KiB
Architecture: ARM
Hash node: 'hash@1'
Hash algo: sha256
Hash value: c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
Hash len: 32
Default Configuration: 'config@1'
Configuration 0 (config@1)
Description: Plain Linux
Kernel: linux_kernel@1
FDT: fdt@1
## Checking hash(es) for FIT Image at 20000000 ...
Hash(es) for Image 0 (linux_kernel@1): sha256+
Hash(es) for Image 1 (fdt@1): sha256+
zImage 已准备好（这可能是错误的方式）
mkimage -A arm -O linux -C none -T kernel -a 0x22000000 -e 0x22008000 -n linux-4.4.36 \
-d $(KDIR)/zImage $(BIN_DIR)/$(IMG_PREFIX)-zImage-nDTB
甚至按照以下思路（我似乎明白了，我该如何处理地址 - 是问题的重新分配部分吗？例如 fdt_high 变量？）
#> bootm 0x23000000
## Current stack ends at 0x23f119b8 * kernel: cmdline image address = 0x23000000
## Loading kernel from FIT Image at 23000000 ...
No configuration specified, trying default...
Found default configuration: 'config@1'
Using 'config@1' configuration
Trying 'linux_kernel@1' kernel subimage
Description: Linux zImage
Type: Kernel Image
Compression: uncompressed
Data Start: 0x230000dc
Data Size: 1465544 Bytes = 1.4 MiB
Architecture: ARM
OS: Linux
Load Address: 0x23000000
Entry Point: 0x23000000
Hash node: 'hash@1'
Hash algo: sha256
Hash value: bb397db1ec90ec8526c6d215c9ded2a1357a258c2145f97fda9898e810e847d7
Hash len: 32
Verifying Hash Integrity ... sha256+ OK
kernel data at 0x230000dc, len = 0x00165cc8 (1465544)
* ramdisk: using config 'config@1' from image at 0x23000000
* ramdisk: no 'ramdisk' in config
* fdt: using config 'config@1' from image at 0x23000000
## Checking for 'FDT'/'FDT Image' at 23000000
## Loading fdt from FIT Image at 23000000 ...
Using 'config@1' configuration
Trying 'fdt@1' fdt subimage
Description: FDT blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x23165ea4
Data Size: 21681 Bytes = 21.2 KiB
Architecture: ARM
Hash node: 'hash@1'
Hash algo: sha256
Hash value: c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
Hash len: 32
Verifying Hash Integrity ... sha256+ OK
Can't get 'load' property from FIT 0x23000000, node: offset 1465916, name fdt@1 (FDT_ERR_NOTFOUND)
Booting using the fdt blob at 0x23165ea4
of_flat_tree at 0x23165ea4 size 0x000054b1
Initial value for argc=3
Final value for argc=3
Loading Kernel Image ... OK
CACHE: Misaligned operation at range [23000000, 23165cc8]
kernel loaded at 0x23000000, end = 0x23165cc8
images.os.start = 0x23000000, images.os.end = 0x2316c911
images.os.load = 0x23000000, load_end = 0x23165cc8
ERROR: new format image overwritten - must RESET the board to recover
所以，上面的问题有很多，我会试着回答一些应该有助于澄清问题的事情：
- U-Boot 二进制文件需要包含公钥。因此，在这种情况下，您列出的 "myboard" 设备树就是需要结束的地方。它在二进制文件中，而不是闪存中的一个单独分区。
- 接下来是 FIT 图像是一个容器，可以说有不同的打开方式。 fitImage 包含 zImage 和 normal-board.dtb 以及逻辑，因此您可以说这些片段中的每一个都需要由特定的 public 密钥签名。所以在这种情况下，不是 zImage 的闪存分区和 normal-board.dtb 的另一个闪存分区，而是 fitImage 所在的单个分区。它是将 "its" 文件提供给 mkimage 的输出。这类似于 "uImage" 是如何将 "zImage" 提供给 mkimage 的输出。
经过大量的工时学习、阅读和尝试 - 我创建了一篇完整的博客文章，内容涉及经过验证的 uboot 如何工作，以及 DTB（两种形式）在构建最终图像时如何结合在一起。
然而，要注意的关键事情确实是汤姆所说的，这里还有一些（在引用我的文章之后）：
- DTB有两种（kernel & uboot DTBS）
- 有一个名为 ITS 的文件 - 它描述了要构建的 FIT 映像
- 您将需要一个异步密钥对
- 您需要一个支持验证的 mkimage 版本 uboot/DTBs
- 您的引导加载程序需要支持已验证的 uboot 已启用
- Uboot 和 Linux 内核需要了解 DTB
- 即使您签署了图像，public 密钥的副本和其他加密信息也将需要在 final 引导加载程序
中
这是一个有趣的过程:)
我已经搜索了验证 u-boot 的演示文稿和文档，但有几个问题。我会尝试引导任何用户了解我所在的位置，因为我怀疑我不是唯一一个在理解验证 u-boot 过程时遇到一些轻微困难的人。
我有一个已编译的 zImage，它有一个工作的外部 DTB，无需验证即可使用。它启动并工作（让我们称之为正常-board.dts）
其次，我使用以下配置条目编译了 u-boot：
CONFIG_ARM=y
CONFIG_ARCH_AT91=y
CONFIG_TARGET_AT91SAM9260EK=y
CONFIG_SYS_EXTRA_OPTIONS="AT91SAM9G20,SYS_USE_DATAFLASH_CS1"
CONFIG_SYS_PROMPT="#> "
# CONFIG_CMD_BDI is not set
CONFIG_CMD_IMI=y
# CONFIG_CMD_IMLS is not set
# CONFIG_CMD_LOADS is not set
# CONFIG_CMD_FPGA is not set
# CONFIG_CMD_SOURCE is not set
CONFIG_CMD_SETEXPR=y
CONFIG_DEFAULT_DEVICE_TREE="myboard"
CONFIG_CMD_MMC=y
CONFIG_CMD_FAT=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_RSA=y
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_OF_CONTROL=y
我的板有一个分区方案类似于：
... boot strap, uboot and env
0xD00084000 (zImage)
0xD0020AA00 (normal-board.dtb)
The rootfs is on NAND (external to this chip)
可以使用以下命令以标准配置启动设备：
cp.b 0xD0084000 0x22000000 0x186A00;cp.b 0xD020AA00 0x28000000 0x61A8;bootm 0x22000000 - 0x28000000
此时，我已经重新编译了 u-boot，但是由于有几个元素，命名有点混乱。
- FIT Control DTS（我假设这是u-boot使用的，需要在自己的分区）
- FIT DTB（与非 FIT 或多或少相同的 DTB（正常-board.dtb），但其中某处具有 FIT 魔法）
- FIT 内核映像（我假设这里的 zImage 也添加了一些魔法？）
看到有uboot控制FIT FDT，请问这个需要单独分区吗？ FIT DTB 是否与工作内核 DTB 相同（只需刷写这个而不是非 FIT 的）？？？
接下来，根据我开始从各种文档和幻灯片中提取的这个脚本，我们可以看到 u-boot.{dts,dtb} 是控制 FDT，而 ITS 文件是合适的（我假设它与 normal-board.dts 相同，但添加了一个 FIT 节点。
例如。你-boot.dts
/dts-v1/;
/ {
model = "Keys";
compatible = "myboard";
signature {
dev_key {
required = "conf";
algo = "sha1,rsa2048";
key-name-hint = "dev_key";
};
};
};
现在 myboard 的示例 DTS 带有适合部分：
/dts-v1/;
/ {
description = "Linux kernel2";
#address-cells = <1>;
images {
kernel@1 {
description = "Linux kernel";
data = /incbin/("../linux/arch/arm/boot/zImage");
arch = "arm";
os = "linux";
type = "kernel_noload";
compression = "none";
load = <0x80080000>;
entry = <0x80080000>;
kernel-version = <1>;
hash@1 {
algo = "sha1";
};
};
};
configurations {
default = "conf@1";
conf@1 {
description = "Boot Linux kernel";
kernel = "kernel@1";
signature@1 {
algo = "sha1, rsa2048 ";
key-name-hint = "dev_key";
sign-images = "kernel";
};
};
};
};
但是，fitImage 到底是什么（见下面的脚本 - 这是来自示例）？是zImage吗？我找不到任何描述它的第一次提及的文档 - 它是什么，它来自哪里等......或者它是由 ITS 内部的参考生成的 incbin 的输出？
#!/bin/bash
key_dir=/tmp/keys
key_name=dev_key
FIT_IMG="fitImage"
rm -rf ${key_dir}
mkdir ${key_dir}
MKIMG="/home/dev/lede/staging_dir/host/bin/mkimage"
DTC="/usr/bin/dtc"
#Generate a private signing key (RSA2048):
openssl genrsa -F4 -out \
"${key_dir}"/"${key_name}".key 2048
# Generate a public key:
openssl req -batch -new -x509 \
-key "${key_dir}"/"${key_name}".key \
-out "${key_dir}"/"${key_name}".crt
# Control FDT (u-boot.dts) - hits uboot to have keys etc...
CTRL_FDT="u-boot.dts"
# FIT image ITS - describes the node
FIT_ITS="fit-image.its"
#Assemble control FDT for U-Boot with space for public key:
$DTC -p 0x1000 $CTRL_FDT -O dtb -o u-boot.dtb
# Generate fitImage with space for signature:
$MKIMG -D "-I dts -O dtb -p 2000" \
-f f$FIT_ITS $FIT_IMG
# Sign fitImage and add public key into u-boot.dtb:
$MKIMG -D "-I dts -O dtb -p 2000" -F \
-k "${key dir}" -K u-boot.dtb -r $FIT_IMG
# Signing subsequent fitImage:
$MKIMG -D "-I dts -O dtb -p 2000" \
-k "${key dir}" -f $FIT_ITS -r $FIT_IMG
Iminfo 让我走到这一步：
#> iminfo
## Checking Image at 20000000 ...
FIT image found
FIT description: Configuration to load a Basic Kernel
Image 0 (linux_kernel@1)
Description: Linux zImage
Type: Kernel Image
Compression: uncompressed
Data Start: 0x200000dc
Data Size: 1465544 Bytes = 1.4 MiB
Architecture: ARM
OS: Linux
Load Address: 0x20000000
Entry Point: 0x20008000
Hash node: 'hash@1'
Hash algo: sha256
Hash value: bf1d62a9ac777310746c443f2500cf197967f1e7c9cb56ff5c33206670e12d8f
Hash len: 32
Image 1 (fdt@1)
Description: FDT blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x20165ea4
Data Size: 21681 Bytes = 21.2 KiB
Architecture: ARM
Hash node: 'hash@1'
Hash algo: sha256
Hash value: c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
Hash len: 32
Default Configuration: 'config@1'
Configuration 0 (config@1)
Description: Plain Linux
Kernel: linux_kernel@1
FDT: fdt@1
## Checking hash(es) for FIT Image at 20000000 ...
Hash(es) for Image 0 (linux_kernel@1): sha256+
Hash(es) for Image 1 (fdt@1): sha256+
zImage 已准备好（这可能是错误的方式）
mkimage -A arm -O linux -C none -T kernel -a 0x22000000 -e 0x22008000 -n linux-4.4.36 \
-d $(KDIR)/zImage $(BIN_DIR)/$(IMG_PREFIX)-zImage-nDTB
甚至按照以下思路（我似乎明白了，我该如何处理地址 - 是问题的重新分配部分吗？例如 fdt_high 变量？）
#> bootm 0x23000000
## Current stack ends at 0x23f119b8 * kernel: cmdline image address = 0x23000000
## Loading kernel from FIT Image at 23000000 ...
No configuration specified, trying default...
Found default configuration: 'config@1'
Using 'config@1' configuration
Trying 'linux_kernel@1' kernel subimage
Description: Linux zImage
Type: Kernel Image
Compression: uncompressed
Data Start: 0x230000dc
Data Size: 1465544 Bytes = 1.4 MiB
Architecture: ARM
OS: Linux
Load Address: 0x23000000
Entry Point: 0x23000000
Hash node: 'hash@1'
Hash algo: sha256
Hash value: bb397db1ec90ec8526c6d215c9ded2a1357a258c2145f97fda9898e810e847d7
Hash len: 32
Verifying Hash Integrity ... sha256+ OK
kernel data at 0x230000dc, len = 0x00165cc8 (1465544)
* ramdisk: using config 'config@1' from image at 0x23000000
* ramdisk: no 'ramdisk' in config
* fdt: using config 'config@1' from image at 0x23000000
## Checking for 'FDT'/'FDT Image' at 23000000
## Loading fdt from FIT Image at 23000000 ...
Using 'config@1' configuration
Trying 'fdt@1' fdt subimage
Description: FDT blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x23165ea4
Data Size: 21681 Bytes = 21.2 KiB
Architecture: ARM
Hash node: 'hash@1'
Hash algo: sha256
Hash value: c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
Hash len: 32
Verifying Hash Integrity ... sha256+ OK
Can't get 'load' property from FIT 0x23000000, node: offset 1465916, name fdt@1 (FDT_ERR_NOTFOUND)
Booting using the fdt blob at 0x23165ea4
of_flat_tree at 0x23165ea4 size 0x000054b1
Initial value for argc=3
Final value for argc=3
Loading Kernel Image ... OK
CACHE: Misaligned operation at range [23000000, 23165cc8]
kernel loaded at 0x23000000, end = 0x23165cc8
images.os.start = 0x23000000, images.os.end = 0x2316c911
images.os.load = 0x23000000, load_end = 0x23165cc8
ERROR: new format image overwritten - must RESET the board to recover
所以，上面的问题有很多，我会试着回答一些应该有助于澄清问题的事情：
- U-Boot 二进制文件需要包含公钥。因此，在这种情况下，您列出的 "myboard" 设备树就是需要结束的地方。它在二进制文件中，而不是闪存中的一个单独分区。
- 接下来是 FIT 图像是一个容器，可以说有不同的打开方式。 fitImage 包含 zImage 和 normal-board.dtb 以及逻辑，因此您可以说这些片段中的每一个都需要由特定的 public 密钥签名。所以在这种情况下，不是 zImage 的闪存分区和 normal-board.dtb 的另一个闪存分区，而是 fitImage 所在的单个分区。它是将 "its" 文件提供给 mkimage 的输出。这类似于 "uImage" 是如何将 "zImage" 提供给 mkimage 的输出。
经过大量的工时学习、阅读和尝试 - 我创建了一篇完整的博客文章，内容涉及经过验证的 uboot 如何工作，以及 DTB（两种形式）在构建最终图像时如何结合在一起。
然而，要注意的关键事情确实是汤姆所说的，这里还有一些（在引用我的文章之后）：
- DTB有两种（kernel & uboot DTBS）
- 有一个名为 ITS 的文件 - 它描述了要构建的 FIT 映像
- 您将需要一个异步密钥对
- 您需要一个支持验证的 mkimage 版本 uboot/DTBs
- 您的引导加载程序需要支持已验证的 uboot 已启用
- Uboot 和 Linux 内核需要了解 DTB
- 即使您签署了图像，public 密钥的副本和其他加密信息也将需要在 final 引导加载程序 中
这是一个有趣的过程:)