href="https://www.cnblogs.com/ljbguanli/p/19621814"

title="发布于

aria-level="2">深入解析：[Linux]学习笔记系列

[base][drivers]firmware

xmlns="http://www.w3.org/2000/svg">

d="M5,0

style="-webkit-tap-highlight-color:

rgba(0,

firmware
categories:

• linux
• drivers
• base
  

  tags:

• linux
• drivers
• base
  abbrlink:

  d5ecd7c4
  date:

  09:01:49

---

https://github.com/wdfk-prog/linux-study

alt="在这里插入图片描述"

src="https://i-blog.csdnimg.cn/direct/b1d14562abd34931a71f7ab3978528fe.png">

class="toc">

文章中的代码实现了Linux内核的固件加载器（Firmware

Loader）框架。

这项技术的诞生是为了解决现代硬件驱动程序面临的几个核心问题：

• 许可（Licensing）问题：许多硬件设备（如Wi-Fi、GPU、网络适配器）需运行一段专有的、非开源的“固件”代码才能正常工作。

  根据GPLv2许可证，这些二进制“固件块”（blobs）不能直接编译进开源的Linux内核镜像中。

  固件加载器提供了一种机制，将这些非开源固件与开源的驱动程序分离开来。

• 灵活性和可更新性：将固件硬编码到驱动程序中是一种非常僵硬的设计。

  当固件需要更新以修复bug或添加新功能时，用户将不得不重新编译并安装整个内核。

  固件加载器允许固件作为普通文件存放在文件系统中（通常在

  /lib/firmware），使得更新固件就像替换一个文件一样简单，无需触及内核本身。

• 内存和内核大小：内核镜像（vmlinuz）中不应该包括所有可能用到的设备的固件。

  这样做会极大地增加内核的大小。

  按需从文件系统中加载固件，意味着只有当检测到相应硬件并需固件时，才会将其读入内存，从而提高了内存采用效率。

id="_29">它的发展经历了哪些重要的里程碑或版本迭代？

固件加载机制经历了重要的演进：

• 早期（无统一机制）：最初，驱动程序没有标准的方式来加载固件，有些驱动甚至会尝试将固件硬编码在代码中。

• Hotplug脚本机制：后来，内核引入了一个基于

  “hotplug”

  /sbin/hotplug），并将所需固件的名称作为参数传递。

  该脚本负责在文件系统中找到固件并将其提供给内核。

  这种方式功能上可行，但执行一个新进程的开销较大，效率较低。

• 现代（基于uevent和sysfs的）机制：这是当前使用的机制，也是drivers/base/firmware代码的核心实现。

  它用一个更高效的、基于netlink套接字的uevent事件通知机制取代了执行脚本。

  当内核需要固件时，它通过sysfs导出一个接口，并发送一个uevent通知用户空间守护进程（通常是systemd-udevd）。

  该守护进程负责找到固件文件并将其内容写入内核通过sysfs创建的节点中，从而完成加载。

• 异步加载的引入：最初的

  request_firmware()

  API是同步的，会阻塞驱动的探测（probe）过程直到固件加载完成或超时。

  后来，为了优化启动时间和处理不能睡眠的上下文，内核引入了异步的

  request_firmware_nowait()

  接口，它会立即返回，并在固件加载完成后通过回调函数通知驱动程序。

目前该技术的社区活跃度和主流应用情况如何？

固件加载器是Linux内核中一个极其稳定、成熟且不可或缺的基础设施。

它被内核中几乎所有与复杂现代硬件交互的驱动程序所使用，包括但不限于：

• 无线网络和蓝牙适配器
• 图形处理器（AMD,

  NVIDIA,

  Intel）

• 高性能网络接口卡（NIC）
• 存储控制器（SAS,

  NVMe）

• 数字信号处理器（DSP）

id="_44">核心原理与设计

它的核心工作原理是什么？

固件加载器的核心是一个精心设计的内核与用户空间的交互流程，以

request_firmware()

API为例：

1. 驱动请求：设备驱动在其

   函数中，调用

   request_firmware(&fw,

   "my_firmware.bin",

   来请求固件。

2. 内核准备：固件加载器核心在内核中创建一个临时的固件对象，并通过sysfs在

   /sys/class/firmware/

   my_firmware.bin），其中包含

   loading

   等控制文件。

3. 发送Uevent：内核向用户空间发送一个

   “add”

   类型的uevent（内核事件）。

   这个事件包含了所需固件的名称（FIRMWARE=“my_firmware.bin”）和请求该固件的设备信息。

4. 阻塞等待：调用

   request_firmware()

   的内核线程现在会进入睡眠状态，等待用户空间提供固件数据。

5. 用户空间处理：systemd-udevd

   udevd

   守护进程接收到uevent。

   它根据事件中的固件名称，在文件系统的标准路径（如

   /lib/firmware/）下查找对应的固件文件。

6. 数据回传：找到文件后，udevd

   1

   文件，表示开始加载。

   然后，它打开固件文件，读取其全部内容，并将这些二进制数据写入到sysfs的

   data

   表示加载完成（或负值表示失败）。

7. 内核唤醒：对

   data

   文件的写入操作会唤醒之前睡眠的内核线程。

   固件加载器核心代码会验证接收到的数据，将其存入驱动提供的

   struct

   指针所指向的结构中。

8. 返回驱动：request_firmware()

   访问到固件内容，并将其上传到硬件设备。

9. 释放：驱动使用完固件后，必须调用

   release_firmware(fw)

   id="_57">它的主要优势体现在哪些方面？

• 解耦：将驱动逻辑与固件数据完全分离，符合良好的软件工程实践。

• 灵活性：更新固件无需修改或重新编译内核。

• 许可合规性：允许内核在保持GPLv2开源的同时，利用专有二进制固件。

• 效率：相比早期的hotplug脚本，基于uevent的机制开销更低、速度更快。

它存在哪些已知的劣势、局限性或在特定场景下的不适用性？

• 启动依赖问题（Chicken-and-egg

  problem）：这是该机制最核心的局限性。

  如果一个存储设备（如某些NVMe

  SSD或RAID卡）的驱动需要加载固件才能初始化硬件，而这个固件文件又恰好存放在该存储设备上的根文件系统中，那么就会陷入死锁：驱动无法加载固件，因为文件系统不可用；文件系统不可用，因为驱动无法初始化。

• 解决方案：这个问题的标准解决方案是使用initramfs（初始RAM文件系统）。

  在内核启动早期，将必要的驱动和固件资料打包到一个临时的、基于内存的文件系统（initramfs）中。

  这样，驱动就可以在真正的根文件系统被挂载之前，从initramfs中加载到所需的固件。

id="_67">使用场景

在哪些具体的业务或技术场景下，它是首选解决方案？

请举例说明。

request_firmware

框架是Linux内核中需要从外部加载二进制数据块到驱动中的唯一标准且首选的解决方案。

• Wi-Fi驱动：一个Wi-Fi网卡驱动（如iwlwifi）在探测到硬件后，会请求相应的

  iwlwifi-xxxx.ucode

  固件。

  这个固件包含了无线通信协议栈的底层实现，驱动会将其上传到网卡的处理器上执行。

• GPU驱动：现代GPU驱动（如amdgpu）在初始化时会加载多个固件文件，用于图形处理、视频编解码、电源管理等不同功能模块。

• NVMe

  SSD驱动：一些企业级NVMe固态硬盘的驱动可能需要在启动时加载特定的固件来启用高级功能或应用安全补丁。

id="_74">是否有不推荐使用该技巧的场景？

为什么？

• 需要固件才能挂载根文件系统，且无法使用initramfs：在这种极其罕见且通常是系统设计问题的场景下，固件加载器将无法工作。

• 固件数据极其简单：如果所谓的“固件”只是一小组配置寄存器的值，那么将其硬编码在驱动中可能比引入文件I/O和用户空间交互更简单直接。

• 无文件系统的嵌入式环境：在一些没有完整文件系统的深度嵌入式系统中，驱动可能会被设计为直接从闪存的某个原始分区读取固件，这需要驱动达成自己的加载逻辑，而不是启用通用的固件加载器。

对比分析

id="____80">请将其

进行详细对比。

固件的提供方式主要有以下几种，request_firmware

是其中最通用和灵活的一种。

operator">*firmware_kobj

class="token

function">EXPORT_SYMBOL_GPL

class="token

punctuation">(firmware_kobj

class="token

function">firmware_init

class="token

function">kobject_create_and_add

class="token

operator">!firmware_kobj

class="token

punctuation">}