Linux firmware子系统的实现机制学习笔记
一、Linux固件子系統概述
固件是硬件設備自身執行的一段程序。固件一般存放在設備flash內。而出于成本和便利性的考慮，通常是先將硬件設備的運行程序打包為一個特定格式的固件文件，存儲到終端系統內，通過終端系統給硬件設備進行升級。
Linux內核開發過程中，開發人員調試外設驅動設備，比如觸控，充電，線性馬達，存儲，WIFI設備等，同樣存在需要更新固件的情況。在Linux系統中，設備驅動程序處于內核態，而固件文件處于用戶態，因此需要一個安全穩定可靠的機制，用來確保設備驅動程序成功加載固件文件。
為了解決設備驅動程序從內核態穩定加載用戶態固件文件的問題，Linux系統提供了固件子系統。
二、Linux固件子系統實現機制
1. 流程簡介:
Linux固件子系統基于sysfs 和uevent機制實現。
驅動程序調用固件系統函數接口申請固件之后，固件子系統使用固件編譯內核的方式去獲取固件；如果獲取失敗，就使用固件緩存的方式去獲取固件；如果仍然獲取失敗，就使用默認路徑內核直接查找的方式去獲取固件。如果還是獲取失敗，就通過上報uevent消息給init進程。init進程則接收到uevent消息，過濾出subsystem類型為firmware的消息。init進程根據uevent消息內指向的固件信息去查找固件，通過sysfs提供的文件節點接口，把獲取的固件內容從用戶態寫入內核態，從而使驅動程序，獲取到固件文件的數據。
Linux固件系統提供了多種在不同場景下獲取固件文件的方法。
1）直接編譯到內核的方式；
2）固件緩存的方式；
3）直接根據內核指定路徑的方式：
4）通過init進程來協助處理的方式；
2. 流程框圖：
3. 主要函數接口：
主要函數接口：
申請固件接口主要類型分為同步和異步。
通常申請固件的過程比較耗時，以及處理固件升級的過程比較耗時，因此可以采用異步函數接口實現，或者在驅動程序內先創建工作隊列調用同步函數接口實現。
其中：
內核申請固件文件調用 request_firmware 函數實現。
內核獲取固件文件后調用 release_firmware 釋放相關的內存。
int request_firmware(const struct firmware **firmware_p, const char *name, struct device *device)
int request_firmware_direct(const struct firmware **firmware_p, const char *name, struct device *device)
int request_firmware_nowait(struct module *module, bool uevent, const char *name, struct device *device,
gfp_t gfp, void *context,
void (*cont)(const struct firmware *fw, void *context))
其中：
request_firmware_direct 接口只在內核指定的路徑內查找固件，不使用uevent機制來獲取固件。
request_firmware_nowait 接口是通過異步的工作隊列去獲取固件，可以起到不阻塞驅動probe時間的作用。
4. 實現過程：
(1) request_firmware 實現流程：
request_firmware 函數通過調用 _request_firmware_prepare 函數，設置不同的標志位，實現不同的差異功能。
a. _request_firmware_prepare 函數:
在打開 CONFIG_FW_LOADER 宏開關基礎上，首先通過調用 fw_get_builtin_firmware 函數的方式，判斷固件文件是否編譯到內核。
extern struct builtin_fw __start_builtin_fw[];
extern struct builtin_fw __end_builtin_fw[];
static void fw_copy_to_prealloc_buf(struct firmware *fw, void *buf, size_t size)
{
if (!buf || size < fw->size)
return;
memcpy(buf, fw->data, fw->size);
}
static bool fw_get_builtin_firmware(struct firmware *fw, const char *name, void *buf, size_t size)
{
struct builtin_fw *b_fw;
/*也就是說編譯進內核的固件放在特定的位置了!*/
for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
if (strcmp(name, b_fw->name) == 0) {
fw->size = b_fw->size;
fw->data = b_fw->data;
fw_copy_to_prealloc_buf(fw, buf, size);
return true;
}
}
return false;
}
//vmlinux.lds.h
/* Built-in firmware blobs */
.builtin_fw : AT(ADDR(.builtin_fw) - LOAD_OFFSET) {
__start_builtin_fw = .;
KEEP(*(.builtin_fw))
__end_builtin_fw = .;
}
接著調用 alloc_lookup_fw_priv 函數，判斷全局fw_cache結構內鏈表是否記錄過當前請求firmware的name。如果不存在當前請求firmware的name，則動態分配對應的內存空間并且添加當前請求firmware的name到全局的fw_cache結構內的鏈表。
b. fw_get_filesystem_firmware 函數:
主要是通過內核提供的默認路徑去查找固件文件，調用 kernel_read_file_from_path 函數。如果沒有查找到固件文件，則通過標志位 FW_OPT_USERHELPER 判斷，是否啟用 USER_HELPER 模式實現。
其中:
Firmware系統內默認路徑如下：
static char fw_path_para[256];
static const char * const fw_path[] = {
fw_path_para,
"/lib/firmware/updates/" UTS_RELEASE,
"/lib/firmware/updates",
"/lib/firmware/" UTS_RELEASE,
"/lib/firmware"
};
/* Typical usage is that passing 'firmware_class.path=$CUSTOMIZED_PATH'
* from kernel command line because firmware_class is generally built in
* kernel instead of module.
*/
module_param_string(path, fw_path_para, sizeof(fw_path_para), 0644); /*0644: perm visibility in sysfs*/
MODULE_PARM_DESC(path, "customized firmware image search path with a higher priority than default path");
sysfs路徑：/sys/module/firmware_class/parameters/path 權限：/sys/module/firmware_class/parameters # ls -laZ -rw-r--r-- 1 root root u:object_r:sysfs:s0 4096 2021-03-29 22:28 path
/* called from request_firmware() and request_firmware_work_func() */
static int
_request_firmware(const struct firmware **firmware_p, const char *name,
struct device *device, void *buf, size_t size,
enum fw_opt opt_flags) /* opt_flags = FW_OPT_UEVENT */
{
struct firmware *fw = NULL;
int ret;
if (!firmware_p)
return -EINVAL;
if (!name || name[0] == '') {
ret = -EINVAL;
goto out;
}
ret = _request_firmware_prepare(&fw, name, device, buf, size, opt_flags);
if (ret <= 0) /* error or already assigned */
goto out;
ret = fw_get_filesystem_firmware(device, fw->priv);
if (ret) {
if (!(opt_flags & FW_OPT_NO_WARN))
dev_warn(device, "Direct firmware load for %s failed with error %d
", name, ret);
ret = firmware_fallback_sysfs(fw, name, device, opt_flags, ret);
} else
ret = assign_fw(fw, device, opt_flags);
out:
if (ret < 0) {
fw_abort_batch_reqs(fw);
release_firmware(fw);
fw = NULL;
}
*firmware_p = fw;
return ret;
}
(2) USER_HELPER 模式：
fw_get_filesystem_firmware() 執行失敗后，會調用 firmware_fallback_sysfs() 函數，它里面會調用 fw_load_from_user_helper() 嘗試通過用戶
空間方式加載固件。
在內核打開 CONFIG_FW_LOADER_USER_HELPER 之后，才支持該功能。主要功能就是通過kernel上報uevent消息給到init進程，通過init進程獲取固件信息寫入底層sysfs節點。
a. fw_load_from_user_helper 函數：
先調用 fw_create_instance 函數創建device設備，class文件和屬性文件(只有一個loading文件)，以及分配 firmware_priv 結構體。
接著在 /sys/class/firmware 下將創建一個目錄，該目錄使用設備名作為它的目錄名。
該目錄包含三個屬性：
loading：
設置為 1：用戶空間開始裝載固件；
設置為 0：當裝載過程完畢時設置為0；
設置為 -1：將終止固件裝載過程。
data：
用來接收固件數據，在設置完 loading 后，用戶空間進程把固件寫入該屬性。
device：
/sys/devices 下相應入口的符號鏈接。
timeout：
默認申請firmware通過uevent方式最大超時時間為60S，支持上層寫入超時時間。
b. fw_load_sysfs_fallback 函數：
首先先禁用uevent上報，通過調用 device_add 函數添加設備，觸發調用 firmware_uevent 函數(怎么觸發的？)。其中，填充uevent上報的信息格式，包括固件的名稱，超時時間，是否異步。
static int do_firmware_uevent(struct fw_sysfs *fw_sysfs, struct kobj_uevent_env *env)
{
if (add_uevent_var(env, "FIRMWARE=%s", fw_sysfs->fw_priv->fw_name))
return -ENOMEM;
if (add_uevent_var(env, "TIMEOUT=%i", __firmware_loading_timeout()))
return -ENOMEM;
if (add_uevent_var(env, "ASYNC=%d", fw_sysfs->nowait))
return -ENOMEM;
return 0;
}
下一步則啟用uevent上報功能，同時調用kobject_uevent函數，上報add動作類型給到上層ueventd。
static int fw_load_sysfs_fallback(struct fw_sysfs *fw_sysfs, enum fw_opt opt_flags, long timeout)
{
int retval = 0;
struct device *f_dev = &fw_sysfs->dev;
struct fw_priv *fw_priv = fw_sysfs->fw_priv;
/* fall back on userspace loading */
if (!fw_priv->data)
fw_priv->is_paged_buf = true;
dev_set_uevent_suppress(f_dev, true);
retval = device_add(f_dev);
if (retval) {
dev_err(f_dev, "%s: device_register failed
", __func__);
goto err_put_dev;
}
mutex_lock(&fw_lock);
list_add(&fw_priv->pending_list, &pending_fw_head);
mutex_unlock(&fw_lock);
if (opt_flags & FW_OPT_UEVENT) {
fw_priv->need_uevent = true;
dev_set_uevent_suppress(f_dev, false);
dev_dbg(f_dev, "firmware: requesting %s
", fw_priv->fw_name);
kobject_uevent(&fw_sysfs->dev.kobj, KOBJ_ADD);
} else {
timeout = MAX_JIFFY_OFFSET;
}
retval = fw_sysfs_wait_timeout(fw_priv, timeout); /*在這里等待，超時時間為60s*/
if (retval < 0 && retval != -ENOENT) {
mutex_lock(&fw_lock);
fw_load_abort(fw_sysfs);
mutex_unlock(&fw_lock);
}
if (fw_state_is_aborted(fw_priv)) {
if (retval == -ERESTARTSYS)
retval = -EINTR;
else
retval = -EAGAIN;
} else if (fw_priv->is_paged_buf && !fw_priv->data)
retval = -ENOMEM;
device_del(f_dev);
err_put_dev:
put_device(f_dev);
return retval;
}
接著調用fw_state_wait_timeout函數，在預設的超時時間內等待上層ueventd的處理。
若超時時間達到或者收到完成量喚醒，則釋放之前申請的內存，釋放device，class等內存信息。
(3) ueventd相關firmware處理流程
Ueventd是init進程內重要的模塊，它主要處理selinux，dev設備創建，監聽kernel上報uevent消息，firmware固件加載等內容。
a.FirmwareHandler處理流程：
FirmwareHandler 內的 HandleUevent 方法主要是處理 firmware 固件加載和底層節點的交互流程。
首先先判斷 uevent 消息的 subsystem 類型是 firmware 字段才進行處理，這個類型只有 kernel 內 firmware 模塊才會上報。
HandleUevent 主要是通過一個主線程創建不同的子線程，并行分別處理來自kernel的不同驅動的firmware請求。
b. ProcessFirmwareEvent 函數:
首先是循環判斷ueventd支持的路徑內檢索固件文件是否存在；若存在，則寫入底層loading屬性文件為1，同時拷貝獲取的固件文件，寫入到底層data文件。完成之后則寫入底層loading屬性文件為0。
至此，kernel就獲取到了用戶空間寫入的固件文件信息。
其中:
ueventd 默認支持搜索固件的路徑：
來自 ueventd.rc文件內指定的firmware_directory。
參考：
https://mp.weixin.qq.com/s/14ngQm4bGg_XQEjhU3qnLg
https://www.kernel.org/doc/html/v4.13/driver-api/firmware/index.html
總結
以上是生活随笔為你收集整理的Linux firmware子系统的实现机制学习笔记的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： iOS 13可以越狱了吗iOS 13越狱
- 下一篇： matlab数字滤波器设计函数汇总(转载