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).
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 <armccu...@gmail.com
<mailto:armccu...@gmail.com>> wrote:
On Thu, Aug 23, 2018 at 1:15 AM, Ryan Harkin <ryan.har...@linaro.org
<mailto:ryan.har...@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@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
