Linux 理解嵌入式板上已验证的Uboot
我已经浏览了演示文稿和文档,寻找经过验证的u-boot,并提出了几个问题。我将尝试引导任何用户了解我的情况,因为我怀疑我不是唯一一个在理解已验证u-boot的过程方面有点困难的人 我有一个编译好的zImage,它有一个工作的外部DTB,可以在没有验证的情况下使用。它启动并工作让我们称之为normal-board.dts 其次,我使用以下配置条目编译了u-boot:Linux 理解嵌入式板上已验证的Uboot,linux,embedded-linux,u-boot,Linux,Embedded Linux,U Boot,我已经浏览了演示文稿和文档,寻找经过验证的u-boot,并提出了几个问题。我将尝试引导任何用户了解我的情况,因为我怀疑我不是唯一一个在理解已验证u-boot的过程方面有点困难的人 我有一个编译好的zImage,它有一个工作的外部DTB,可以在没有验证的情况下使用。它启动并工作让我们称之为normal-board.dts 其次,我使用以下配置条目编译了u-boot: CONFIG_ARM=y CONFIG_ARCH_AT91=y CONFIG_TARGET_AT91SAM9260EK=y CONF
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使用的DTS,并且需要在它自己的分区中
FIT DTB与non-FIT one normal-board.DTB的DTB大致相同,但其中包含FIT magic
FIT内核映像我假设zImage中也添加了一些魔力?
已经看到有一个uboot控件适合FDT,这需要它自己的分区吗?FIT DTB是否与工作内核DTB相同,只是将其闪存,而不是非FIT DTB
接下来,考虑到我从各种文档和幻灯片中开始分析的这个脚本,我们可以看到u-boot.{dts,dtb}是控制FDT,ITS文件是带有fit的文件,我假设它与normal-board.dts相同,但添加了一个fit节点
例如,u-boot.dts
/dts-v1/;
/ {
model = "Keys";
compatible = "myboard";
signature {
dev_key {
required = "conf";
algo = "sha1,rsa2048";
key-name-hint = "dev_key";
};
};
};
下面是myboard的DTS示例和FIT部分:
/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";
};
};
};
};
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_高变量
#> 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以及逻辑,因此您可以说这些部分中的每一部分都需要使用特定的公钥签名。因此,在本例中,fitImage可以驻留在一个分区中,而不是zImage的闪存分区和normal-board.dtb的闪存分区。它是将its文件提供给mkimage的输出。这类似于uImage是将zImage提供给mkimage的输出。
因此,上面的问题有很多,我将尝试回答一些有助于澄清问题的问题: U-Boot二进制文件需要包含公钥。因此,在本例中,您列出的myboard设备树就是需要结束的地方。它位于二进制文件中,而不是闪存中的单独分区。 接下来的事情是,FIT图像是一个容器,其中包含了不同的打开方式。fitImage包含zImage和normal-board.dtb以及逻辑,因此您可以说这些部分中的每一部分都需要使用特定的公钥签名。因此,在本例中,fitImage可以驻留在一个分区中,而不是zImage的闪存分区和normal-board.dtb的闪存分区。它是将its文件提供给mkimage的输出。这类似于uImage是将zImage提供给mkimage的输出。
经过长时间的学习、阅读和尝试,我写了一篇完整的博客文章,介绍了如何验证uboot的工作原理,以及DTB在构建最终图像时如何将这两种形式结合在一起 这个 然而,需要注意的关键是Tom所说的,在引用了我的文章之后,这里还有一些内容: 有两种类型的DTB内核&uboot DTB 有一个名为ITS的文件-它描述了要构建的FIT映像 您将需要一个异步密钥对 您需要一个支持已验证的uboot/DTB的mkimage版本 您的引导加载程序需要支持已验证的uboot启用 Uboot和Linux内核需要了解DTB 即使您对图像进行了签名,最终引导加载程序中仍需要公钥和其他加密信息的副本
这是一个有趣的过程:经过长时间的学习、阅读和尝试后,我写了一篇完整的博客文章,介绍了经过验证的uboot是如何工作的,以及在构建最终图像时DTB和DTB是如何结合在一起的 这个 然而,需要注意的关键是Tom所说的,在引用了我的文章之后,这里还有一些内容: 有两种类型的DTB内核&uboot DTB 有一个名为ITS的文件-它描述了要构建的FIT映像 您将需要一个异步密钥对 您需要一个支持已验证的uboot/DTB的mkimage版本 您的引导加载程序将需要支持 启用 Uboot和Linux内核需要了解DTB 即使您对图像进行了签名,最终引导加载程序中仍需要公钥和其他加密信息的副本
这是一个有趣的过程:谢谢汤姆。下一个问题是关于地址、加载等。。我更新了我的答案,以显示我是如何走到这一步的。谢谢汤姆。下一个问题是关于地址、加载等。。我更新了我的答案以显示我是如何走到这一步的。原来的链接似乎断了。这是来自的缓存版本。原始链接似乎已断开。这是来自的缓存版本。
#> 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