[meta-freescale] Firmware loading

[John Weber]

I incorporated this blobs into the kernel image and it seems to have worked. 
Not the best option, but it does move me forward.

John

On 3/7/13 10:21 AM, John Weber wrote:
> 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
>>