<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 24 August 2018 at 11:43, Mike Looijmans <span dir="ltr"><<a href="mailto:mike.looijmans@topic.nl" target="_blank">mike.looijmans@topic.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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).</blockquote><div><br></div><div>I agree. That's a longer term change that will take quite some time to filter through, if at all.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 24-08-18 11:04, Martin Jansa wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
One way to keep it allarch would be to package<br>
${nonarch_base_libdir}/firmwar<wbr>e/brcm/brcmfmac43430-sdio.<wbr>AP6212.txt<br>
${nonarch_base_libdir}/firmwar<wbr>e/brcm/brcmfmac43430-sdio.<wbr>MUR1DX.txt<br>
in 2 separate packages and handle<br>
${nonarch_base_libdir}/firmwar<wbr>e/brcm/brcmfmac43430-sdio.txt<br>
symlink with update-alternatives<br>
<br>
most MACHINEs won't install either of these packages and those which need it will pull the right one (e.g. through MACHINE_EXTRA_RRECOMME<wbr>NDS).<br>
<br>
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).<br>
<br>
Cheers,<br>
<br></span><span class="">
On Fri, Aug 24, 2018 at 4:53 AM Andre McCurdy <<a href="mailto:armccurdy@gmail.com" target="_blank">armccurdy@gmail.com</a> <mailto:<a href="mailto:armccurdy@gmail.com" target="_blank">armccurdy@gmail.com</a>>> wrote:<br>
<br>
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><br></span><div><div class="h5">
<mailto:<a href="mailto:ryan.harkin@linaro.org" target="_blank">ryan.harkin@linaro.org</a><wbr>>> 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.txt<wbr>"<br>
<br>
FILES_${PN}-bcm43430-nvram = " \<br>
${nonarch_base_libdir}/firmwar<wbr>e/brcm/brcmfmac43430-sdio.txt \<br>
${nonarch_base_libdir}/firmwar<wbr>e/brcm/brcmfmac43430-sdio.<wbr>AP6212.txt \<br>
${nonarch_base_libdir}/firmwar<wbr>e/brcm/brcmfmac43430-sdio.<wbr>MUR1DX.txt \<br>
"<br>
<br>
do_install() {<br>
...<br>
ln -sf ${BCM43430_NVRAM_SYMLINK}<br>
${D}${nonarch_base_libdir}/fir<wbr>mware/brcm/brcmfmac43430-sdio.<wbr>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.txt<wbr>"<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>
<br>
<br>
<br>
</div></div></blockquote><div class="HOEnZb"><div class="h5">
<br>
-- <br>
______________________________<wbr>_________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openem<wbr>bedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>core</a><br>
</div></div></blockquote></div><br></div></div>