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 <[email protected]> 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: [email protected] http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
_______________________________________________
meta-freescale mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-freescale
