为什么我们需要嵌入式设备中的引导加载程序？-IT科技

摘要：问题描述：我正在使用 ARM cortex-A8 上的 ELinux 内核。我知道引导加载程序的工作原理以及它的作用。但我有一个问题 - 我们为什么需要引导加载程序，引导加载程序为何诞生？为什么我们不能不通过 bootloader 直接从闪存中将内核加载到 RAM 中？如果我们加载它会发生什么？事实上，处理器...

问题描述：

我正在使用 ARM cortex-A8 上的 ELinux 内核。

我知道引导加载程序的工作原理以及它的作用。但我有一个问题 - 我们为什么需要引导加载程序，引导加载程序为何诞生？

为什么我们不能不通过 bootloader 直接从闪存中将内核加载到 RAM 中？如果我们加载它会发生什么？事实上，处理器不支持它，但是我们为什么要遵循这个程序呢？

解决方案 1：

在 Linux 中，引导加载程序负责一些预定义的任务。因为这个问题手臂标记，我认为ARM 启动可能是一种有用的资源。具体来说，引导加载程序负责设置一个ATAG列表，该列表描述了 RAM 的数量、内核命令行和其他参数。最重要的参数之一是机器类型。使用设备树，可以传递主板的完整描述。这使得普通的 ARM Linux 无法启动，除非有一些代码来设置所述参数。

这些参数允许一个通用Linux 支持多个设备。例如，ARM Debian 内核可以支持数百种不同的主板类型。Uboot 或其他引导加载程序可以动态确定此信息，也可以为主板进行硬编码。

您可能还想查看堆栈溢出处的引导加载程序信息页面。

基本系统可能能够设置ATAGS并将 NOR 闪存复制到 SRAM。但是，通常比这更复杂一些。Linux 需要设置 RAM，因此您可能需要初始化 SDRAM 控制器。如果您使用 NAND 闪存，则必须处理坏块，并且复制可能比更复杂一些memcpy()。

Linux 经常存在一些潜在的驱动程序错误，驱动程序会假设时钟已初始化。例如，如果Uboot始终为特定机器初始化以太网时钟，则 Linux 以太网驱动程序可能忽略了设置此时钟。时钟树尤其如此。

有些系统需要 Linux 不支持的启动映像格式；例如，可以立即初始化硬件的特殊标头；如配置devices读取初始代码。此外，通常有一些硬件需要立即配置；引导加载程序可以快速完成此操作，而 Linux 的正常结构可能会显著延迟此操作，从而导致 I/O 冲突等。

从实用角度来看，使用引导加载程序更简单。但是，没有什么可以阻止您更改 Linux 的源代码以直接从其引导；尽管这可能就像将引导加载程序代码直接粘贴到 Linux 的启动部分一样。

另请参阅：Coreboot、Uboot和Wikipedia 的比较。Barebox是一个鲜为人知但结构良好且现代的 ARM 引导加载程序。RedBoot 也用于一些ARM 系统；内核树支持 RedBoot 分区。

解决方案 2：

引导加载程序是一种计算机程序，它在完成自检后为计算机加载主操作系统或运行环境。

^来自维基百科文章

因此，基本上引导加载程序正在执行您想要的操作 - 将数据从闪存复制到操作内存中。真的就这么简单。

如果您想了解有关引导操作系统的更多信息，我强烈建议您阅读链接的文章。除了测试之外，引导阶段还包括检查外围设备和其他一些东西。跳过它们只在非常简单的嵌入式设备上有意义，这就是为什么它们的引导加载程序更简单的原因：

一些嵌入式系统不需要明显的启动序列即可开始运行，并且在打开时可能只需运行存储在 ROM 中的操作程序。

同一来源

解决方案 3：

主引导加载程序通常内置于硅片中，并执行系统中运行的第一个用户代码的加载。

引导加载程序之所以存在，是因为没有标准化的协议来加载第一个代码，因为它依赖于芯片。有时可以通过串行端口、闪存甚至硬盘加载代码。找到它是引导加载程序的功能。

一旦用户代码被加载并运行，引导加载程序就不再使用，并且系统执行的正确性由用户负责。

在嵌入式 Linux 链中，主引导程序将设置并运行 Uboot。然后 Uboot 将找到 Linux 内核并加载它。

解决方案 4：

为什么我们不能不通过 bootloader 直接从闪存中将内核加载到 RAM 中？如果我们加载它会发生什么？事实上，处理器不支持它，但是我们为什么要遵循这个程序呢？

Bartek、Artless 和 Felipe 均给出了图片的部分内容。

每种嵌入式处理器类型（例如 386EX、Coretex-A53、EM5200）在重置或通电时都会自动执行某些操作。有时，根据设备是否通电或重置，某些操作会有所不同。某些嵌入式处理器允许您根据设备通电或重置时施加到不同引脚的电压来更改某些操作。

无论如何，处理器可以做的事情是有限的，因为定义某些事情需要处理器上的物理空间，无论是片上 FLASH、指令微代码还是其他机制。

这个限制意味着某物

目标明确，尽快做好一件事。
范围和能力有限，通常将一小块代码（通常几千字节或更少）加载到固定的内存位置并从加载的代码开始执行。
不可修改。

因此，处理器对重置或电源循环的响应是无法改变的，也不能做太多事情，我们不希望它自动将数百兆字节或千兆字节复制到可能不存在或未初始化的内存中，这可能需要很长时间。

所以....

我们设置了一个小程序，该程序小于我们将要使用的所有设备允许的最小大小。该程序存储在需要它的任何位置。

有时小程序是 U-Boot。有时 U-Boot 太大，无法初始加载，因此小程序会依次加载 U-Boot。

重点是，无论由加载什么，都可以根据特定系统的需求进行修改。如果是 U-Boot，那就太好了，如果不是，它知道在哪里加载主操作系统或在哪里加载 U-Boot（或其他引导加载程序）。

然后，U-Boot（一般指引导加载程序）会配置一组最少的设备、内存、芯片设置等，以便加载和启动主操作系统。主操作系统 init 负责处理任何其他配置或初始化。

因此顺序如下：

处理器开机或复位
加载初始启动代码（或 U-Boot 样式的嵌入式引导加载程序）
初始启动代码（可能不需要）
U-Boot（或其他通用嵌入式引导加载程序）
Linux 初始化

解决方案 5：

除了所有其他答案中所述（这是正确的）之外，在某些情况下，系统必须经历不同的执行模式，例如用于安全 ARM 芯片的 TrustZone。仍然可以将其视为某种硬件初始化，但奇怪的是，存在其他限制（例如：可用内存），这使得在单个二进制文件中完成所有操作不切实际，甚至不可能，因此可以使用多个阶段的引导加载程序。

此外，出于安全原因，每个系统都经过签名，并且只有满足安全要求才能执行其工作。