Linux 设备驱动的固件加载

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

     硬件越来越复杂，硬件的许多功能使用了程序实现，与直接硬件实现相比，固件拥有处理复杂事物的灵活性和便于升级、维护等优点。固件（firmware）就是这样的一段在设备硬件自身中执行的程序，通过固件标准驱动程序才能实现特定机器的操作，如：光驱、刻录机等都有内部的固件。

      固件一般存放在设备上的flash存储器中，但出于成本和灵活性考虑，许多设备都将固件的映像(image)以文件的形式存放在硬盘中，设备驱动程序初始化时再装载到设备内部的存储器中。这样，方便了固件的升级，并省略了设备的flash存储器。

一、驱动和固件的区别

       从计算机领域来说，驱动和固件从来没有过明确的定义，就好像今天我们说内存，大部分人用来表示SDRAM，但也有人把Android里的“固化的Flash/Storage"称为“内存”，你不能说这样说就错了，因为这确实是一种“内部存储”。

      但在Linux Kernel中，Driver和Firmware是有明确含义的，

1、驱动

     Driver是控制被操作系统管理的外部设备（Device）的代码段。很多时候Driver会被实现为LKM，但这不是必要条件。driver通过driver_register()注册到总线(bus_type）上，代表系统具备了驱动某种设备（device）的能力。当某个device被注册到同样的总线的时候（通常是总线枚举的时候发现了这个设备），总线驱动会对driver和device会通过一定的策略进行binding（即进行匹配），如果Binding成功，总线驱动会调用driver的probe()函数，把设备的信息（例如端口，中断号等）传递给驱动，驱动就可以对真实的物理部件进行初始化，并把对该设备的控制接口注册到Linux的其他子系统上（例如字符设备，v4l2子系统等）。这样操作系统的其他部分就可以通过这些通用的接口来访问设备了。

2、固件

     Firmware，是表示运行在非“控制处理器”（指不直接运行操作系统的处理器，例如外设中的处理器，或者被用于bare metal的主处理器的其中一些核)中的程序。这些程序很多时候使用和操作系统所运行的处理器完全不同的指令集。这些程序以二进制形式存在于Linux内核的源代码树中，生成目标系统的时候，通常拷贝在/lib/firmware目录下。当driver对device进行初始化的时候，通过request_firmware()等接口，在一个用户态helper程序的帮助下，可以把指定的firmware加载到内存中，由驱动传输到指定的设备上。

     所以，总的来说，其实driver和firmware没有什么直接的关系，但firmware通常由驱动去加载。我们讨论的那个OS，一般不需要理解firmware是什么，只是把它当做数据。firmware是什么，只有使用这些数据的那个设备才知道。好比你用一个电话，电话中有一个软件，这个软件你完全不关心如何工作的，你换这个软件的时候，就可以叫这个软件是“固件”，但如果你用了一个智能手机，你要细细关系什么是上面的应用程序，Android平台，插件之类的细节内容，你可能就不叫这个东西叫“固件”了。

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

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

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

二、内核固件接口

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

[cpp]  view plain   copy

 

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

     函数request_firmware向用户空间请求提供一个名为name固件映像文件并等待完成。参数device为固件装载的设备。文件内容存入request_firmware 返回，如果固件请求成功，返回0。该函数从用户空间得到的数据未做任何检查，用户在编写驱动程序时，应对固件映像做数据安全检查，检查方向由设备固件提供商确定，通常有检查标识符、校验和等方法。

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

[cpp]  view plain   copy

 

1. struct firmware {  
2.  size_t size;  
3.  u8 *data;   
4. };  

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

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

[cpp]  view plain   copy

 

1. void release_firmware(struct firmware *fw);  

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

[cpp]  view plain   copy

 

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

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

三、固件如何工作

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

loading

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

data

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

device

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

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