SPL(二级程序加载器)有什么用
what is the use of SPL (secondary program loader)
我对这三个问题的概念很迷茫
为什么我们需要辅助程序加载器?
它在哪个内存中加载和重定位?
系统内存和RAM有什么区别?
据我通过阅读链接了解到的是.. 当系统内部存储器不能完全容纳 uboot 时需要 SPL,因此我们需要使用称为 SPL 的最小代码片段初始化内存。 SPL是真的搬迁还是只是uboot自己搬迁?
理论上不需要辅助程序加载器 (SPL)。然而,拥有一个通常有务实的理由。我的头顶上有两个。
- 首先,模块化和易于开发。
- 其次,硬件启动过程可能限制太多。它可能期望引导加载程序位于没有足够空间存储整个引导过程的特定位置。
主加载程序执行加载完整启动过程 (SPL) 所需的一切。例如,主加载器可能存储在内存有限的 ROM 中。
让我以OMAP平台为例来解释一下(只是为了提供一些实际背景,而不仅仅是理论或常识)。
先看看一些事实:
- 在基于 OMAP 的平台上,开机后第一个程序 运行 是 ROM code(类似于 PC 上的 BIOS)。
- ROM 代码查找引导加载程序(它必须是一个名为 "MLO" 的文件,位于 MMC 的活动第一个分区,必须格式化为 FAT12/16/32,--但这是细节)
- ROM 代码将 "MLO" 文件的内容复制到 static RAM (because regular RAM is not initialized yet). Next picture shows SRAM memory layout for OMAP4460 SoC:
- SRAM 内存有限(由于物理原因),因此我们只有 48 KiB 用于引导加载程序。通常常规引导加载程序(例如 U-Boot)二进制文件比那个大。所以我们需要创建一些额外的引导加载程序,它将初始化常规 RAM 并将常规引导加载程序从 MMC 复制到 RAM,然后跳转到执行该常规引导加载程序。这个额外的引导加载程序通常被称为第一阶段引导加载程序(在两阶段引导加载程序场景中)。
所以这个第一阶段引导程序是U-Boot SPL; 第二阶段引导加载程序是常规U-Boot(或U-Boot proper)。明确一点:SPL 代表 Secondary Program Loader。这意味着 ROM 代码是 第一件事 加载(并执行)其他程序,而 SPL 是 第二件事 加载(并执行)其他程序。所以通常引导顺序是:ROM code -> SPL -> u-boot -> kernel。实际上它与 PC 引导非常相似,即:BIOS -> MBR -> GRUB -> 内核。
更新
为了绝对清楚,这里是 table 描述启动顺序的所有阶段(以澄清所用术语中可能存在的不确定性):
+--------+----------------+----------------+----------+
| Boot | Terminology #1 | Terminology #2 | Actual |
| stage | | | program |
| number | | | name |
+--------+----------------+----------------+----------+
| 1 | Primary | - | ROM code |
| | Program | | |
| | Loader | | |
| | | | |
| 2 | Secondary | 1st stage | u-boot |
| | Program | bootloader | SPL |
| | Loader (SPL) | | |
| | | | |
| 3 | - | 2nd stage | u-boot |
| | | bootloader | |
| | | | |
| 4 | - | - | kernel |
| | | | |
+--------+----------------+----------------+----------+
所以我只是使用 bootloader 作为 U-Boot 和 Program Loader[=65] 的同义词=] 作为任何加载其他程序的程序的通用术语。
另请参阅:
[2]TPL: SPL loading SPL - Denx
[4]Boot ROM vs Bootloader
我对这三个问题的概念很迷茫
为什么我们需要辅助程序加载器?
它在哪个内存中加载和重定位?
系统内存和RAM有什么区别?
据我通过阅读链接了解到的是.. 当系统内部存储器不能完全容纳 uboot 时需要 SPL,因此我们需要使用称为 SPL 的最小代码片段初始化内存。 SPL是真的搬迁还是只是uboot自己搬迁?
理论上不需要辅助程序加载器 (SPL)。然而,拥有一个通常有务实的理由。我的头顶上有两个。
- 首先,模块化和易于开发。
- 其次,硬件启动过程可能限制太多。它可能期望引导加载程序位于没有足够空间存储整个引导过程的特定位置。
主加载程序执行加载完整启动过程 (SPL) 所需的一切。例如,主加载器可能存储在内存有限的 ROM 中。
让我以OMAP平台为例来解释一下(只是为了提供一些实际背景,而不仅仅是理论或常识)。 先看看一些事实:
- 在基于 OMAP 的平台上,开机后第一个程序 运行 是 ROM code(类似于 PC 上的 BIOS)。
- ROM 代码查找引导加载程序(它必须是一个名为 "MLO" 的文件,位于 MMC 的活动第一个分区,必须格式化为 FAT12/16/32,--但这是细节)
- ROM 代码将 "MLO" 文件的内容复制到 static RAM (because regular RAM is not initialized yet). Next picture shows SRAM memory layout for OMAP4460 SoC:
- SRAM 内存有限(由于物理原因),因此我们只有 48 KiB 用于引导加载程序。通常常规引导加载程序(例如 U-Boot)二进制文件比那个大。所以我们需要创建一些额外的引导加载程序,它将初始化常规 RAM 并将常规引导加载程序从 MMC 复制到 RAM,然后跳转到执行该常规引导加载程序。这个额外的引导加载程序通常被称为第一阶段引导加载程序(在两阶段引导加载程序场景中)。
所以这个第一阶段引导程序是U-Boot SPL; 第二阶段引导加载程序是常规U-Boot(或U-Boot proper)。明确一点:SPL 代表 Secondary Program Loader。这意味着 ROM 代码是 第一件事 加载(并执行)其他程序,而 SPL 是 第二件事 加载(并执行)其他程序。所以通常引导顺序是:ROM code -> SPL -> u-boot -> kernel。实际上它与 PC 引导非常相似,即:BIOS -> MBR -> GRUB -> 内核。
更新
为了绝对清楚,这里是 table 描述启动顺序的所有阶段(以澄清所用术语中可能存在的不确定性):
+--------+----------------+----------------+----------+
| Boot | Terminology #1 | Terminology #2 | Actual |
| stage | | | program |
| number | | | name |
+--------+----------------+----------------+----------+
| 1 | Primary | - | ROM code |
| | Program | | |
| | Loader | | |
| | | | |
| 2 | Secondary | 1st stage | u-boot |
| | Program | bootloader | SPL |
| | Loader (SPL) | | |
| | | | |
| 3 | - | 2nd stage | u-boot |
| | | bootloader | |
| | | | |
| 4 | - | - | kernel |
| | | | |
+--------+----------------+----------------+----------+
所以我只是使用 bootloader 作为 U-Boot 和 Program Loader[=65] 的同义词=] 作为任何加载其他程序的程序的通用术语。
另请参阅:
[2]TPL: SPL loading SPL - Denx
[4]Boot ROM vs Bootloader