firmware loading

firmware loading

[Daniel Drake]

Hi,

Dracut seems to lack a mechanism for firmware loading i.e. it doesn't
install the udev rules or the firmware loading helper.

Is this planned?

I'd be happy to come up with a patch. Would it be sensible to add it to
95udev-rules?

Thanks,
Daniel


--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: firmware loading

[Harald Hoyer]

On 07/02/2009 03:32 PM, Daniel Drake wrote:
> Hi,
>
> Dracut seems to lack a mechanism for firmware loading i.e. it doesn't
> install the udev rules or the firmware loading helper.
>
> Is this planned?
>
> I'd be happy to come up with a patch. Would it be sensible to add it to
> 95udev-rules?
>
> Thanks,
> Daniel

yep
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Firmware loading

[John Weber]

I'm attempting to configure Linux to load firmware for a Broadcom SDIO Wifi chip 
(BCM4329) onto an i.MX6-based board.

Here is my main question - How is firmware supposed to be loaded within the 
paradigm of a Yocto/Poky-built system?  Any insight and guidance is appreciated.

What I've done so far, and what I've discovered:

I've incorporated the driver into the kernel (backported from an upstream kernel 
rev), and removed the staging drivers present in 3.0.35.  It is built-in at the 
moment (not a module) and this is the error that I'm getting when it times-out 
loading firmware:

brcmfmac: brcmf_sdbrcm_download_code_file: Fail to request firmware -2
brcmfmac: _brcmf_sdbrcm_download_firmware: dongle image file download failed
brcmfmac: brcmf_bus_start: brcmf_sdbrcm_bus_init failed -1

The error code indicates that it cannot load firmware because it can't find the 
firmware file.

I've taken care to put the firmware in /lib/firmware/brcm (2 files).  The driver 
hardcodes a relative path filename to the firmware files and I've made sure that 
they are the same.

I've researched the firmware request process for the kernel.  My understanding 
is that the process looks like this:
1) driver requests firmware file
2) kernel opens up a special set of files in sysfs (/sys/class/firmware/xxx 
where xxx is the device name)
3) kernel signals udev to load firmware, giving it the filename and the device name
4) udev, through its rules, locates the firmware file for the device and writes 
it to the special file in sysfs

So, here is where I'm starting to get confused.  The default udev rules that are 
created in /lib/udev/rules.d/50-udev-default.rules show the following rule for 
firmware:

SUBSYSTEM=="firmware", ACTION=="add", IMPORT{builtin}="firmware"

I'm guessing that this is for cases where the firmware file is built-in to the 
kernel image.  I can see the necessity for doing this in some cases, but that is 
not what I'm doing at the moment, I'm trying to load the firmware from a file in 
the filesystem.  That requires udev to run a program or script that will read 
the file and write it to the appropriate file in sysfs.

The files in the poky udev recipe offers a clue, but for some reason that I 
don't understand, this file does not make it into the filesystem:

poky/meta/recipes-core/udev/udev/udev.rules:

# Firmware Helper
ACTION=="add", SUBSYSTEM=="firmware", RUN+="/lib/udev/firmware.sh"

This rule expects that there is a firmware helper script "firmware.sh" somewhere 
in the filesystem.  Other than this file, I can't file any reference to a 
"firmware.sh" file anywhere in the metadata, which could explain why this line 
doesn't make it into the installed filesystem.  I could only find references to 
files named this on the net.

Re: Firmware loading

[Otavio Salvador]

On Wed, Mar 6, 2013 at 12:06 PM, John Weber <rjohnweber@gmail.com> wrote:
> I'm attempting to configure Linux to load firmware for a Broadcom SDIO Wifi
> chip (BCM4329) onto an i.MX6-based board.
>
> Here is my main question - How is firmware supposed to be loaded within the
> paradigm of a Yocto/Poky-built system?  Any insight and guidance is
> appreciated.
>
> What I've done so far, and what I've discovered:
>
> I've incorporated the driver into the kernel (backported from an upstream
> kernel rev), and removed the staging drivers present in 3.0.35.  It is
> built-in at the moment (not a module) and this is the error that I'm getting
> when it times-out loading firmware:
>
> brcmfmac: brcmf_sdbrcm_download_code_file: Fail to request firmware -2
> brcmfmac: _brcmf_sdbrcm_download_firmware: dongle image file download failed
> brcmfmac: brcmf_bus_start: brcmf_sdbrcm_bus_init failed -1
>
> The error code indicates that it cannot load firmware because it can't find
> the firmware file.
>
> I've taken care to put the firmware in /lib/firmware/brcm (2 files).  The
> driver hardcodes a relative path filename to the firmware files and I've
> made sure that they are the same.
>
> I've researched the firmware request process for the kernel.  My
> understanding is that the process looks like this:
> 1) driver requests firmware file
> 2) kernel opens up a special set of files in sysfs (/sys/class/firmware/xxx
> where xxx is the device name)
> 3) kernel signals udev to load firmware, giving it the filename and the
> device name
> 4) udev, through its rules, locates the firmware file for the device and
> writes it to the special file in sysfs
>
> So, here is where I'm starting to get confused.  The default udev rules that
> are created in /lib/udev/rules.d/50-udev-default.rules show the following
> rule for firmware:
>
> SUBSYSTEM=="firmware", ACTION=="add", IMPORT{builtin}="firmware"
>
> I'm guessing that this is for cases where the firmware file is built-in to
> the kernel image.  I can see the necessity for doing this in some cases, but
> that is not what I'm doing at the moment, I'm trying to load the firmware
> from a file in the filesystem.  That requires udev to run a program or
> script that will read the file and write it to the appropriate file in
> sysfs.
>
> The files in the poky udev recipe offers a clue, but for some reason that I
> don't understand, this file does not make it into the filesystem:
>
> poky/meta/recipes-core/udev/udev/udev.rules:
>
> # Firmware Helper
> ACTION=="add", SUBSYSTEM=="firmware", RUN+="/lib/udev/firmware.sh"
>
> This rule expects that there is a firmware helper script "firmware.sh"
> somewhere in the filesystem.  Other than this file, I can't file any
> reference to a "firmware.sh" file anywhere in the metadata, which could
> explain why this line doesn't make it into the installed filesystem.  I
> could only find references to files named this on the net.

This is danny or master? For danny, please check the version of udev
being included as the udev maintained in meta-oe has some bugs but it
is used by default.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Firmware loading

[Eric Bénard]

Hi John,

Le Wed, 06 Mar 2013 09:06:36 -0600,
John Weber <rjohnweber@gmail.com> a écrit :

> I'm attempting to configure Linux to load firmware for a Broadcom SDIO Wifi chip 
> (BCM4329) onto an i.MX6-based board.
> 
> Here is my main question - How is firmware supposed to be loaded within the 
> paradigm of a Yocto/Poky-built system?  Any insight and guidance is appreciated.
> 
> What I've done so far, and what I've discovered:
> 
> I've incorporated the driver into the kernel (backported from an upstream kernel 
> rev), and removed the staging drivers present in 3.0.35.  It is built-in at the 
> moment (not a module) and this is the error that I'm getting when it times-out 
> loading firmware:
> 
> brcmfmac: brcmf_sdbrcm_download_code_file: Fail to request firmware -2
> brcmfmac: _brcmf_sdbrcm_download_firmware: dongle image file download failed
> brcmfmac: brcmf_bus_start: brcmf_sdbrcm_bus_init failed -1
> 
> The error code indicates that it cannot load firmware because it can't find the 
> firmware file.
> 
> I've taken care to put the firmware in /lib/firmware/brcm (2 files).  The driver 
> hardcodes a relative path filename to the firmware files and I've made sure that 
> they are the same.
> 
> I've researched the firmware request process for the kernel.  My understanding 
> is that the process looks like this:
> 1) driver requests firmware file
> 2) kernel opens up a special set of files in sysfs (/sys/class/firmware/xxx 
> where xxx is the device name)
> 3) kernel signals udev to load firmware, giving it the filename and the device name
> 4) udev, through its rules, locates the firmware file for the device and writes 
> it to the special file in sysfs
> 
if the driver is in the kernel it may not have the ability to require
the firmware from the file system as the file system may not yet be
mounted which can explain why you get the timeout.
You can check if you are in that case if you get the timeout log
before getting the log saying the filesystem is mounted.

To workaround that, you can integrate the firmware in the kernel image
by setting CONFIG_EXTRA_FIRMWARE="path/to/your/firmware" in the kernel
config, so that your driver can get its firmware (or you can compile
your driver as a module and load it after the file system is mounted).

Eric

Re: Firmware loading

[John Weber]

On 3/6/13 3:18 PM, Otavio Salvador wrote:
> On Wed, Mar 6, 2013 at 12:06 PM, John Weber <rjohnweber@gmail.com> wrote:
>> I'm attempting to configure Linux to load firmware for a Broadcom SDIO Wifi
>> chip (BCM4329) onto an i.MX6-based board.
>>
>> Here is my main question - How is firmware supposed to be loaded within the
>> paradigm of a Yocto/Poky-built system?  Any insight and guidance is
>> appreciated.
>>
>> What I've done so far, and what I've discovered:
>>
>> I've incorporated the driver into the kernel (backported from an upstream
>> kernel rev), and removed the staging drivers present in 3.0.35.  It is
>> built-in at the moment (not a module) and this is the error that I'm getting
>> when it times-out loading firmware:
>>
>> brcmfmac: brcmf_sdbrcm_download_code_file: Fail to request firmware -2
>> brcmfmac: _brcmf_sdbrcm_download_firmware: dongle image file download failed
>> brcmfmac: brcmf_bus_start: brcmf_sdbrcm_bus_init failed -1
>>
>> The error code indicates that it cannot load firmware because it can't find
>> the firmware file.
>>
>> I've taken care to put the firmware in /lib/firmware/brcm (2 files).  The
>> driver hardcodes a relative path filename to the firmware files and I've
>> made sure that they are the same.
>>
>> I've researched the firmware request process for the kernel.  My
>> understanding is that the process looks like this:
>> 1) driver requests firmware file
>> 2) kernel opens up a special set of files in sysfs (/sys/class/firmware/xxx
>> where xxx is the device name)
>> 3) kernel signals udev to load firmware, giving it the filename and the
>> device name
>> 4) udev, through its rules, locates the firmware file for the device and
>> writes it to the special file in sysfs
>>
>> So, here is where I'm starting to get confused.  The default udev rules that
>> are created in /lib/udev/rules.d/50-udev-default.rules show the following
>> rule for firmware:
>>
>> SUBSYSTEM=="firmware", ACTION=="add", IMPORT{builtin}="firmware"
>>
>> I'm guessing that this is for cases where the firmware file is built-in to
>> the kernel image.  I can see the necessity for doing this in some cases, but
>> that is not what I'm doing at the moment, I'm trying to load the firmware
>> from a file in the filesystem.  That requires udev to run a program or
>> script that will read the file and write it to the appropriate file in
>> sysfs.
>>
>> The files in the poky udev recipe offers a clue, but for some reason that I
>> don't understand, this file does not make it into the filesystem:
>>
>> poky/meta/recipes-core/udev/udev/udev.rules:
>>
>> # Firmware Helper
>> ACTION=="add", SUBSYSTEM=="firmware", RUN+="/lib/udev/firmware.sh"
>>
>> This rule expects that there is a firmware helper script "firmware.sh"
>> somewhere in the filesystem.  Other than this file, I can't file any
>> reference to a "firmware.sh" file anywhere in the metadata, which could
>> explain why this line doesn't make it into the installed filesystem.  I
>> could only find references to files named this on the net.
>
> This is danny or master? For danny, please check the version of udev
> being included as the udev maintained in meta-oe has some bugs but it
> is used by default.
>

I'm using master at the moment.  The version of udev is 182 in poky.

Re: Firmware loading

[John Weber]

Hi Eric,

On 3/6/13 3:48 PM, Eric Bénard wrote:
> Hi John,
>
> Le Wed, 06 Mar 2013 09:06:36 -0600,
> John Weber <rjohnweber@gmail.com> a écrit :
>
>> I'm attempting to configure Linux to load firmware for a Broadcom SDIO Wifi chip
>> (BCM4329) onto an i.MX6-based board.
>>
>> Here is my main question - How is firmware supposed to be loaded within the
>> paradigm of a Yocto/Poky-built system?  Any insight and guidance is appreciated.
>>
>> What I've done so far, and what I've discovered:
>>
>> I've incorporated the driver into the kernel (backported from an upstream kernel
>> rev), and removed the staging drivers present in 3.0.35.  It is built-in at the
>> moment (not a module) and this is the error that I'm getting when it times-out
>> loading firmware:
>>
>> brcmfmac: brcmf_sdbrcm_download_code_file: Fail to request firmware -2
>> brcmfmac: _brcmf_sdbrcm_download_firmware: dongle image file download failed
>> brcmfmac: brcmf_bus_start: brcmf_sdbrcm_bus_init failed -1
>>
>> The error code indicates that it cannot load firmware because it can't find the
>> firmware file.
>>
>> I've taken care to put the firmware in /lib/firmware/brcm (2 files).  The driver
>> hardcodes a relative path filename to the firmware files and I've made sure that
>> they are the same.
>>
>> I've researched the firmware request process for the kernel.  My understanding
>> is that the process looks like this:
>> 1) driver requests firmware file
>> 2) kernel opens up a special set of files in sysfs (/sys/class/firmware/xxx
>> where xxx is the device name)
>> 3) kernel signals udev to load firmware, giving it the filename and the device name
>> 4) udev, through its rules, locates the firmware file for the device and writes
>> it to the special file in sysfs
>>
> if the driver is in the kernel it may not have the ability to require
> the firmware from the file system as the file system may not yet be
> mounted which can explain why you get the timeout.
> You can check if you are in that case if you get the timeout log
> before getting the log saying the filesystem is mounted.
>
> To workaround that, you can integrate the firmware in the kernel image
> by setting CONFIG_EXTRA_FIRMWARE="path/to/your/firmware" in the kernel
> config, so that your driver can get its firmware (or you can compile
> your driver as a module and load it after the file system is mounted).
>
> Eric
>

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.

John

Re: Firmware loading

[Eric Bénard]

Le Wed, 06 Mar 2013 15:56:03 -0600,
John Weber <rjohnweber@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

Re: 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@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
>

Re: 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@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
>>

Re: Firmware loading

[Otavio Salvador]

On Thu, Mar 7, 2013 at 2:50 PM, John Weber <rjohnweber@gmail.com> wrote:
> I incorporated this blobs into the kernel image and it seems to have worked.
> Not the best option, but it does move me forward.

Can you make a bug report in https://bugzilla.yoctoproject.org/

Please pay attention to select the meta-fsl-arm BSP; put the more
information possible so we can fix it.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Firmware loading

[John Weber]

I could, but I think that these issues are probably resolved by using upstream 
sources, so I'm not sure if this is a bug for greater Yocto or not.  Does it 
make sense to file a bug, even if it is closed just for informational purposes?

I do think that this will be a problem for the following systems:
- Using a version of udev > 176 (I suspect this, as that is when udev moved to 
an internal-only firmware loading capability, but I know it is a problem for 182)
- Using a kernel < 3.7 (3.7 incorporated a filesystem firmware loading feature 
which bypasses udev)
- Drivers loading their firmware in the module init stage  (as the brcmfmac does)

I'd like to create a recipe to at least get this working in Yocto/Poky master 
for this and submit it to meta-freescale that would do the following:
- Patch the kernel to remove the staging drivers and add the 
net/wirelesss/brcm80211 backport
- Fetch the firmware from a *remote repository* and load it into the kernel's 
firmware directory
- Patch the defconfig to add the extra firmware to load into the kernel


On 3/8/13 6:15 AM, Otavio Salvador wrote:
> On Thu, Mar 7, 2013 at 2:50 PM, John Weber <rjohnweber@gmail.com> wrote:
>> I incorporated this blobs into the kernel image and it seems to have worked.
>> Not the best option, but it does move me forward.
>
> Can you make a bug report in https://bugzilla.yoctoproject.org/
>
> Please pay attention to select the meta-fsl-arm BSP; put the more
> information possible so we can fix it.
>
> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
>

Re: Firmware loading

[Otavio Salvador]

On Fri, Mar 8, 2013 at 12:35 PM, John Weber <rjohnweber@gmail.com> wrote:
> I could, but I think that these issues are probably resolved by using
> upstream sources, so I'm not sure if this is a bug for greater Yocto or not.
> Does it make sense to file a bug, even if it is closed just for
> informational purposes?

We cannot; due GPU issues. So please report a bug about it.

> I do think that this will be a problem for the following systems:
> - Using a version of udev > 176 (I suspect this, as that is when udev moved
> to an internal-only firmware loading capability, but I know it is a problem
> for 182)
>
> - Using a kernel < 3.7 (3.7 incorporated a filesystem firmware loading
> feature which bypasses udev)
> - Drivers loading their firmware in the module init stage  (as the brcmfmac
> does)
>
> I'd like to create a recipe to at least get this working in Yocto/Poky
> master for this and submit it to meta-freescale that would do the following:
> - Patch the kernel to remove the staging drivers and add the
> net/wirelesss/brcm80211 backport
> - Fetch the firmware from a *remote repository* and load it into the
> kernel's firmware directory
> - Patch the defconfig to add the extra firmware to load into the kernel

Read other reply please.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Firmware loading

[John Weber]

Bug is reported:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4013


On 3/8/13 11:36 AM, Otavio Salvador wrote:
> On Fri, Mar 8, 2013 at 12:35 PM, John Weber <rjohnweber@gmail.com> wrote:
>> I could, but I think that these issues are probably resolved by using
>> upstream sources, so I'm not sure if this is a bug for greater Yocto or not.
>> Does it make sense to file a bug, even if it is closed just for
>> informational purposes?
>
> We cannot; due GPU issues. So please report a bug about it.
>
>> I do think that this will be a problem for the following systems:
>> - Using a version of udev > 176 (I suspect this, as that is when udev moved
>> to an internal-only firmware loading capability, but I know it is a problem
>> for 182)
>>
>> - Using a kernel < 3.7 (3.7 incorporated a filesystem firmware loading
>> feature which bypasses udev)
>> - Drivers loading their firmware in the module init stage  (as the brcmfmac
>> does)
>>
>> I'd like to create a recipe to at least get this working in Yocto/Poky
>> master for this and submit it to meta-freescale that would do the following:
>> - Patch the kernel to remove the staging drivers and add the
>> net/wirelesss/brcm80211 backport
>> - Fetch the firmware from a *remote repository* and load it into the
>> kernel's firmware directory
>> - Patch the defconfig to add the extra firmware to load into the kernel
>
> Read other reply please.
>