{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.xiaopingtou.cn//data/attach/topic/topicKPo7gB.jpg', '推荐 旅途青蛙 的文章《Firmware 加载原理分析》','https://www.xiaopingtou.net/article-69979.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
前言
前段时间移植 wifi 驱动到 android 的内核上，发现 firmware 的加载始终出错，问了几个人，都不是很了解，没办法，只好自己研究一下。
显然是通过 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 需要做的事情包括两件： 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 总线把数据写到模块里面去了；