From: John Weber <rjohnweber@gmail.com>
To: Otavio Salvador <otavio@ossystems.com.br>
Cc: "meta-freescale@yoctoproject.org"
<meta-freescale@yoctoproject.org>,
"poky@yoctoproject.org" <poky@yoctoproject.org>
Subject: Re: [meta-freescale] Firmware loading
Date: Fri, 08 Mar 2013 09:35:52 -0600 [thread overview]
Message-ID: <513A0558.6020703@gmail.com> (raw)
In-Reply-To: <CAP9ODKqaVVqHi9_90kO6bGuf8zk0MWk40a7M8RQ9MQi1tNgKxQ@mail.gmail.com>
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
>
WARNING: multiple messages have this Message-ID (diff)
From: John Weber <rjohnweber@gmail.com>
To: Otavio Salvador <otavio@ossystems.com.br>
Cc: "meta-freescale@yoctoproject.org"
<meta-freescale@yoctoproject.org>,
"poky@yoctoproject.org" <poky@yoctoproject.org>
Subject: Re: Firmware loading
Date: Fri, 08 Mar 2013 09:35:52 -0600 [thread overview]
Message-ID: <513A0558.6020703@gmail.com> (raw)
In-Reply-To: <CAP9ODKqaVVqHi9_90kO6bGuf8zk0MWk40a7M8RQ9MQi1tNgKxQ@mail.gmail.com>
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
>
next prev parent reply other threads:[~2013-03-08 15:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-06 15:06 Firmware loading John Weber
2013-03-06 21:18 ` Otavio Salvador
2013-03-06 21:50 ` [meta-freescale] " John Weber
2013-03-06 21:50 ` John Weber
2013-03-06 21:48 ` [meta-freescale] " Eric Bénard
2013-03-06 21:48 ` Eric Bénard
2013-03-06 21:56 ` [meta-freescale] " John Weber
2013-03-06 21:56 ` John Weber
2013-03-06 22:04 ` [meta-freescale] " Eric Bénard
2013-03-06 22:04 ` Eric Bénard
2013-03-07 16:21 ` [meta-freescale] " John Weber
2013-03-07 16:21 ` John Weber
2013-03-07 17:50 ` [meta-freescale] " John Weber
2013-03-07 17:50 ` John Weber
2013-03-08 12:15 ` Otavio Salvador
2013-03-08 15:35 ` John Weber [this message]
2013-03-08 15:35 ` John Weber
2013-03-08 17:36 ` Otavio Salvador
2013-03-12 3:53 ` [meta-freescale] " John Weber
2013-03-12 3:53 ` John Weber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=513A0558.6020703@gmail.com \
--to=rjohnweber@gmail.com \
--cc=meta-freescale@yoctoproject.org \
--cc=otavio@ossystems.com.br \
--cc=poky@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.