[OE-core] [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM

[Ryan Harkin]

On 24 August 2018 at 11:43, Mike Looijmans <mike.looijmans at topic.nl> wrote:

> I think this should be solved in the driver actually. It probably "knows"
> which variant is there (or could be taught using devicetree or so).


I agree. That's a longer term change that will take quite some time to
filter through, if at all.

The device doesn't know which variant it is, but I'm *hoping* to add a
device tree attribute to cover this, but there has been resistance this in
the past, so it may not be an easy change to get accepted.


>
> On 24-08-18 11:04, Martin Jansa wrote:
>
>> One way to keep it allarch would be to package
>> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.AP6212.txt
>> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.MUR1DX.txt
>> in 2 separate packages and handle
>> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt
>> symlink with update-alternatives
>>
>> most MACHINEs won't install either of these packages and those which need
>> it will pull the right one (e.g. through MACHINE_EXTRA_RRECOMMENDS).
>>
>> In worst case someone will try to install both packages and based on u-a
>> priority one of them will win (use higher priority for the more common
>> version).
>>
>> Cheers,
>>
>> On Fri, Aug 24, 2018 at 4:53 AM Andre McCurdy <armccurdy at gmail.com
>> <mailto:armccurdy at gmail.com>> wrote:
>>
>>     On Thu, Aug 23, 2018 at 1:15 AM, Ryan Harkin <ryan.harkin at linaro.org
>>     <mailto:ryan.harkin at linaro.org>> wrote:
>>      >
>>      > So now the ln issue is resolved, I'm not convinced my
>> MACHINEOVERRIDES is
>>      > the correct approach. Does anyone have any feedback on how I can
>> improve
>>      > that?
>>
>>     If you want to make a configurable symlink then perhaps the more usual
>>     approach would be to just use a variable in the linux-firmware recipe
>>     to weakly define a default target for the symlink. Machine config
>>     files could then either do nothing (ie use the default) or provide
>>     their own value. For example, in the linux-firmware recipe:
>>
>>        BCM43430_NVRAM_SYMLINK ?= "brcmfmac43430-sdio.AP6212.txt"
>>
>>        FILES_${PN}-bcm43430-nvram = " \
>>          ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt \
>>          ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.AP6212.txt
>> \
>>          ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.MUR1DX.txt
>> \
>>        "
>>
>>        do_install() {
>>          ...
>>          ln -sf ${BCM43430_NVRAM_SYMLINK}
>>     ${D}${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt
>>        }
>>
>>     And then in the machine config files of machines which need the MUR1DX
>>     firmware instead of the default, add:
>>
>>        BCM43430_NVRAM_SYMLINK = "brcmfmac43430-sdio.MUR1DX.txt"
>>
>>     However... note that currently the linux-firmware recipe is
>>     architecture independent (ie it won't be rebuilt if the target is
>>     changed). Adding a machine specific symlink is going to cause problems
>>     with that, so the above is still not a full solution.
>>
>>
>>
>>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180828/4b47709b/attachment-0002.html>