[meta-freescale] Firmware loading

[John Weber]

Not at all - CONFIG_FW_LOADER=y is definitely in the kernel config.

I think the issue is tied to some major changes in udev related to firmware 
loading.  Udev 176 brought all of the firmware loading functionality into a 
built-in function, rather than launch an external firmware helper script. This 
could be the reason that Canonical still hasn't moved to udev 176 or later versions.

While I haven't been able to do thorough testing, the Broadcom (brcm80211) 
driver does attempt to request firmware during the probe.  I believe that udev 
182 does not permit this until after the module is loaded.  This has caused some 
consternation amongst the maintainers [1], resulting in Linus adding direct 
firmware loading from the filesystem into kernel 3.7 and later [2].  This would 
bypass udev entirely for firmware loading.  I personally like this because in my 
view, this whole process of going to userspace to load firmware is too complicated.

Since, I'm on kernel 3.0.35 (stuck in the dark ages with Freescale), it might 
mean that I might have a few options, none of which are great.

(A) Go back to udev 164 in Danny which supports using a rule to launch an 
external helper script to load firmware
(B) Backport the firmware loader from file functionality from an upstream kernel 
into 3.0.35
(C) Move to a mainline kernel, which isn't really an option because all of 
Freescale's multimedia functionality gets lost

Here is the dump of /var/log/messages related to udevd after I load the module 
using modprobe:

Mar  6 15:21:01 wandboard-dual daemon.info udevd[234]: validate module index
Mar  6 15:21:01 wandboard-dual daemon.info udevd[234]: seq 2119 queued, 'remove'
  'firmware'
Mar  6 15:21:01 wandboard-dual daemon.info udevd[234]: seq 2119 forked new worke
r [501]
Mar  6 15:21:01 wandboard-dual daemon.info udevd[234]: seq 2120 queued, 'add' 'd
rivers'
Mar  6 15:21:01 wandboard-dual daemon.info udevd[501]: seq 2119 running
Mar  6 15:21:01 wandboard-dual daemon.info udevd[234]: seq 2120 forked new worke
r [502]
Mar  6 15:21:01 wandboard-dual daemon.info udevd[501]: no db file to read /var/r
un/udev/data/+firmware:mmc1:0001:2: No such file or directory
Mar  6 15:21:01 wandboard-dual daemon.info udevd[501]: passed -1 bytes to netlin
k monitor 0x49c50
Mar  6 15:21:01 wandboard-dual daemon.info udevd[501]: seq 2119 processed with 0
Mar  6 15:21:01 wandboard-dual daemon.info udevd[234]: seq 2119 done with 0
Mar  6 15:21:01 wandboard-dual daemon.info udevd[502]: seq 2120 running
Mar  6 15:21:01 wandboard-dual daemon.info udevd[502]: device 0x36b70 has devpat
h '/bus/sdio/drivers/brcmfmac'
Mar  6 15:21:01 wandboard-dual daemon.info udevd[502]: no db file to read /var/r
un/udev/data/+drivers:brcmfmac: No such file or directory
Mar  6 15:21:01 wandboard-dual daemon.info udevd[502]: passed -1 bytes to netlin
k monitor 0x36dc8
Mar  6 15:21:01 wandboard-dual daemon.info udevd[234]: seq 2120 done with 0
Mar  6 15:21:01 wandboard-dual daemon.info udevd[502]: seq 2120 processed with 0


[1] http://lwn.net/Articles/518942/
[2] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=abb139e75c2cdbb955e840d6331cb5863e409d0e


On 3/6/13 4:04 PM, Eric Bénard wrote:
> Le Wed, 06 Mar 2013 15:56:03 -0600,
> John Weber <rjohnweber at gmail.com> a écrit :
>> Thanks for the help.  I've since broken the driver out of the kernel and
>> modprobed it with the same results.  This allows me to start udevadm to see some
>> debug output from udev, but it still fails.  I've manually created a firmware
>> helper script as well, and that's not even being executed at the moment.
>>
>> It just seems like this kind of thing is already being done as the i.MX6 vpu
>> firmware is needed (not being loaded into the filesystem now, but that is a
>> different issue), as well as other machines use atheros wifi modules.  This
>> seems that I'm missing something.
>>
> stupid question, but do you have
> CONFIG_FW_LOADER=y
> in your kernel config ?
>
> Maybe you can post the udev log also as it may contain some hints.
>
> Eric
>