固件升级相关接触与request_firmware

产品在送样调试后，测试发现的问题需要解决和优化，可以调试单样品，也可以整机调试（整机升级固件）。

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

我不清楚有多少种固件升级方法，接触的几个是 *.h、*.i、*.bin、*.img 等。前两个放入驱动中，后两者提供接口由应用层调用执行（不知是否正确）。

有人说高通平台采用img方式，去了解了一下，发现此乃较严谨的商业做法趋向。

前两种的思路大致如下：

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

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

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

后两者在实际中得到了大力赏识和“正道”之称，便