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

Andre McCurdy armccurdy at gmail.com
Fri Aug 24 02:53:17 UTC 2018


On Thu, Aug 23, 2018 at 1:15 AM, Ryan Harkin <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.



More information about the Openembedded-core mailing list