request_firmware

http://oss.org.cn/kernel-book/ldd3/ch14s08.html

14.8. 处理固件

作为一个驱动作者, 你可能发现你面对一个设备必须在它能支持工作前下载固件到它里面. 硬件市场的许多地方的竞争是如此得强烈, 以至于甚至一点用作设备控制固件的 EEPROM 的成本制造商都不愿意花费. 因此固件发布在随硬件一起的一张 CD 上, 并且操作系统负责传送固件到设备自身.

你可能想解决固件问题使用这样的一个声明:

static char my_firmware[] = { 0x34, 0x78, 0xa4, ... }; 

但是, 这个方法几乎肯定是一个错误. 将固件编码到一个驱动扩大了驱动的代码, 使固件升级困难, 并且非常可能产生许可问题. 供应商不可能已经发布固件映象在 GPL 之下, 因此和 GPL-许可的代码混合常常是一个错误. 为此, 包含内嵌固件的驱动不可能被接受到主流内核或者被 Linux 发布者包含.

14.8.1. 内核固件接口

正确的方法是当你需要它时从用户空间获取它. 但是, 请抵制试图从内核空间直接打开包含固件的文件的诱惑; 那是一个易出错的操作, 并且它安放了策略(以一个文件名的形式)到内核. 相反, 正确的方法时使用固件接口, 它就是为此而创建的:

#include <linux/firmware.h>
int request_firmware(const struct firmware **fw, char *name, 
 struct device *device); 

调用 request_firmware 要求用户空间定位并提供一个固件映象给内核; 我们一会儿看它如何工作的细节. name 应当标识需要的固件; 正常的用法是供应者提供的固件文件名. 某些象 my_firmware.bin 的名子是典型的. 如果固件被成功加载, 返回值是 0(负责常用的错误码被返回), 并且 fw 参数指向一个这些结构:

struct firmware {
 size_t size;
 u8 *data; 
}; 

那个结构包含实际的固件, 它现在可被下载到设备中. 小心这个固件是来自用户空间的未被检查的数据; 你应当在发送它到硬件之前运用任何并且所有的你能够想到的检查来说服你自己它是正确的固件映象. 设备固件常常包含标识串, 校验和, 等等; 在信任数据前全部检查它们.

在你已经发送固件到设备前, 你应当释放 in-kernel 结构, 使用:

void release_firmware(struct firmware *fw); 

因为 request_firmware 请求用户空间来帮忙, 它保证在返回前睡眠. 如果你的驱动当它必须请求固件时不在睡眠的位置, 异步的替代方法可能要使用:

int request_firmware_nowait(struct module *module,
 char *name, struct device *device, void *context,
 void (*cont)(const struct firmware *fw, void *context)); 

这里额外的参数是 moudle( 它将一直是 THIS_MODULE), context (一个固件子系统不使用的私有数据指针), 和 cont. 如果都进行顺利, request_firmware_nowait 开始固件加载过程并且返回 0. 在将来某个时间, cont 将用加载的结果被调用. 如果由于某些原因固件加载失败, fw 是 NULL.

14.8.2. 它如何工作

固件子系统使用 sysfs 和热插拔机制. 当调用 request_firmware, 一个新目录在 /sys/class/firmware 下使用你的驱动的名子被创建. 那个目录包含 3 个属性:

loading

这个属性应当被加载固件的用户空间进程设置为 1. 当加载进程完成, 它应当设为 0. 写一个值 -1 到 loading 会中止固件加载进程.

data

data 是一个二进制的接收固件数据自身的属性. 在设置 loading 后, 用户空间进程应当写固件到这个属性.

device

这个属性是一个符号连接到 /sys/devices 下面的被关联入口项.

一旦创建了 sysfs 入口项, 内核为你的设备产生一个热插拔事件. 传递给热插拔处理者的环境包括一个变量 FIRMWARE, 它被设置为提供给 request_firmware 的名子. 这个处理者应当定位固件文件, 并且拷贝它到内核使用提供的属性. 如果这个文件无法找到, 处理者应当设置 loading 属性为 -1.

如果一个固件请求在 10 秒内没有被服务, 内核就放弃并返回一个失败状态给驱动. 超时周期可通过 sysfs 属性 /sys/class/firmware/timeout 属性改变.

使用 request_firmware 接口允许你随你的驱动发布设备固件. 当正确地集成到热插拔机制, 固件加载子系统允许设备简化工作"在盒子之外" 显然这是处理问题的最好方法.

但是, 请允许我们提出多一条警告: 设备固件没有制造商的许可不应当发布. 许多制造商会同意在合理的条款下许可它们的固件, 如果客气地请求; 一些其他的可能不何在. 无论如何, 在没有许可时拷贝和发布它们的固件是对版权法的破坏并且招致麻烦.

以下转自：http://blog.csdn.net/lanmanck/article/details/5127174

对于刚使用的人来说，上面都说的笼统，说了等于没说，我总结一下：

1、request_firmware在内核使用，需要文件系统支持，就是说，启动的时候如果在驱动里面的probe函数调用request_firmware ，那么系统将等待30s左右，因为文件系统还没有挂载，当然找不到固件了，所以最好在中断里面启动tasklet，然后request_firmware 。如果不想等待，就用request_firmware_nowait，好像是这样写的。

 

2、那么用户层怎么用？这是初学者最易迷惑的，网上的基本都没有讲到。

实际上这个分x86和嵌入式，比如arm，平台。x86的用到了udev，我没有试。我说说arm平台的，用的是busybox的mdev。

比如你要请求固件 fw.hex，那么必须在文件系统中导出环境变量，比如 export FIRMWARE=/lib/firmware，而且目录/lib/firmware不能少，因为busybox要用到。然后把固件fw.hex放到/lib/firmware目录下即可。内核request_firmware的时候，busybox就知道去FIRMWARE找了。这实际上用到了mdev的热插拔功能：

echo /sbin/mdev > /proc/sys/kernel/hotplug

 

3、对linux来讲，所谓的固件什么也不是，他只是按fopen()返回二进制文件给你，看看busybox的处理就知道了。所以你的文件随便定义，比如一个mp3文件，你也可以称为固件：request_firmware("xxx.mp3")，那么你文件系统里面也要有这个xxx.mp3文件，只不过系统给你返回二进制数据，具体的处理要在内核进行。