uboot & uImage和linux引导过程

Question

通常，在嵌入式系统中，NAND闪存被划分为四个部分：--

1. 引导加载程序的分区(下面是uboot.bin)
2. 一个小分区，其中uboot保存它的环境变量。
3. 内核的分区(下面是uImage.bin)
4. 用于rootfs的分区

现在我有几个问题要问:--

1> 32位ARM单片机具有多个外部存储器接口，如DRAM和NAND或NOR闪存。我们的32位ARM单片机将如何知道从NAND上的哪个地址获取Uboot？在RAM中加载Uboot的地址是什么？

2>在8位单片机中，如AVR复位矢量地址为0x0000，在内置闪存中.32位ARM单片机如何指定复位矢量，因为它有许多不同类型的外部存储器接口连接到它。

3>在32位ARM单片机的情况下，先将Uboot放入内存中，然后加载到RAM中，然后uboot将uimage解压缩为LOADADDR。因此，要定义LOADADDR (未压缩的图像地址)，我们是否必须考虑(uboot本身+要加载到内存中的压缩uImage )的空间？FOr uImage我们如何定义LOADADDR？

4>是linux uImage中嵌入了rootfs还是它是一个独立的实体？如果rootfs是一个位于NAND上的独立实体，那么内核如何知道rootfs是从NAND上的哪个地址来的呢？

Answer 1

1)通常，参考手册中定义的每个可引导接口都有一个偏移量。例如，您可能能够从映射的内存启动NOR、NAND等。例如，NOR可能是0x1000，NAND0x4000。有关引导的参考手册章节将告诉您。

2)见1

3)通常，uboot不能只是“进入RAM中”。这必须通过第一阶段引导加载程序来完成。U具有SPL (辅助程序加载器)功能。这个SPL的工作是在处理器SRAM之外执行，并初始化系统DRAM，这样就可以加载完全的U引导可执行文件了。然后，U引导将需要适当的LOADADDR为您正在工作的板/芯片。U不解压缩内核，因为它正在引导。由于遗留原因，这通常是内核本身的一项工作。显然，您的内核应该能够适应您的内存，并且您可能需要确保在内核解压自己时，您没有覆盖其他组件(rootfs，设备树)。

4)这两种选择都是存在的，而且是有效的。如果rootfs是单独的，则需要知道它是什么类型的文件系统。如果它是initramfs，您可以定义它存储在原始NAND中的位置。如果它是一个持久的文件系统(ext4)，那么U引导需要知道如何处理分区映射。一旦完成，您实际上传递的是设备路径，而不是一个地址到内核。