Hello,
I am seeing this error in my build:
Configuring aCollected errors: * check_data_file_clashes: Package linux-firmware-bcm43430 wants to install file /linaro/mbl/workspace-arm/build-mbl/tmp-mbl-glibc/work/imx7s _warp-oe-linux-gnueabi/mbl-console-image-test/1.0-r0/root fs/lib/firmware/brcm/brcmfmac43430-sdio.bin But that file is already provided by package * firmware-imx * check_data_file_clashes: Package linux-firmware-bcm43430 wants to install file /linaro/mbl/workspace-arm/build-mbl/tmp-mbl-glibc/work/imx7s _warp-oe-linux-gnueabi/mbl-console-image-test/1.0-r0/root fs/lib/firmware/brcm/brcmfmac43430-sdio.txt But that file is already provided by package * firmware-imx
In my build, I'm including meta-raspberrypi and meta-freescale-3rdparty in my manifest. These two meta layers include the following two files into the rootfs in various ways:
/lib/firmware/brcm/brcmfmac43430-sdio.txt /lib/firmware/brcm/brcmfmac43430-sdio.bin
For example, in the following files define a way of adding the firmware into the rootfs (there will be more ways they get into the build, saying as one is a .inc file):
meta-freescale-3rdparty/recipes-bsp/broadcom-nvram-config/ broadcom-nvram-config.inc meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware_%.bbappend openembedded-core/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
My meta-layer is included after meta-freescale* and meta-raspberrypi, but before openembedded-core/meta in my BBLAYERS setup.
However, I want to provide a newer version of these two files in my build. So we created this recipe in our meta layer:
file: recipes-bsp/firmware-imx/firmware-imx_%.bbappend ------------------------------------------------------------ -------------------------- SRCREV_linuxfirmware = "a61ac5cf8374edbfe692d12f805a1b194f7fead2" SRCREV_recalboxbuildroot = "f648e4b54eb5e4be593746d6cc51375b22a7efbd"
SRC_URI += "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linu x-firmware.git;branch=${SRCBRANCH};destsuffix=${S}/git1;name=linuxfirmware http://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;branch=$%7BSRCBRANCH%7D;destsuffix=$%7BS%7D/git1;name=linuxfirmware \ git://github.com/recalbox/recalbox-buildroot.git;protocol= https;branch=${SRCBRANCH};destsuffix=${S}/git2;name=recalboxbuildroot http://github.com/recalbox/recalbox-buildroot.git;protocol=https;branch=$%7BSRCBRANCH%7D;destsuffix=$%7BS%7D/git2;name=recalboxbuildroot " LIC_FILES_CHKSUM += "file://git1/LICENCE.broadcom_ bcm43xx;md5=3160c14df7228891b868060e1951dfbc \ file://git2/COPYING;md5=e4edbc78b8892db416b6a07e0d97309a "
do_install_append() { install -d ${D}${base_libdir}/firmware install -d ${D}${base_libdir}/firmware/brcm
cp -rfv git1/brcm/brcmfmac43430-sdio.bin ${D}${base_libdir}/firmware/br cm cp -rfv git2/board/warp7/rootfs_overlay/lib/firmware/brcm/brcmfmac43430-sdio.txt ${D}${base_libdir}/firmware/brcm }
FILES_${PN} += "${base_libdir}/firmware/brcm/brcmfmac43430*"
COMPATIBLE_MACHINE = "(imx7s-warp)" ------------------------------------------------------------ --------------------------
It builds fine in a "normal" configuration. However, in a "test" build, where "dev-pkgs" is added to IMAGE_FEATURES, I get the error as above.
So how do I work around this issue? Am I doing the wrong thing by providing a bbappend to overlay these files?
Any advice appreciated.
Regards, Ryan.
On Tue, Nov 28, 2017 at 11:36 PM, Ryan Harkin ryan.harkin@linaro.org wrote:
Hello,
I am seeing this error in my build:
Configuring aCollected errors:
- check_data_file_clashes: Package linux-firmware-bcm43430 wants to install
file /linaro/mbl/workspace-arm/build-mbl/tmp-mbl-glibc/work/imx7s_warp-oe-linux-gnueabi/mbl-console-image-test/1.0-r0/rootfs/lib/firmware/brcm/brcmfmac43430-sdio.bin But that file is already provided by package * firmware-imx
- check_data_file_clashes: Package linux-firmware-bcm43430 wants to install
file /linaro/mbl/workspace-arm/build-mbl/tmp-mbl-glibc/work/imx7s_warp-oe-linux-gnueabi/mbl-console-image-test/1.0-r0/rootfs/lib/firmware/brcm/brcmfmac43430-sdio.txt But that file is already provided by package * firmware-imx
In my build, I'm including meta-raspberrypi and meta-freescale-3rdparty in my manifest. These two meta layers include the following two files into the rootfs in various ways:
/lib/firmware/brcm/brcmfmac43430-sdio.txt /lib/firmware/brcm/brcmfmac43430-sdio.bin
For example, in the following files define a way of adding the firmware into the rootfs (there will be more ways they get into the build, saying as one is a .inc file):
meta-freescale-3rdparty/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config.inc meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware_%.bbappend openembedded-core/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
My meta-layer is included after meta-freescale* and meta-raspberrypi, but before openembedded-core/meta in my BBLAYERS setup.
However, I want to provide a newer version of these two files in my build. So we created this recipe in our meta layer:
file: recipes-bsp/firmware-imx/firmware-imx_%.bbappend
SRCREV_linuxfirmware = "a61ac5cf8374edbfe692d12f805a1b194f7fead2" SRCREV_recalboxbuildroot = "f648e4b54eb5e4be593746d6cc51375b22a7efbd"
SRC_URI += "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;branch=${SRCBRANCH};destsuffix=${S}/git1;name=linuxfirmware \ git://github.com/recalbox/recalbox-buildroot.git;protocol=https;branch=${SRCBRANCH};destsuffix=${S}/git2;name=recalboxbuildroot " LIC_FILES_CHKSUM += "file://git1/LICENCE.broadcom_bcm43xx;md5=3160c14df7228891b868060e1951dfbc \ file://git2/COPYING;md5=e4edbc78b8892db416b6a07e0d97309a "
do_install_append() { install -d ${D}${base_libdir}/firmware install -d ${D}${base_libdir}/firmware/brcm
cp -rfv git1/brcm/brcmfmac43430-sdio.bin${D}${base_libdir}/firmware/brcm cp -rfv git2/board/warp7/rootfs_overlay/lib/firmware/brcm/brcmfmac43430-sdio.txt ${D}${base_libdir}/firmware/brcm }
FILES_${PN} += "${base_libdir}/firmware/brcm/brcmfmac43430*"
COMPATIBLE_MACHINE = "(imx7s-warp)"
It builds fine in a "normal" configuration. However, in a "test" build, where "dev-pkgs" is added to IMAGE_FEATURES, I get the error as above.
So how do I work around this issue? Am I doing the wrong thing by providing a bbappend to overlay these files?
you also need to fix firmware-imx recipe to not provide these files in similar ways.
Any advice appreciated.
Regards, Ryan.
OpenEmbedded mailing list OpenEmbedded@lists.linaro.org https://lists.linaro.org/mailman/listinfo/openembedded
On Wed, Nov 29, 2017 at 8:36 AM, Ryan Harkin ryan.harkin@linaro.org wrote:
Hello,
I am seeing this error in my build:
Configuring aCollected errors:
- check_data_file_clashes: Package linux-firmware-bcm43430 wants to install
file /linaro/mbl/workspace-arm/build-mbl/tmp-mbl-glibc/work/imx7s_warp-oe-linux-gnueabi/mbl-console-image-test/1.0-r0/rootfs/lib/firmware/brcm/brcmfmac43430-sdio.bin But that file is already provided by package * firmware-imx
- check_data_file_clashes: Package linux-firmware-bcm43430 wants to install
file /linaro/mbl/workspace-arm/build-mbl/tmp-mbl-glibc/work/imx7s_warp-oe-linux-gnueabi/mbl-console-image-test/1.0-r0/rootfs/lib/firmware/brcm/brcmfmac43430-sdio.txt But that file is already provided by package * firmware-imx
as the error message says it, 1 file in the root file system has to be installed by 1 package, and only one. The process of building an image with OE/bitbake is:
1. determine the list of all packages be installed. This is done by looking at all RDEPENDS for the 'image' you are building. 2. build all recipes that are needed by the image (and all their dependencies) 3. install all binary packages that were just built in #2 into a 'local root filesystem' 4. create an 'image' file (ext4, sd card, ...) from the rootfs in #3
#3 is basically just 'uncompressing' binary packages into a folder. So if 2 packages try to install the same file, it will fail and abort , like in your case. 1 file in the resulting rootfs belongs to 1 binary package.
In my build, I'm including meta-raspberrypi and meta-freescale-3rdparty in my manifest. These two meta layers include the following two files into the rootfs in various ways:
/lib/firmware/brcm/brcmfmac43430-sdio.txt /lib/firmware/brcm/brcmfmac43430-sdio.bin
For example, in the following files define a way of adding the firmware into the rootfs (there will be more ways they get into the build, saying as one is a .inc file):
meta-freescale-3rdparty/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config.inc meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware_%.bbappend openembedded-core/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
My meta-layer is included after meta-freescale* and meta-raspberrypi, but before openembedded-core/meta in my BBLAYERS setup.
Order/priority won't matter here. if 1 file is to be found in 2 *different* packages, then installing these 2 packages into the same image will fail.
However, I want to provide a newer version of these two files in my build. So we created this recipe in our meta layer:
file: recipes-bsp/firmware-imx/firmware-imx_%.bbappend
SRCREV_linuxfirmware = "a61ac5cf8374edbfe692d12f805a1b194f7fead2" SRCREV_recalboxbuildroot = "f648e4b54eb5e4be593746d6cc51375b22a7efbd"
SRC_URI += "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;branch=${SRCBRANCH};destsuffix=${S}/git1;name=linuxfirmware \ git://github.com/recalbox/recalbox-buildroot.git;protocol=https;branch=${SRCBRANCH};destsuffix=${S}/git2;name=recalboxbuildroot " LIC_FILES_CHKSUM += "file://git1/LICENCE.broadcom_bcm43xx;md5=3160c14df7228891b868060e1951dfbc \ file://git2/COPYING;md5=e4edbc78b8892db416b6a07e0d97309a "
do_install_append() { install -d ${D}${base_libdir}/firmware install -d ${D}${base_libdir}/firmware/brcm
cp -rfv git1/brcm/brcmfmac43430-sdio.bin${D}${base_libdir}/firmware/brcm cp -rfv git2/board/warp7/rootfs_overlay/lib/firmware/brcm/brcmfmac43430-sdio.txt ${D}${base_libdir}/firmware/brcm }
FILES_${PN} += "${base_libdir}/firmware/brcm/brcmfmac43430*"
COMPATIBLE_MACHINE = "(imx7s-warp)"
I am not familiar with the layers you are using, but I think that a bbappend for linux-firmware like they do in meta-rpi would be more appropriate. e.g. you would modify an existing package instead of making a new one.
It builds fine in a "normal" configuration. However, in a "test" build, where "dev-pkgs" is added to IMAGE_FEATURES, I get the error as above.
It probably means that linux-firmware is not included by default, and gets pulled in when you include dev-pkgs feature.
So how do I work around this issue? Am I doing the wrong thing by providing a bbappend to overlay these files?
Any advice appreciated.
Regards, Ryan.
OpenEmbedded mailing list OpenEmbedded@lists.linaro.org https://lists.linaro.org/mailman/listinfo/openembedded
On 29 November 2017 at 07:54, Nicolas Dechesne nicolas.dechesne@linaro.org wrote:
On Wed, Nov 29, 2017 at 8:36 AM, Ryan Harkin ryan.harkin@linaro.org wrote:
Hello,
I am seeing this error in my build:
Configuring aCollected errors:
- check_data_file_clashes: Package linux-firmware-bcm43430 wants to
install
file /linaro/mbl/workspace-arm/build-mbl/tmp-mbl-glibc/work/
imx7s_warp-oe-linux-gnueabi/mbl-console-image-test/1.0-r0/ rootfs/lib/firmware/brcm/brcmfmac43430-sdio.bin
But that file is already provided by package * firmware-imx
- check_data_file_clashes: Package linux-firmware-bcm43430 wants to
install
file /linaro/mbl/workspace-arm/build-mbl/tmp-mbl-glibc/work/
imx7s_warp-oe-linux-gnueabi/mbl-console-image-test/1.0-r0/ rootfs/lib/firmware/brcm/brcmfmac43430-sdio.txt
But that file is already provided by package * firmware-imx
as the error message says it, 1 file in the root file system has to be installed by 1 package, and only one. The process of building an image with OE/bitbake is:
- determine the list of all packages be installed. This is done by
looking at all RDEPENDS for the 'image' you are building. 2. build all recipes that are needed by the image (and all their dependencies) 3. install all binary packages that were just built in #2 into a 'local root filesystem' 4. create an 'image' file (ext4, sd card, ...) from the rootfs in #3
#3 is basically just 'uncompressing' binary packages into a folder. So if 2 packages try to install the same file, it will fail and abort , like in your case. 1 file in the resulting rootfs belongs to 1 binary package.
In my build, I'm including meta-raspberrypi and meta-freescale-3rdparty
in
my manifest. These two meta layers include the following two files into
the
rootfs in various ways:
/lib/firmware/brcm/brcmfmac43430-sdio.txt /lib/firmware/brcm/brcmfmac43430-sdio.bin
For example, in the following files define a way of adding the firmware
into
the rootfs (there will be more ways they get into the build, saying as
one
is a .inc file):
meta-freescale-3rdparty/recipes-bsp/broadcom-nvram-
config/broadcom-nvram-config.inc
meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware_%.bbappend openembedded-core/meta/recipes-kernel/linux-firmware/
linux-firmware_git.bb
My meta-layer is included after meta-freescale* and meta-raspberrypi, but before openembedded-core/meta in my BBLAYERS setup.
Order/priority won't matter here. if 1 file is to be found in 2 *different* packages, then installing these 2 packages into the same image will fail.
However, I want to provide a newer version of these two files in my
build.
So we created this recipe in our meta layer:
file: recipes-bsp/firmware-imx/firmware-imx_%.bbappend
SRCREV_linuxfirmware = "a61ac5cf8374edbfe692d12f805a1b194f7fead2" SRCREV_recalboxbuildroot = "f648e4b54eb5e4be593746d6cc51375b22a7efbd"
SRC_URI += "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/
linux-firmware.git;branch=${SRCBRANCH};destsuffix=${S}/ git1;name=linuxfirmware
\ git://github.com/recalbox/recalbox-buildroot.git;
protocol=https;branch=${SRCBRANCH};destsuffix=${S}/ git2;name=recalboxbuildroot
" LIC_FILES_CHKSUM += "file://git1/LICENCE.broadcom_bcm43xx;md5=3160c14df7228891b868060e1951dfbc
\
file://git2/COPYING;md5=e4edbc78b8892db416b6a07e0d97309a
"
do_install_append() { install -d ${D}${base_libdir}/firmware install -d ${D}${base_libdir}/firmware/brcm
cp -rfv git1/brcm/brcmfmac43430-sdio.bin${D}${base_libdir}/firmware/brcm cp -rfv git2/board/warp7/rootfs_overlay/lib/firmware/brcm/brcmfmac43430-sdio.txt ${D}${base_libdir}/firmware/brcm }
FILES_${PN} += "${base_libdir}/firmware/brcm/brcmfmac43430*"
COMPATIBLE_MACHINE = "(imx7s-warp)"
I am not familiar with the layers you are using, but I think that a bbappend for linux-firmware like they do in meta-rpi would be more appropriate. e.g. you would modify an existing package instead of making a new one.
Well, that's what I'm trying to do - to overlay the recipe that provides the firmware and provide a newer version of the same firmware. Perhaps I'm overlaying the wrong recipe?
The error implies that instead of overlaying "firmware-imx", I should be overlaying "linux-firmware-bcm43430" , but I can't find a package of that name in my workspace. But I suspect that the package name in the error comes from the FILES_${PN}-bcm43430 entry in another bbappend.
It builds fine in a "normal" configuration. However, in a "test" build, where "dev-pkgs" is added to IMAGE_FEATURES, I get the error as above.
It probably means that linux-firmware is not included by default, and gets pulled in when you include dev-pkgs feature.
So how do I work around this issue? Am I doing the wrong thing by
providing
a bbappend to overlay these files?
Any advice appreciated.
Regards, Ryan.
OpenEmbedded mailing list OpenEmbedded@lists.linaro.org https://lists.linaro.org/mailman/listinfo/openembedded
Op 29 nov. 2017, om 09:56 heeft Ryan Harkin ryan.harkin@linaro.org het volgende geschreven:
[..]
The error implies that instead of overlaying "firmware-imx", I should be overlaying "linux-firmware-bcm43430" , but I can't find a package of that name in my workspace. But I suspect that the package name in the error comes from the FILES_${PN}-bcm43430 entry in another bbappend.
It is most likely a subpackage of the linux-firmare recipe.
regards,
Koen
Hi all,
An update for those interested:
brcmfmac43430-sdio.bin is provided by: openembedded-core/meta/recipes-kernel/linux-firmware/ linux-firmware_git.bb:530:
brcmfmac43430-sdio.txt is provided by: recipes-kernel/linux-firmware/.linux-firmware_%.bbappend.swp
So I renamed my bbappend to match the file in meta-raspberry-pi. And these are the contents:
-------------------------------------------------------------------------------- SRCREV_linuxfirmware = "a61ac5cf8374edbfe692d12f805a1b194f7fead2" SRCREV_recalboxbuildroot = "f648e4b54eb5e4be593746d6cc51375b22a7efbd"
SRC_URI += "git:// git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;nobranch=1;destsuffix=${S}/git1;name=linuxfirmware \ git:// github.com/recalbox/recalbox-buildroot.git;protocol=https;nobranch=1;destsuffix=${S}/git2;name=recalboxbuildroot " LIC_FILES_CHKSUM += "file://git1/LICENCE.broadcom_bcm43xx;md5=3160c14df7228891b868060e1951dfbc \
file://git2/COPYING;md5=e4edbc78b8892db416b6a07e0d97309a "
do_install_append() { install -d ${D}${base_libdir}/firmware install -d ${D}${base_libdir}/firmware/brcm
cp -rfv git1/brcm/brcmfmac43430-sdio.bin ${D}${base_libdir}/firmware/brcm cp -rfv git2/board/warp7/rootfs_overlay/lib/firmware/brcm/brcmfmac43430-sdio.txt ${D}${base_libdir}/firmware/brcm }
FILES_${PN}-bcm43430 += " \ ${base_libdir}/firmware/brcm/brcmfmac43430-sdio.bin \ ${base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt \ " --------------------------------------------------------------------------------
But that errors out with this garbles mess:
-------------------------------------------------------------------------------- ERROR: ExpansionError during parsing /linaro/mbl/workspace-arm/build-mbl/conf/../../layers/openembedded-core/meta/recipes-kernel/linux-firmware/ linux-firmware_git.bb Traceback (most recent call last): File "/linaro/mbl/workspace-arm/bitbake/lib/bb/data_smart.py", line 412, in DataSmart.expandWithRefs(s='0.0+git${SRCPV}', varname='PV'): try: > s = __expand_var_regexp__.sub(varparse.var_sub, s) try: File "/linaro/mbl/workspace-arm/bitbake/lib/bb/data_smart.py", line 111, in VariableParse.var_sub(match=<_sre.SRE_Match object; span=(7, 15), match='${SRCPV}'>): else: > var = self.d.getVarFlag(key, "_content") self.references.add(key) File "/linaro/mbl/workspace-arm/bitbake/lib/bb/data_smart.py", line 794, in DataSmart.getVarFlag(var='SRCPV', flag='_content', expand=True, noweakdefault=False, parsing=False): cachename = var + "[" + flag + "]" > value = self.expand(value, cachename)
File "/linaro/mbl/workspace-arm/bitbake/lib/bb/data_smart.py", line 436, in DataSmart.expand(s='${@bb.fetch2.get_srcrev(d)}', varname='SRCPV'): def expand(self, s, varname = None): > return self.expandWithRefs(s, varname).value
File "/linaro/mbl/workspace-arm/bitbake/lib/bb/data_smart.py", line 426, in DataSmart.expandWithRefs(s='${@bb.fetch2.get_srcrev(d)}', varname='SRCPV'): except Exception as exc: > raise ExpansionError(varname, s, exc) from exc
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception RecursionError: maximum recursion depth exceeded --------------------------------------------------------------------------------
I'm guessing t's really not happy about me providing a git repo and messing up its refs.
So, just to test things, I hacked my recipe to match the RPi one and copied the files I want locally into a "files" subdir. My recipe now looks like this:
-------------------------------------------------------------------------------- SRC_URI += " \ file://brcmfmac43430-sdio.bin \ file://brcmfmac43430-sdio.txt \ " do_install_append() { install -d ${D}${base_libdir}/firmware install -d ${D}${base_libdir}/firmware/brcm
install -m 0644 $_firmware ${WORKDIR}/brcmfmac43430-sdio.bin ${D}${base_libdir}/firmware/brcm install -m 0644 $_firmware ${WORKDIR}/brcmfmac43430-sdio.txt ${D}${base_libdir}/firmware/brcm }
FILES_${PN}-bcm43430 += " \ ${base_libdir}/firmware/brcm/brcmfmac43430-sdio.bin \ ${base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt \ " --------------------------------------------------------------------------------
It gives me this warning from meta-raspberrypi's linux-firmware_%.bbappend:
WARNING: linux-firmware-1_0.0+gitAUTOINC+bf04291309-r0 do_install: linux-firmware stopped providing brcmfmac43430 v7.45.41.26.
... but otherwise, it build. However, I still end up with the files from meta-raspberrypi in the build. So I guess that was a pointless exercise.
Cheers., Ryan.
On 29 November 2017 at 09:07, Koen Kooi koen.kooi@linaro.org wrote:
Op 29 nov. 2017, om 09:56 heeft Ryan Harkin ryan.harkin@linaro.org
het volgende geschreven:
[..]
The error implies that instead of overlaying "firmware-imx", I should be
overlaying "linux-firmware-bcm43430" , but I can't find a package of that name in my workspace. But I suspect that the package name in the error comes from the FILES_${PN}-bcm43430 entry in another bbappend.
It is most likely a subpackage of the linux-firmare recipe.
regards,
Koen
On 29 November 2017 at 14:32, Ryan Harkin ryan.harkin@linaro.org wrote:
Hi all,
An update for those interested:
brcmfmac43430-sdio.bin is provided by: openembedded-core/meta/recipes-kernel/linux-firmware/ linux-firmware_git.bb:530:
Sorry, my mistake. This is also provided by meta-raspberrypi.
brcmfmac43430-sdio.txt is provided by: recipes-kernel/linux-firmware/.linux-firmware_%.bbappend.swp
So I renamed my bbappend to match the file in meta-raspberry-pi. And these are the contents:
SRCREV_linuxfirmware = "a61ac5cf8374edbfe692d12f805a1b194f7fead2" SRCREV_recalboxbuildroot = "f648e4b54eb5e4be593746d6cc51375b22a7efbd"
SRC_URI += "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/ linux-firmware.git;nobranch=1;destsuffix=${S}/git1;name=linuxfirmware http://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;nobranch=1;destsuffix=$%7BS%7D/git1;name=linuxfirmware \ git://github.com/recalbox/recalbox-buildroot.git; protocol=https;nobranch=1;destsuffix=${S}/git2;name=recalboxbuildroot http://github.com/recalbox/recalbox-buildroot.git;protocol=https;nobranch=1;destsuffix=$%7BS%7D/git2;name=recalboxbuildroot " LIC_FILES_CHKSUM += "file://git1/LICENCE.broadcom_bcm43xx;md5= 3160c14df7228891b868060e1951dfbc \ file://git2/COPYING;md5= e4edbc78b8892db416b6a07e0d97309a "
do_install_append() { install -d ${D}${base_libdir}/firmware install -d ${D}${base_libdir}/firmware/brcm
cp -rfv git1/brcm/brcmfmac43430-sdio.bin ${D}${base_libdir}/firmware/brcm cp -rfv git2/board/warp7/rootfs_overlay/lib/firmware/brcm/brcmfmac43430-sdio.txt ${D}${base_libdir}/firmware/brcm }
FILES_${PN}-bcm43430 += " \ ${base_libdir}/firmware/brcm/brcmfmac43430-sdio.bin \ ${base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt \ "
But that errors out with this garbles mess:
ERROR: ExpansionError during parsing /linaro/mbl/workspace-arm/ build-mbl/conf/../../layers/openembedded-core/meta/ recipes-kernel/linux-firmware/linux-firmware_git.bb Traceback (most recent call last): File "/linaro/mbl/workspace-arm/bitbake/lib/bb/data_smart.py", line 412, in DataSmart.expandWithRefs(s='0.0+git${SRCPV}', varname='PV'): try: > s = __expand_var_regexp__.sub(varparse.var_sub, s) try: File "/linaro/mbl/workspace-arm/bitbake/lib/bb/data_smart.py", line 111, in VariableParse.var_sub(match=<_sre.SRE_Match object; span=(7, 15), match='${SRCPV}'>): else: > var = self.d.getVarFlag(key, "_content") self.references.add(key) File "/linaro/mbl/workspace-arm/bitbake/lib/bb/data_smart.py", line 794, in DataSmart.getVarFlag(var='SRCPV', flag='_content', expand=True, noweakdefault=False, parsing=False): cachename = var + "[" + flag + "]" > value = self.expand(value, cachename)
File "/linaro/mbl/workspace-arm/bitbake/lib/bb/data_smart.py", line 436, in DataSmart.expand(s='${@bb.fetch2.get_srcrev(d)}', varname='SRCPV'): def expand(self, s, varname = None): > return self.expandWithRefs(s, varname).value
File "/linaro/mbl/workspace-arm/bitbake/lib/bb/data_smart.py", line 426, in DataSmart.expandWithRefs(s='${@bb.fetch2.get_srcrev(d)}', varname='SRCPV'): except Exception as exc: > raise ExpansionError(varname, s, exc) from exc
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception RecursionError: maximum recursion depth exceeded
I'm guessing t's really not happy about me providing a git repo and messing up its refs.
So, just to test things, I hacked my recipe to match the RPi one and copied the files I want locally into a "files" subdir. My recipe now looks like this:
SRC_URI += " \ file://brcmfmac43430-sdio.bin \ file://brcmfmac43430-sdio.txt \ " do_install_append() { install -d ${D}${base_libdir}/firmware install -d ${D}${base_libdir}/firmware/brcm
install -m 0644 $_firmware ${WORKDIR}/brcmfmac43430-sdio.bin${D}${base_libdir}/firmware/brcm install -m 0644 $_firmware ${WORKDIR}/brcmfmac43430-sdio.txt ${D}${base_libdir}/firmware/brcm }
FILES_${PN}-bcm43430 += " \ ${base_libdir}/firmware/brcm/brcmfmac43430-sdio.bin \ ${base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt \ "
It gives me this warning from meta-raspberrypi's linux-firmware_%.bbappend:
WARNING: linux-firmware-1_0.0+gitAUTOINC+bf04291309-r0 do_install: linux-firmware stopped providing brcmfmac43430 v7.45.41.26.
... but otherwise, it build. However, I still end up with the files from meta-raspberrypi in the build. So I guess that was a pointless exercise.
Cheers., Ryan.
On 29 November 2017 at 09:07, Koen Kooi koen.kooi@linaro.org wrote:
Op 29 nov. 2017, om 09:56 heeft Ryan Harkin ryan.harkin@linaro.org
het volgende geschreven:
[..]
The error implies that instead of overlaying "firmware-imx", I should
be overlaying "linux-firmware-bcm43430" , but I can't find a package of that name in my workspace. But I suspect that the package name in the error comes from the FILES_${PN}-bcm43430 entry in another bbappend.
It is most likely a subpackage of the linux-firmare recipe.
regards,
Koen
Op 29 nov. 2017, om 15:32 heeft Ryan Harkin ryan.harkin@linaro.org het volgende geschreven:
Hi all,
An update for those interested:
brcmfmac43430-sdio.bin is provided by: openembedded-core/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb:530:
brcmfmac43430-sdio.txt is provided by: recipes-kernel/linux-firmware/.linux-firmware_%.bbappend.swp
So I renamed my bbappend to match the file in meta-raspberry-pi. And these are the contents:
SRCREV_linuxfirmware = "a61ac5cf8374edbfe692d12f805a1b194f7fead2" SRCREV_recalboxbuildroot = "f648e4b54eb5e4be593746d6cc51375b22a7efbd"
SRC_URI += "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;nobranch=1;destsuffix=${S}/git1;name=linuxfirmware \ git://github.com/recalbox/recalbox-buildroot.git;protocol=https;nobranch=1;destsuffix=${S}/git2;name=recalboxbuildroot “
I think this will expand to:
git://uri-in-recipe.git \ git://uri-in-bbappend.git \ git://github-uri-in-bbappend.git \
And since SRCPV is used in the recipe, you’ll need to set SRCREV_FORMAT (I forget the actual variable name) to tell bitbake which repo to base SRCPV on.
regards,
Koen
Here's another question:
When I build for MACHINE=imx7s-warp, should meta-raspberrypi's linux-firmware recipe be running or not? Is there something in meta-raspberrypi that makes it only run on MACHINE=raspberrypi?
In an OE-RPB based build, it doesn't run. I put a bbwarn statement into the bbappend file's do_install and it didn't output anything.
But when I run it in the "other" distro, meta-raspberrypi's linux-firmware_%.bbappend is running during a warp7 build and outputting the bbwarn from meta-raspberrypi.
Is this expected?
On 29 November 2017 at 15:28, Koen Kooi koen.kooi@linaro.org wrote:
Op 29 nov. 2017, om 15:32 heeft Ryan Harkin ryan.harkin@linaro.org het volgende geschreven:
Hi all,
An update for those interested:
brcmfmac43430-sdio.bin is provided by: openembedded-core/meta/recipes-kernel/linux-firmware/linux-
firmware_git.bb:530:
brcmfmac43430-sdio.txt is provided by: recipes-kernel/linux-firmware/.linux-firmware_%.bbappend.swp
So I renamed my bbappend to match the file in meta-raspberry-pi. And
these are the contents:
SRCREV_linuxfirmware = "a61ac5cf8374edbfe692d12f805a1b194f7fead2" SRCREV_recalboxbuildroot = "f648e4b54eb5e4be593746d6cc51375b22a7efbd"
SRC_URI += "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linu
x-firmware.git;nobranch=1;destsuffix=${S}/git1;name=linuxfirmware http://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;nobranch=1;destsuffix=$%7BS%7D/git1;name=linuxfirmware \
git://github.com/recalbox/recalbox-buildroot.git;protocol=https;nobranch=1;destsuffix=${S}/git2;name=recalboxbuildroot http://github.com/recalbox/recalbox-buildroot.git;protocol=https;nobranch=1;destsuffix=$%7BS%7D/git2;name=recalboxbuildroot “
I think this will expand to:
git://uri-in-recipe.git \ git://uri-in-bbappend.git \ git://github-uri-in-bbappend.git \
And since SRCPV is used in the recipe, you’ll need to set SRCREV_FORMAT (I forget the actual variable name) to tell bitbake which repo to base SRCPV on.
Thanks, I'll try and work out what that variable is and how to use it.
For now, I've copied the meta-raspberrypi method and cached the files locally. I'm not sure if that is better or worse.
Cheers, Ryan.
regards,
Koen
Op 30 nov. 2017, om 09:26 heeft Ryan Harkin ryan.harkin@linaro.org het volgende geschreven:
Here's another question:
When I build for MACHINE=imx7s-warp, should meta-raspberrypi's linux-firmware recipe be running or not? Is there something in meta-raspberrypi that makes it only run on MACHINE=raspberrypi?
Looking at https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-kernel/linu... it should be included
In an OE-RPB based build, it doesn't run. I put a bbwarn statement into the bbappend file's do_install and it didn't output anything.
But when I run it in the "other" distro, meta-raspberrypi's linux-firmware_%.bbappend is running during a warp7 build and outputting the bbwarn from meta-raspberrypi.
Is this expected?
It depends on the order and content of the other linux-firmware bbappend files, if one that sorts higher does:
do_install() { something }
all the lower sorted appends will not get their do_install_append in.
Anyway, try doing ‘bitbake -e linux-firmware > firmware-e.txt’ and inspecting the result, that should list the overrides and their order for every variable and method.
regards,
Koen
On 29 November 2017 at 15:28, Koen Kooi koen.kooi@linaro.org wrote: Op 29 nov. 2017, om 15:32 heeft Ryan Harkin ryan.harkin@linaro.org het volgende geschreven:
Hi all,
An update for those interested:
brcmfmac43430-sdio.bin is provided by: openembedded-core/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb:530:
brcmfmac43430-sdio.txt is provided by: recipes-kernel/linux-firmware/.linux-firmware_%.bbappend.swp
So I renamed my bbappend to match the file in meta-raspberry-pi. And these are the contents:
SRCREV_linuxfirmware = "a61ac5cf8374edbfe692d12f805a1b194f7fead2" SRCREV_recalboxbuildroot = "f648e4b54eb5e4be593746d6cc51375b22a7efbd"
SRC_URI += "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;nobranch=1;destsuffix=${S}/git1;name=linuxfirmware \ git://github.com/recalbox/recalbox-buildroot.git;protocol=https;nobranch=1;destsuffix=${S}/git2;name=recalboxbuildroot “
I think this will expand to:
git://uri-in-recipe.git \ git://uri-in-bbappend.git \ git://github-uri-in-bbappend.git \
And since SRCPV is used in the recipe, you’ll need to set SRCREV_FORMAT (I forget the actual variable name) to tell bitbake which repo to base SRCPV on.
Thanks, I'll try and work out what that variable is and how to use it.
For now, I've copied the meta-raspberrypi method and cached the files locally. I'm not sure if that is better or worse.
Cheers, Ryan.
regards,
Koen
On 30 November 2017 at 08:34, Koen Kooi koen.kooi@linaro.org wrote:
Op 30 nov. 2017, om 09:26 heeft Ryan Harkin ryan.harkin@linaro.org het volgende geschreven:
Here's another question:
When I build for MACHINE=imx7s-warp, should meta-raspberrypi's
linux-firmware recipe be running or not? Is there something in meta-raspberrypi that makes it only run on MACHINE=raspberrypi?
Looking at https://github.com/agherzan/meta-raspberrypi/blob/master/ recipes-kernel/linux-firmware/linux-firmware_%25.bbappend it should be included
In an OE-RPB based build, it doesn't run. I put a bbwarn statement into
the bbappend file's do_install and it didn't output anything.
But when I run it in the "other" distro, meta-raspberrypi's
linux-firmware_%.bbappend is running during a warp7 build and outputting the bbwarn from meta-raspberrypi.
Is this expected?
It depends on the order and content of the other linux-firmware bbappend files, if one that sorts higher does:
do_install() { something }
all the lower sorted appends will not get their do_install_append in.
Anyway, try doing ‘bitbake -e linux-firmware > firmware-e.txt’ and inspecting the result, that should list the overrides and their order for every variable and method.
OK, thanks for that top tip.
So rpi and warp7 are both being included in the final do_install function in both OE-RPB and my other distro.
Why I didn't see the bbwarn from meta-raspberrypi on OE-RPB is a different matter, especially as I'm no longer seeing either bbwarn when I build right now.
But because the rpi layer is included in the manifest after/later than my layer, the rpi do_install appended commands run after the warp7 ones, so there's no way I'll ever get my firmware into the disk image with this mechanism.
regards,
Koen
On 29 November 2017 at 15:28, Koen Kooi koen.kooi@linaro.org wrote: Op 29 nov. 2017, om 15:32 heeft Ryan Harkin ryan.harkin@linaro.org
het volgende geschreven:
Hi all,
An update for those interested:
brcmfmac43430-sdio.bin is provided by: openembedded-core/meta/recipes-kernel/linux-firmware/
linux-firmware_git.bb:530:
brcmfmac43430-sdio.txt is provided by: recipes-kernel/linux-firmware/.linux-firmware_%.bbappend.swp
So I renamed my bbappend to match the file in meta-raspberry-pi. And
these are the contents:
SRCREV_linuxfirmware = "a61ac5cf8374edbfe692d12f805a1b194f7fead2" SRCREV_recalboxbuildroot = "f648e4b54eb5e4be593746d6cc51375b22a7efbd"
SRC_URI += "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/
linux-firmware.git;nobranch=1;destsuffix=${S}/git1;name=linuxfirmware \
git://github.com/recalbox/recalbox-buildroot.git;protocol=https;nobranch=1;destsuffix=${S}/git2;name=recalboxbuildroot “
I think this will expand to:
git://uri-in-recipe.git \ git://uri-in-bbappend.git \ git://github-uri-in-bbappend.git \
And since SRCPV is used in the recipe, you’ll need to set SRCREV_FORMAT
(I forget the actual variable name) to tell bitbake which repo to base SRCPV on.
Thanks, I'll try and work out what that variable is and how to use it.
For now, I've copied the meta-raspberrypi method and cached the files
locally. I'm not sure if that is better or worse.
Cheers, Ryan.
regards,
Koen
Op 30 nov. 2017, om 10:08 heeft Ryan Harkin ryan.harkin@linaro.org het volgende geschreven:
On 30 November 2017 at 08:34, Koen Kooi koen.kooi@linaro.org wrote: Op 30 nov. 2017, om 09:26 heeft Ryan Harkin ryan.harkin@linaro.org het volgende geschreven:
Here's another question:
When I build for MACHINE=imx7s-warp, should meta-raspberrypi's linux-firmware recipe be running or not? Is there something in meta-raspberrypi that makes it only run on MACHINE=raspberrypi?
Looking at https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-kernel/linu... it should be included
In an OE-RPB based build, it doesn't run. I put a bbwarn statement into the bbappend file's do_install and it didn't output anything.
But when I run it in the "other" distro, meta-raspberrypi's linux-firmware_%.bbappend is running during a warp7 build and outputting the bbwarn from meta-raspberrypi.
Is this expected?
It depends on the order and content of the other linux-firmware bbappend files, if one that sorts higher does:
do_install() { something }
all the lower sorted appends will not get their do_install_append in.
Anyway, try doing ‘bitbake -e linux-firmware > firmware-e.txt’ and inspecting the result, that should list the overrides and their order for every variable and method.
OK, thanks for that top tip.
So rpi and warp7 are both being included in the final do_install function in both OE-RPB and my other distro.
Why I didn't see the bbwarn from meta-raspberrypi on OE-RPB is a different matter, especially as I'm no longer seeing either bbwarn when I build right now.
Code in methods only gets executed when that method runs and *doesn’t* run if bitbake uses sstate to restore it. So you might not see it due to caching working as intended.
But because the rpi layer is included in the manifest after/later than my layer, the rpi do_install appended commands run after the warp7 ones, so there's no way I'll ever get my firmware into the disk image with this mechanism.
Both appends touch the same file(s)?
regards,
Koen
regards,
Koen
On 29 November 2017 at 15:28, Koen Kooi koen.kooi@linaro.org wrote: Op 29 nov. 2017, om 15:32 heeft Ryan Harkin ryan.harkin@linaro.org het volgende geschreven:
Hi all,
An update for those interested:
brcmfmac43430-sdio.bin is provided by: openembedded-core/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb:530:
brcmfmac43430-sdio.txt is provided by: recipes-kernel/linux-firmware/.linux-firmware_%.bbappend.swp
So I renamed my bbappend to match the file in meta-raspberry-pi. And these are the contents:
SRCREV_linuxfirmware = "a61ac5cf8374edbfe692d12f805a1b194f7fead2" SRCREV_recalboxbuildroot = "f648e4b54eb5e4be593746d6cc51375b22a7efbd"
SRC_URI += "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;nobranch=1;destsuffix=${S}/git1;name=linuxfirmware \ git://github.com/recalbox/recalbox-buildroot.git;protocol=https;nobranch=1;destsuffix=${S}/git2;name=recalboxbuildroot “
I think this will expand to:
git://uri-in-recipe.git \ git://uri-in-bbappend.git \ git://github-uri-in-bbappend.git \
And since SRCPV is used in the recipe, you’ll need to set SRCREV_FORMAT (I forget the actual variable name) to tell bitbake which repo to base SRCPV on.
Thanks, I'll try and work out what that variable is and how to use it.
For now, I've copied the meta-raspberrypi method and cached the files locally. I'm not sure if that is better or worse.
Cheers, Ryan.
regards,
Koen
On 30 November 2017 at 09:18, Koen Kooi koen.kooi@linaro.org wrote:
Op 30 nov. 2017, om 10:08 heeft Ryan Harkin ryan.harkin@linaro.org
het volgende geschreven:
On 30 November 2017 at 08:34, Koen Kooi koen.kooi@linaro.org wrote: Op 30 nov. 2017, om 09:26 heeft Ryan Harkin ryan.harkin@linaro.org
het volgende geschreven:
Here's another question:
When I build for MACHINE=imx7s-warp, should meta-raspberrypi's
linux-firmware recipe be running or not? Is there something in meta-raspberrypi that makes it only run on MACHINE=raspberrypi?
Looking at https://github.com/agherzan/meta-raspberrypi/blob/master/
recipes-kernel/linux-firmware/linux-firmware_%25.bbappend it should be included
In an OE-RPB based build, it doesn't run. I put a bbwarn statement
into the bbappend file's do_install and it didn't output anything.
But when I run it in the "other" distro, meta-raspberrypi's
linux-firmware_%.bbappend is running during a warp7 build and outputting the bbwarn from meta-raspberrypi.
Is this expected?
It depends on the order and content of the other linux-firmware bbappend
files, if one that sorts higher does:
do_install() { something }
all the lower sorted appends will not get their do_install_append in.
Anyway, try doing ‘bitbake -e linux-firmware > firmware-e.txt’ and
inspecting the result, that should list the overrides and their order for every variable and method.
OK, thanks for that top tip.
So rpi and warp7 are both being included in the final do_install
function in both OE-RPB and my other distro.
Why I didn't see the bbwarn from meta-raspberrypi on OE-RPB is a
different matter, especially as I'm no longer seeing either bbwarn when I build right now.
Code in methods only gets executed when that method runs and *doesn’t* run if bitbake uses sstate to restore it. So you might not see it due to caching working as intended.
Yes, I tried unsuccessfully to clean, I guess...
Eg: bitbake -c do_cleanall linux-firmware
But because the rpi layer is included in the manifest after/later than
my layer, the rpi do_install appended commands run after the warp7 ones, so there's no way I'll ever get my firmware into the disk image with this mechanism.
Both appends touch the same file(s)?
Yes, identical filenames and locations, but different versions.
:-(
regards,
Koen
regards,
Koen
On 29 November 2017 at 15:28, Koen Kooi koen.kooi@linaro.org wrote: Op 29 nov. 2017, om 15:32 heeft Ryan Harkin ryan.harkin@linaro.org
het volgende geschreven:
Hi all,
An update for those interested:
brcmfmac43430-sdio.bin is provided by: openembedded-core/meta/recipes-kernel/linux-firmware/
linux-firmware_git.bb:530:
brcmfmac43430-sdio.txt is provided by: recipes-kernel/linux-firmware/.linux-firmware_%.bbappend.swp
So I renamed my bbappend to match the file in meta-raspberry-pi. And
these are the contents:
SRCREV_linuxfirmware = "a61ac5cf8374edbfe692d12f805a1b194f7fead2" SRCREV_recalboxbuildroot = "f648e4b54eb5e4be593746d6cc5137
5b22a7efbd"
SRC_URI += "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/
linux-firmware.git;nobranch=1;destsuffix=${S}/git1;name=linuxfirmware \
git://github.com/recalbox/recalbox-buildroot.git;protocol=https;nobranch=1;destsuffix=${S}/git2;name=recalboxbuildroot “
I think this will expand to:
git://uri-in-recipe.git \ git://uri-in-bbappend.git \ git://github-uri-in-bbappend.git \
And since SRCPV is used in the recipe, you’ll need to set
SRCREV_FORMAT (I forget the actual variable name) to tell bitbake which repo to base SRCPV on.
Thanks, I'll try and work out what that variable is and how to use it.
For now, I've copied the meta-raspberrypi method and cached the files
locally. I'm not sure if that is better or worse.
Cheers, Ryan.
regards,
Koen
On 30 November 2017 at 09:31, Ryan Harkin ryan.harkin@linaro.org wrote:
On 30 November 2017 at 09:18, Koen Kooi koen.kooi@linaro.org wrote:
Op 30 nov. 2017, om 10:08 heeft Ryan Harkin ryan.harkin@linaro.org
het volgende geschreven:
On 30 November 2017 at 08:34, Koen Kooi koen.kooi@linaro.org wrote: Op 30 nov. 2017, om 09:26 heeft Ryan Harkin ryan.harkin@linaro.org
het volgende geschreven:
Here's another question:
When I build for MACHINE=imx7s-warp, should meta-raspberrypi's
linux-firmware recipe be running or not? Is there something in meta-raspberrypi that makes it only run on MACHINE=raspberrypi?
Looking at https://github.com/agherzan/meta-raspberrypi/blob/master/rec
ipes-kernel/linux-firmware/linux-firmware_%25.bbappend it should be included
In an OE-RPB based build, it doesn't run. I put a bbwarn statement
into the bbappend file's do_install and it didn't output anything.
But when I run it in the "other" distro, meta-raspberrypi's
linux-firmware_%.bbappend is running during a warp7 build and outputting the bbwarn from meta-raspberrypi.
Is this expected?
It depends on the order and content of the other linux-firmware
bbappend files, if one that sorts higher does:
do_install() { something }
all the lower sorted appends will not get their do_install_append in.
Anyway, try doing ‘bitbake -e linux-firmware > firmware-e.txt’ and
inspecting the result, that should list the overrides and their order for every variable and method.
OK, thanks for that top tip.
So rpi and warp7 are both being included in the final do_install
function in both OE-RPB and my other distro.
Why I didn't see the bbwarn from meta-raspberrypi on OE-RPB is a
different matter, especially as I'm no longer seeing either bbwarn when I build right now.
Code in methods only gets executed when that method runs and *doesn’t* run if bitbake uses sstate to restore it. So you might not see it due to caching working as intended.
Yes, I tried unsuccessfully to clean, I guess...
Eg: bitbake -c do_cleanall linux-firmware
But because the rpi layer is included in the manifest after/later than
my layer, the rpi do_install appended commands run after the warp7 ones, so there's no way I'll ever get my firmware into the disk image with this mechanism.
Both appends touch the same file(s)?
Yes, identical filenames and locations, but different versions.
:-(
I'm trying to work out what I can to here to stop WaRP7 linux-firmware_%.bbappend corrupting RPi3 and vice versa.
In my recipe, I can use do_install_append_imx7s-warp() to prevent it from including during an RPi build. But RPi will still trample over my WaRP7 build.
I could move my meta-layer to be higher than RPi's, but I don't think that's a good solution.
Would it be a good idea to submit a patch to meta-raspberrypi to change their do_install_append() to do_install_append_raspberrypi()?
(I assume the SRC_URI and other variables would need their machine tags added too).
I'll try to create a new clone of oe-rpb-manifest.xml and a fresh meta layer with only this recipe so I can isolate this problem and share it publicly.
regards,
Koen
regards,
Koen
On 29 November 2017 at 15:28, Koen Kooi koen.kooi@linaro.org wrote: Op 29 nov. 2017, om 15:32 heeft Ryan Harkin ryan.harkin@linaro.org
het volgende geschreven:
Hi all,
An update for those interested:
brcmfmac43430-sdio.bin is provided by: openembedded-core/meta/recipes-kernel/linux-firmware/linux-
firmware_git.bb:530:
brcmfmac43430-sdio.txt is provided by: recipes-kernel/linux-firmware/.linux-firmware_%.bbappend.swp
So I renamed my bbappend to match the file in meta-raspberry-pi.
And these are the contents:
SRCREV_linuxfirmware = "a61ac5cf8374edbfe692d12f805a1b194f7fead2" SRCREV_recalboxbuildroot = "f648e4b54eb5e4be593746d6cc513
75b22a7efbd"
SRC_URI += "git://git.kernel.org/pub/scm/
linux/kernel/git/firmware/linux-firmware.git;nobranch=1;dest suffix=${S}/git1;name=linuxfirmware http://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;nobranch=1;destsuffix=$%7BS%7D/git1;name=linuxfirmware \
git://github.com/recalbox/recalbox-buildroot.git;protocol=https;nobranch=1;destsuffix=${ S}/git2;name=recalboxbuildroot http://github.com/recalbox/recalbox-buildroot.git;protocol=https;nobranch=1;destsuffix=$%7BS%7D/git2;name=recalboxbuildroot “
I think this will expand to:
git://uri-in-recipe.git \ git://uri-in-bbappend.git \ git://github-uri-in-bbappend.git \
And since SRCPV is used in the recipe, you’ll need to set
SRCREV_FORMAT (I forget the actual variable name) to tell bitbake which repo to base SRCPV on.
Thanks, I'll try and work out what that variable is and how to use it.
For now, I've copied the meta-raspberrypi method and cached the files
locally. I'm not sure if that is better or worse.
Cheers, Ryan.
regards,
Koen
On Thu, Nov 30, 2017 at 2:53 AM, Ryan Harkin ryan.harkin@linaro.org wrote:
On 30 November 2017 at 09:31, Ryan Harkin ryan.harkin@linaro.org wrote:
On 30 November 2017 at 09:18, Koen Kooi koen.kooi@linaro.org wrote:
Op 30 nov. 2017, om 10:08 heeft Ryan Harkin ryan.harkin@linaro.org het volgende geschreven:
On 30 November 2017 at 08:34, Koen Kooi koen.kooi@linaro.org wrote: Op 30 nov. 2017, om 09:26 heeft Ryan Harkin ryan.harkin@linaro.org het volgende geschreven:
Here's another question:
When I build for MACHINE=imx7s-warp, should meta-raspberrypi's linux-firmware recipe be running or not? Is there something in meta-raspberrypi that makes it only run on MACHINE=raspberrypi?
Looking at https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-kernel/linu... it should be included
In an OE-RPB based build, it doesn't run. I put a bbwarn statement into the bbappend file's do_install and it didn't output anything.
But when I run it in the "other" distro, meta-raspberrypi's linux-firmware_%.bbappend is running during a warp7 build and outputting the bbwarn from meta-raspberrypi.
Is this expected?
It depends on the order and content of the other linux-firmware bbappend files, if one that sorts higher does:
do_install() { something }
all the lower sorted appends will not get their do_install_append in.
Anyway, try doing ‘bitbake -e linux-firmware > firmware-e.txt’ and inspecting the result, that should list the overrides and their order for every variable and method.
OK, thanks for that top tip.
So rpi and warp7 are both being included in the final do_install function in both OE-RPB and my other distro.
Why I didn't see the bbwarn from meta-raspberrypi on OE-RPB is a different matter, especially as I'm no longer seeing either bbwarn when I build right now.
Code in methods only gets executed when that method runs and *doesn’t* run if bitbake uses sstate to restore it. So you might not see it due to caching working as intended.
Yes, I tried unsuccessfully to clean, I guess...
Eg: bitbake -c do_cleanall linux-firmware
But because the rpi layer is included in the manifest after/later than my layer, the rpi do_install appended commands run after the warp7 ones, so there's no way I'll ever get my firmware into the disk image with this mechanism.
Both appends touch the same file(s)?
Yes, identical filenames and locations, but different versions.
:-(
I'm trying to work out what I can to here to stop WaRP7 linux-firmware_%.bbappend corrupting RPi3 and vice versa.
In my recipe, I can use do_install_append_imx7s-warp() to prevent it from including during an RPi build. But RPi will still trample over my WaRP7 build.
I could move my meta-layer to be higher than RPi's, but I don't think that's a good solution.
Would it be a good idea to submit a patch to meta-raspberrypi to change their do_install_append() to do_install_append_raspberrypi()?
I think yes you can. rpi layer is adding specific firmware and making it universally applicable, this is not multi-bsp friendly. So please turn that whole bbappend to act under _rpi override.
(I assume the SRC_URI and other variables would need their machine tags added too).
I'll try to create a new clone of oe-rpb-manifest.xml and a fresh meta layer with only this recipe so I can isolate this problem and share it publicly.
On 30 November 2017 at 16:54, Khem Raj raj.khem@gmail.com wrote:
On Thu, Nov 30, 2017 at 2:53 AM, Ryan Harkin ryan.harkin@linaro.org wrote:
On 30 November 2017 at 09:31, Ryan Harkin ryan.harkin@linaro.org
wrote:
On 30 November 2017 at 09:18, Koen Kooi koen.kooi@linaro.org wrote:
Op 30 nov. 2017, om 10:08 heeft Ryan Harkin ryan.harkin@linaro.org het volgende geschreven:
On 30 November 2017 at 08:34, Koen Kooi koen.kooi@linaro.org
wrote:
Op 30 nov. 2017, om 09:26 heeft Ryan Harkin ryan.harkin@linaro.org het volgende geschreven:
Here's another question:
When I build for MACHINE=imx7s-warp, should meta-raspberrypi's linux-firmware recipe be running or not? Is there something in meta-raspberrypi that makes it only run on MACHINE=raspberrypi?
Looking at https://github.com/agherzan/meta-raspberrypi/blob/master/
recipes-kernel/linux-firmware/linux-firmware_%25.bbappend
it should be included
In an OE-RPB based build, it doesn't run. I put a bbwarn statement into the bbappend file's do_install and it didn't output anything.
But when I run it in the "other" distro, meta-raspberrypi's linux-firmware_%.bbappend is running during a warp7 build and
outputting the
bbwarn from meta-raspberrypi.
Is this expected?
It depends on the order and content of the other linux-firmware bbappend files, if one that sorts higher does:
do_install() { something }
all the lower sorted appends will not get their do_install_append in.
Anyway, try doing ‘bitbake -e linux-firmware > firmware-e.txt’ and inspecting the result, that should list the overrides and their
order for
every variable and method.
OK, thanks for that top tip.
So rpi and warp7 are both being included in the final do_install function in both OE-RPB and my other distro.
Why I didn't see the bbwarn from meta-raspberrypi on OE-RPB is a different matter, especially as I'm no longer seeing either bbwarn
when I
build right now.
Code in methods only gets executed when that method runs and *doesn’t* run if bitbake uses sstate to restore it. So you might not see it due
to
caching working as intended.
Yes, I tried unsuccessfully to clean, I guess...
Eg: bitbake -c do_cleanall linux-firmware
But because the rpi layer is included in the manifest after/later
than
my layer, the rpi do_install appended commands run after the warp7
ones, so
there's no way I'll ever get my firmware into the disk image with
this
mechanism.
Both appends touch the same file(s)?
Yes, identical filenames and locations, but different versions.
:-(
I'm trying to work out what I can to here to stop WaRP7 linux-firmware_%.bbappend corrupting RPi3 and vice versa.
In my recipe, I can use do_install_append_imx7s-warp() to prevent it from including during an RPi build. But RPi will still trample over my WaRP7 build.
I could move my meta-layer to be higher than RPi's, but I don't think
that's
a good solution.
Would it be a good idea to submit a patch to meta-raspberrypi to change their do_install_append() to do_install_append_raspberrypi()?
I think yes you can. rpi layer is adding specific firmware and making it universally applicable, this is not multi-bsp friendly. So please turn that whole bbappend to act under _rpi override.
Thanks for the +1 on that.
However, I've just worked out that all of the firmware that RPi3's recipe is included is good for what I want to do on WaRP7:
- the BlueTooth firmware is exactly the same binary file - the WiFi firmware is a slightly newer version than I was using on WaRP7
And it all just works if I add this to my meta layer:
diff --git a/conf/machine/imx7s-warp-foo.conf b/conf/machine/imx7s-warp-foo.conf new file mode 100644 index 0000000..c822aa6 --- /dev/null +++ b/conf/machine/imx7s-warp-foo.conf @@ -0,0 +1,8 @@ +#@TYPE: Machine +#@NAME: NXP WaRP7 Development Board +#@DESCRIPTION: Machine configuration for the WaRP7 Zero board + +MACHINEOVERRIDES = "imx7s-warp:${MACHINE}" +include conf/machine/imx7s-warp.conf + +MACHINE_EXTRA_RRECOMMENDS += "linux-firmware-bcm43430"
So, in effect, I can use the RPi3 pollution of my rootfs to my advantage and move on until someone else fixes the problem.
(I assume the SRC_URI and other variables would need their machine tags added too).
I'll try to create a new clone of oe-rpb-manifest.xml and a fresh meta
layer
with only this recipe so I can isolate this problem and share it
publicly.
-
Khem Raj -
Koen Kooi -
Nicolas Dechesne -
Ryan Harkin