<div dir="ltr">Hi Martin,<br><div class="gmail_extra"><br><div class="gmail_quote">On 24 August 2018 at 10:04, Martin Jansa <span dir="ltr"><<a href="mailto:martin.jansa@gmail.com" target="_blank">martin.jansa@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">One way to keep it allarch would be to package<span class=""><div>${nonarch_base_libdir}/<wbr>firmware/brcm/brcmfmac43430-<wbr>sdio.AP6212.txt<br>${nonarch_base_libdir}/<wbr>firmware/brcm/brcmfmac43430-<wbr>sdio.MUR1DX.txt<br></div></span><div>in 2 separate packages and handle</div><div>${nonarch_base_libdir}/<wbr>firmware/brcm/brcmfmac43430-<wbr>sdio.txt<br></div><div>symlink with update-alternatives</div><div><br></div><div>most MACHINEs won't install either of these packages and those which need it will pull the right one (e.g. through MACHINE_EXTRA_<wbr>RRECOMMENDS).</div><div><br></div><div>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).</div></div></blockquote><div><br></div>Thanks, this sounds like a good approach. I'll experiment with update-alternatives as I haven't used it before and see if I can come up with something sensible.<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Cheers,</div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 24, 2018 at 4:53 AM Andre McCurdy <<a href="mailto:armccurdy@gmail.com" target="_blank">armccurdy@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Aug 23, 2018 at 1:15 AM, Ryan Harkin <<a href="mailto:ryan.harkin@linaro.org" target="_blank">ryan.harkin@linaro.org</a>> wrote:<br>
><br>
> So now the ln issue is resolved, I'm not convinced my MACHINEOVERRIDES is<br>
> the correct approach. Does anyone have any feedback on how I can improve<br>
> that?<br>
<br>
If you want to make a configurable symlink then perhaps the more usual<br>
approach would be to just use a variable in the linux-firmware recipe<br>
to weakly define a default target for the symlink. Machine config<br>
files could then either do nothing (ie use the default) or provide<br>
their own value. For example, in the linux-firmware recipe:<br>
<br>
 BCM43430_NVRAM_SYMLINK ?= "brcmfmac43430-sdio.AP6212.<wbr>txt"<br>
<br>
 FILES_${PN}-bcm43430-nvram = " \<br>
  ${nonarch_base_libdir}/<wbr>firmware/brcm/brcmfmac43430-<wbr>sdio.txt \<br>
  ${nonarch_base_libdir}/<wbr>firmware/brcm/brcmfmac43430-<wbr>sdio.AP6212.txt \<br>
  ${nonarch_base_libdir}/<wbr>firmware/brcm/brcmfmac43430-<wbr>sdio.MUR1DX.txt \<br>
 "<br>
<br>
 do_install() {<br>
  ...<br>
  ln -sf ${BCM43430_NVRAM_SYMLINK}<br>
${D}${nonarch_base_libdir}/<wbr>firmware/brcm/brcmfmac43430-<wbr>sdio.txt<br>
 }<br>
<br>
And then in the machine config files of machines which need the MUR1DX<br>
firmware instead of the default, add:<br>
<br>
 BCM43430_NVRAM_SYMLINK = "brcmfmac43430-sdio.MUR1DX.<wbr>txt"<br>
<br>
However... note that currently the linux-firmware recipe is<br>
architecture independent (ie it won't be rebuilt if the target is<br>
changed). Adding a machine specific symlink is going to cause problems<br>
with that, so the above is still not a full solution.<br>
</blockquote></div>
</div></div></blockquote></div><br></div><div class="gmail_extra">Thanks Andre. It looks like it would work, but unless you see a problem, I'll look at Martin's idea first.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra">Ryan.</div><div class="gmail_extra"><br></div></div>