Skip to main content
 首页 » 操作系统

Linux firmware子系统的实现机制学习笔记

2022年07月19日49jackei

一、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] == '\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\n", 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\n", __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\n", 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


本文参考链接:https://www.cnblogs.com/hellokitty2/p/14594987.html