转自：http://blog.csdn.net/dxdxsmy/article/details/8669840
前言
前段时间移植 wifi 驱动到 Android 的内核上，发现 firmware 的加载始终出错，问了几个人，都不是很了解，没办法，只好自己研究一下。
原理分析
从本质上来说， firmware 需要做的事情包括两件：
1， 通知用户态程序，我需要下载 firmware 了；
2， 用户态程序把用户态的数据 copy 到内核层；
3， 内核把内核态的数据写到设备上，比如 wifi 模块里；
其中第三步应该不难，关键是看看， Linux 里面是如何实现第一、二步的；
实现机制
简单的说，它的机制分成以下几部分：
1， 通过一定的方式，通知用户态程序，比如 init 程序，如图所示：
显然是通过 kobject_uevent 的方式通知的应用层，它的机制我有空再详细解释，简单的说，就是往一个socket 广播一个消息，只需要在应用层打开 socket 监听 NETLINK_KOBJECT_UEVENT 组的消息，就可以收到了。
用户态的 init 是如何做的？
可以看到 init 程序打开了一个 socket ，然后绑定它，最后通过 select 来监听 socket 上来的数据，最后调用handle_device_fd 来处理收到的消息；当内核发送一个 KOBJ_ADD 的消息上来的时候，经过过滤，判断是否是 firmware 要被加载的消息，然后调用
handle_firmware_event 来处理；
2， 用户态的数据如何下载到内核；
本质上它是内核创建了两个文件，一个文件 A 用来标志下载的开始和结束，另外一个文件 B 用来接收用户层传下来的数据，当用户态的程序往 A 文件写入 1 的时候，标志用户态程序已经往里面写程序来，而往里面写入 0 的时候，就标志下载成功结束，如果写入 -1 就表示下载失败了；下面看看这两个文件是如何被创建的 , 以及数据是如何写到内核的，请看图：
这个图基本上就是两个文件被创立的过程，以及当这两个文件被用户态程序访问的时候将要被调用的函数，比如对于标志文件，如果往里面写入数据，将会触发函数 firmware_loading_store 函数，如果往 bin文件里面写入数据将会触发 bin 文件类型的 write 函数；
用户态写数据的过程大约是这样的：当用户态收到 KOBJ_ADD 消息的时候最终将会调用handle_firmware_event 的函数；
它的过程就是：
a, 先往标志文件里面写 1 ；
b, 从用户空间读取数据；
c, 往内核创建的文件里面写数据；
d, 如果成功写入 0 ，否则写入 -1 ；
下面看看内核是如何接受这些文件的，前面提到内核创建了一个 bin 文件，用来接收用户态的数据，下面看看这个过程：
对于SYSFS_KOBJ_BIN_ATTR 属性的文件，在 inode 初始化的时候，将会被赋予 bin_fops 的文件操作函数集，于是当上层调用 write 的时候，将会走到内核的 bin_fops.write 函数；这个函数干的事情很简单，就是把用户态的数据 copyright 到 bb->buffer ，而 bb->buffer 其实是在 open 的时候分配的空间，这样的话，就实现了用户态的数据到内核的 copy ；过程是不是完了？
还有一个步骤，这个 bb->buffer 本身是如何与 wifi 驱动交互的呢？这只是一个中间层，它的数据必须要写到 wifi 的驱动才应该算完整，而这一步其实就是通过 flush_write 来完成的，下面看看这个过程：
这里可以清楚的看到， flush_write 做的事情就是把 bb->buffer 的内容 copy 到 wifi driver 分配的空间 fw->data 里面去了，至此，用户态的数据已经完整的写到了 wifi 的 driver 空间了；
3， 内核态的数据到 wifi 模块
这个就比较简单了，通过函数 sdio_writesb 利用 sdio 总线把数据写到模块里面去了；
总结
Firmware 的加载主要是利用了 uevent 的通讯机制实现用户态和内核态的交互，另外还涉及了 sys 文件系统里的文件创建 , 我加载 wifi firmware 始终出错的原因是 android 的文件系统要求把 wifi 的 firmware helper放到 /etc/firmware 里面，而把真正的 firmware sd8686.bin 放到 /etc/firmware/mrvl 里面，估计是 marvel 修改后的结果，结论就是，这个设计还真行。
From : http://blog.csdn.NET/linweig/article/details/5640697