[参考译文] Linux：Linux 设备驱动程序、BIOS、引导加载程序、initrd - initramfs

尊敬的 Amimal Khan：

由于您已在 TI 论坛上发布此查询、我将讨论基于 TI 的嵌入式 SOC (片上系统)。
i) BIOS 是否包含任何驱动程序？？
我)是的。 由于这是一个 TI 论坛、我们来讨论特定于常见 TI 芯片组的芯片组、如 DaVinci 和 Sitara SOC 芯片组。 它们具有与 BIOS 类似的 RBL (只读引导加载程序、用户/开发人员无法写入其中)。 它从介质(如 SDCard、NAND、eMMC、USB、以太网、UART)中拾取第一级引导加载程序(在 TI SOC 世界中称为 MLO、SPL、xloader 等)、具体取决于硬件开关、可以更改硬件开关以使其选择其中一个引导选项。 回到这个问题、是的、RBL(BIOS)有一组驱动程序(可能不是 Linux 驱动程序、而是一段代码与硬件交互并使其正常工作)。 TI 可以访问他们使用的 RBL 代码、我在这个论坛中看到过、很少有 TI 人员在内部引用代码并给出指示。 此外、TRM (技术参考手册)详细介绍了支持的硬件类型(如 NAND 类型等)

ii)它如何检测硬件并执行开机自检或与硬盘、RAM 等通信？？
我在前面的回答中提到过、它读取一个引导开关、我们可以对其进行设置。 然后、根据 SDCard 或 NAND 等介质集、第一级引导加载程序预计位于特定偏移(NAND 位于0x00地址、尽管支持的 NAND 配置列表将以 TRM 指定)或格式(在大多数 TI 案例中、 它可以读取包含第一级引导加载程序的 FAT32分区 SDCard)。 因此、所连接的 NAND 或所使用的 SDCard 应该有一个预定义的要求(大多数 NAND 器件或 SDCard 类型都满足这个要求)。 嵌入式 SOC 没有任何特定于 POST 的功能。

III)Now if device drivers are packed into kernel、so when bootloader load kernel image into RAM、does it does it means the drivers that ware packed inside kernel are too loaded into RAM、if then the kernel who need a temporary root file system to load drivers？(如果是、引导加载程序需要临时根文件系统来加载驱动程序？)
ME)在嵌入式世界中、我们并非总是使用 RAMDISK (临时文件系统)。 但在桌面等一般用途中，安装根文件系统的介质可能会有所不同。 因此、很难使内核(内核大小将会增加)内包含所有驱动程序。 因此它使用初始 ramdisk，它具有工具和可加载模块，用于检测存在根文件系统的介质并加载它们。 由于在类似桌面的环境中，根文件系统可以存储在任何可用介质中，因此 ramdisk 起着至关重要的作用。 在嵌入式环境中、它有助于从 RAM 快速引导和运行应用程序、因为它比从存储在辅助存储器中的根文件系统运行更快。

IV)引导加载程序：如果引导加载程序正在从硬盘驱动器将内核映像加载到 RAM 中、则意味着它应该包含用于硬盘驱动器的设备驱动程序。 那么为什么内核需要加载 RAID 控制器和驱动程序？？ 引导加载程序是否应将驱动程序切换至内核？？？
ME)引导加载程序顾名思义、是在引导时运行以加载操作系统软件的一段代码。 它是一段代码、比 BIOS (RBL 代码)功能更强大。 实际上、由于连接的外设可能会有所不同、存储操作系统软件的介质也可能有所不同、因此我们需要一个引导加载程序来初始化足够的外设和存储器以加载操作系统。 但需要记住的是、引导加载程序不能非常大且通用。 它必须是特定于电路板的(具有给定的外设和存储器集)。 回到移交驱动程序的问题(尽管这似乎是一个好主意)、与 Linux 内核相比、引导加载程序是一个简单的代码。 分层和抽象以及 API 在内核和引导加载程序之间是不同的。 引导加载程序中的驱动程序代码可能很简单、不适合 Linux 内核等更分层的代码、也不适合该代码的完整版本。 但是、诸如设置视频、成像子系统等外设时钟和引脚多路复用等的初始化步骤可在引导加载程序中执行一次、无需在 Linux 内核中再次设置。 虽然有两组驱动程序、一组在引导加载程序中、另一组在内核中、似乎是冗余的、但考虑到 Linux 驱动程序的上述点与简单的引导加载程序代码相比是通用的、分层的、也是成熟的、这似乎是合理的。