|
How to get firmware-imx for imx8mm evk into sdcard image? I'm getting firmware loading errors for sdma-imx7d.bin etc.
Brian Hutchinson
Just built latest Freescale Community BSP core-image-minimal (kernel 5.4.67 was built) for imx8mm-evk and firmware-imx is not included in sdcard image ... which I think is why I'm getting messages like these:
[ 0.127623] imx-sdma 302c0000.dma-controller: Direct firmware load for imx/sdma/sdma-imx7d.bin failed with error -2 [ 0.127636] imx-sdma 302c0000.dma-controller: Falling back to sysfs fallback for: imx/sdma/sdma-imx7d.bin [ 0.135771] mxs-dma 33000000.dma-controller: initialized [ 3.921734] cfg80211: failed to load regulatory.db [ 3.939089] imx-sdma 302b0000.dma-controller: external firmware not found, using ROM firmware [ 3.939090] imx-sdma 30bd0000.dma-controller: external firmware not found, using ROM firmware [ 3.939186] imx-sdma 302c0000.dma-controller: Direct firmware load for imx/sdma/sdma-imx7d.bin failed with error -2 [ 3.966989] imx-sdma 302c0000.dma-controller: Falling back to sysfs fallback for: imx/sdma/sdma-imx7d.bin [ 4.013621] imx-sdma 302c0000.dma-controller: external firmware not found, using ROM firmware I found the firmware files in: build/tmp/work/aarch64-mx8mm-poky-linux/firmware-imx-8m/8.8-r0/firmware-imx-8.8/firmware ... and copied them to the sdcard under /lib/firmware/imx directory but I still get the firmware errors. How "should" I be getting these firmware binaries into the core-image-minimal sdcard image to also get rid of the firmware loading errors? I'm using a rev B imx8mm-evk board and using the imx8mm-evk-revb.dtb. Regards, Brian |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [PATCH] imx-boot: add back LD_LIBRARY_PATH exporting
Otavio Salvador
Em seg., 5 de out. de 2020 às 09:41, Ming Liu <liu.ming50@...> escreveu:
Please open a PR with it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[PATCH] imx-boot: add back LD_LIBRARY_PATH exporting
Ming Liu <liu.ming50@...>
From: Ming Liu <liu.ming50@...>
It was dropped by commit 65100fad: [ imx-mkimage: upgrade to version 1.0 ] after that, the following error was observed again: | ./mkimage_uboot -E -p 0x3000 -f u-boot.its u-boot.itb | ./mkimage_uboot: error while loading shared libraries: libssl.so.1.1: c= annot open shared object file: No such file or directory Signed-off-by: Ming Liu <liu.ming50@...> --- recipes-bsp/imx-mkimage/imx-boot_1.0.bb | 3 +++ 1 file changed, 3 insertions(+) diff --git a/recipes-bsp/imx-mkimage/imx-boot_1.0.bb b/recipes-bsp/imx-mk= image/imx-boot_1.0.bb index a54b439d..08431b39 100644 --- a/recipes-bsp/imx-mkimage/imx-boot_1.0.bb +++ b/recipes-bsp/imx-mkimage/imx-boot_1.0.bb @@ -126,6 +126,9 @@ compile_mx8x() { fi } do_compile() { + # mkimage_uboot requires libssl.so.1.1 from ${STAGING_LIBDIR_NATIVE} + export LD_LIBRARY_PATH=3D${STAGING_LIBDIR_NATIVE}:$LD_LIBRARY_PATH + # mkimage for i.MX8 # Copy TEE binary to SoC target folder to mkimage if ${DEPLOY_OPTEE}; then --=20 2.28.0 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform
Otavio Salvador
Em seg., 5 de out. de 2020 às 04:51, Georg Hartinger
<Georg.Hartinger@...> escreveu: Yes, please open it.Verify using Poky (dunfell-next) as there is a queued fix for it.Same issue thereYou can open there and if it is not meta-freescale specific we try toaddress and reassign. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform
Georg Hartinger
Hi Otavio,
> Verify using Poky (dunfell-next) as there is a queued fix for it. Same issue there > You can open there and if it is not meta-freescale specific we try to address and reassign. Thanks for the info. Should I open a ticket for this too? Best regards Georg |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform
Otavio Salvador
Hello Georg,
Em sex., 2 de out. de 2020 às 10:14, Georg Hartinger <Georg.Hartinger@...> escreveu: Verify using Poky (dunfell-next) as there is a queued fix for it.Also an error occured on sources/poky/meta/recipes-kernel/lttng/lttng-modules_2.11.2.bb:do_compile:Is it possible to build the fsl-image-machine-test with fslc-wayland? I thought it is a bad idea to mix fsl images with fslc distros. But I try it.Yes. If you use the NXP BSP this is mostly the same. The setup was:You can open there and if it is not meta-freescale specific we try to address and reassign. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform
Georg Hartinger
Hi Otavio,
> Please open issues on github for those errors. Done > Please prepare a PR on github so we can review and apply. Need some time for this, because I'm not yet involved in this project > > Is it possible to build the fsl-image-machine-test with fslc-wayland? I thought it is a bad idea to mix fsl images with fslc distros. But I try it. >Yes. If you use the NXP BSP this is mostly the same. Also an error occured on sources/poky/meta/recipes-kernel/lttng/lttng-modules_2.11.2.bb:do_compile: /home/devel/src/bsp-dunfell-fslc/build-fslc-wayland/tmp/work/imx6qdlsabresd-fslc-linux-gnueabi/lttng-modules/2.11.2-r0/lttng-modules-2.11.2/probes/../probes/lttng-tracepoint-event-impl.h:130:6: error: conflicting types for 'trace_writeback_queue_io' |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform
Otavio Salvador
Hello,
Em qua., 30 de set. de 2020 às 14:51, Georg Hartinger <Georg.Hartinger@...> escreveu: Please open issues on github for those errors.We merged the dunfell-next so please upgrade your 'fslc' (using repoBuild is ok except uboot (which is now 2020.04), mesa and imx-test. Is it possible that you apply the appended patch on meta-freescale to fix the imx-test package? It adds a patchfile and the patch filename to the recipe.Please prepare a PR on github so we can review and apply. Yes. If you use the NXP BSP this is mostly the same.The 'fsl-wayland' uses the fsl pinned versions. We don't apply many fixes onIs it possible to build the fsl-image-machine-test with fslc-wayland? I thought it is a bad idea to mix fsl images with fslc distros. But I try it. ... From: Georg Hartinger <georg.hartinger@...>Please add the Upstream-Status header so we know this patch is pending. Signed-off-by: Georg Hartinger <georg.hartinger@...> -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform
Georg Hartinger
Hi Otavio, > > We merged the dunfell-next so please upgrade your 'fslc' (using repo > sync) and please give it a go. > Build is ok except uboot (which is now 2020.04), mesa and imx-test. Is it possible that you apply the appended patch on meta-freescale to fix the imx-test package? It adds a patchfile and the patch filename to the recipe. > The 'fsl-wayland' uses the fsl pinned versions. We don't apply many fixes on > those. The 'fslc-wayland' would be the equivalent one using the 'fslc' fixed > forks. > Is it possible to build the fsl-image-machine-test with fslc-wayland? I thought it is a bad idea to mix fsl images with fslc distros. But I try it. Best regards, Georg Here is the patch for imx-test: From ed49d06b52db5e18dad148d51e63b7aae4be1296 Mon Sep 17 00:00:00 2001
From: Georg Hartinger <georg.hartinger@...> Date: Wed, 30 Sep 2020 16:30:01 +0200 Subject: [PATCH 1/1] imx-test: fix compile issue format-not-a-string-literal Signed-off-by: Georg Hartinger <georg.hartinger@...> --- .../fix_compile_issue_format-not-a-string-literal.patch | 12 ++++++++++++ recipes-bsp/imx-test/imx-test_git.bb | 1 + 2 files changed, 13 insertions(+) create mode 100644 recipes-bsp/imx-test/imx-test/fix_compile_issue_format-not-a-string-literal.patch diff --git a/recipes-bsp/imx-test/imx-test/fix_compile_issue_format-not-a-string-literal.patch b/recipes-bsp/imx-test/imx-test/fix_compile_issue_format-not-a-string-literal.patch new file mode 100644 index 0000000..ff6f66b --- /dev/null +++ b/recipes-bsp/imx-test/imx-test/fix_compile_issue_format-not-a-string-literal.patch @@ -0,0 +1,12 @@ +diff --git a/test/pxp_lib_test/pxp_test.c b/test/pxp_lib_test/pxp_test.c +index 107198f..6275aec 100644 +--- a/test/pxp_lib_test/pxp_test.c ++++ b/test/pxp_lib_test/pxp_test.c +@@ -538,6 +538,6 @@ int main(int argc, char *argv[]) + + return 0; + usage: +- printf(usage); ++ puts(usage); + return -1; + } diff --git a/recipes-bsp/imx-test/imx-test_git.bb b/recipes-bsp/imx-test/imx-test_git.bb index 81bbd3a..6a10eb3 100644 --- a/recipes-bsp/imx-test/imx-test_git.bb +++ b/recipes-bsp/imx-test/imx-test_git.bb @@ -20,6 +20,7 @@ SRCBRANCH = "lf-5.4.y" SRC_URI = " \ git://source.codeaurora.org/external/imx/imx-test.git;protocol=https;branch=${SRCBRANCH} \ file://0001-mxc_v4l2_test-fix-compilation-error-produced-by-gcc9.patch \ + file://fix_compile_issue_format-not-a-string-literal.patch \ file://memtool_profile \ " SRCREV = "6d20e84f2dbe5940fe6d629c2839e1390994ee1f" -- 2.7.4 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: IMX7D bring up of second core
Otavio Salvador
Hello,
toggle quoted message
Show quoted text
Please check dunfell branch to check if it works. Em qua., 30 de set. de 2020 às 03:14, bartvanderlaan <bartvanderlaan@...> escreveu:
--
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform
Otavio Salvador
Hello Georg,
Em qua., 30 de set. de 2020 às 05:18, Georg Hartinger <Georg.Hartinger@...> escreveu: Ok, that was pretty easy. Thanks.We merged the dunfell-next so please upgrade your 'fslc' (using repo sync) and please give it a go. The 'fsl-wayland' uses the fsl pinned versions. We don't apply many fixes on those. The 'fslc-wayland' would be the equivalent one using the 'fslc' fixed forks. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform
Georg Hartinger
Hi Otavio, > > git checkout fslc/dunfell-next > Ok, that was pretty easy. Thanks. I configured and built as usual with $ MACHINE=imx6qdlsabresd DISTRO=fsl-wayland source setup-environment build-fsl-wayland $ bitbake -k fsl-image-machine-test And got the errors: Summary: 4 tasks failed: /home/georg/src/bsp-dunfell-community-next/sources/meta-freescale/recipes-bsp/u-boot/u-boot-imx_2020.04.bb:do_compile /home/georg/src/bsp-dunfell-community-next/sources/poky/meta/recipes-graphics/mesa/mesa_20.0.2.bb:do_configure /home/georg/src/bsp-dunfell-community-next/sources/meta-freescale/recipes-bsp/imx-test/imx-test_git.bb:do_compile /home/georg/src/bsp-dunfell-community-next/sources/meta-freescale-distro/recipes-graphics/imx-gpu-sdk/imx-gpu-sdk_5.0.2.bb:do_compile So gstreamer plugins work on dunfell next and if I copy the complete gstreamer recipe folder back to dunfell, then it works too. Only gstreamer-plugins-bad fails if copied alone. Mesa and the imx-test errors are the same as in plain dunfell. The imx-test error could be fixed with a patch: diff --git a/test/pxp_lib_test/pxp_test.c b/test/pxp_lib_test/pxp_test.c index 107198f..6275aec 100644 --- a/test/pxp_lib_test/pxp_test.c +++ b/test/pxp_lib_test/pxp_test.c @@ -538,6 +538,6 @@ int main(int argc, char *argv[]) return 0; usage: - printf(usage); + puts(usage); return -1; } And the mesa error message is "meson.build:455:4: ERROR: Problem encountered: building dri drivers require at least one windowing system or classic osmesa" which is already known according to https://github.com/Freescale/meta-freescale/issues/115 So if I add USE_OSMESA_ONLY_mx6 ?= "yes" in the mesa_%.bbappend, then it works but I think this is not the best solution. Do you have a better idea for this related to the IMX6 and a not mainlined Kernel? Best regards Georg
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform
Andrey Zhizhikin
Hello Georg, On Tue, Sep 29, 2020 at 9:14 PM Georg Hartinger <Georg.Hartinger@...> wrote:
Ah, OK. I've actually overlooked this statement. I was focused on the actual failure in GStreamer build. :) In this case I would also follow the advice from Otavio and use the dunfell-next branch. It should contain modifications you need, so the build should then be fine for you.
-- Regards, Andrey. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
IMX7D bring up of second core
bartvanderlaan
Hi,
I have recently started working on a project that is based on linux-fslc. The target board is a Technexion pico imx7d. Hopefully I have come to the right place to ask this question and this post provides enough information to paint a complete picture. I have trouble bringing up the 2nd core of the SoC and have tried to narrow this down. I'm comparing behaviour to a rescue image from Technexion (I have two pico-pi boards) which boots both processors in SVC. Board with project image:
Board with rescue image:
Things I have tried:
- 5.0.7-fslc and 5.4.20-fslc. - Remove CONFIG_ARMV7_BOOT_SEC_DEFAULT in u-boot-fslc, which does boot both processors in HYP mode resulting in some other issues. I don't know much about the differences between secure, non-secure and hypervisor mode and could not find a defenitive answer online which and if a certain mode is mandatory for the 2nd core. - Debug the boot process in secure mode with pr_info: SMP is actually trying to get cpu1 up but is failing when invoking callbacks. Looking at the call below to cpu_up for cpu 1, it returns an error code -38 although the return value is not used in with an error handler. This traces all the way back to the moment the callback is invoked for CPUHP_BRINGUP_CPU (cpuhp_state #85) where ret = cb(cpu) get’s the value -38, which if I’m not mistaken means ENOSYS. The callback invocations for this list below did pass without this error just before that for cpu1: 1; CPUHP_CREATE_THREADS Hopefully someone will see my post and share some experience in the matter, or point me to a place where this question might best be answered. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform
Otavio Salvador
Em ter., 29 de set. de 2020 às 16:24, Georg Hartinger
<Georg.Hartinger@...> escreveu: So how is dunfell-next built or where do I get the manifest file from to check the BSP?With a fslc dunfell repository (using normal manifest) go to sources/meta-freescale and do: git checkout fslc/dunfell-next -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform
Georg Hartinger
Hi Otavio, >
> Gesendet: Dienstag, 29. September 2020 18:43 > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > b.com%2FFreescale%2Fmeta-freescale%2Ftree%2Fdunfell- > next&data=02%7C01%7C%7C328ec692af5d4cbeaebc08d86496d33d%7C > 1b738660126645879d5454e9ad89e4cb%7C0%7C0%7C637369946239922584&a > mp;sdata=OEc%2B1lT7BnW3dc5zAxRoSdX3CovNMyKTQiHKvxgkZAU%3D&a > mp;reserved=0 > I'm not yet as familiar as I like on the community BSP. Most of my time I work on the NXP BSPs. Your link (https://github.com/Freescale/meta-freescale/tree/dunfell-next) is only the meta-freescale part of the BSP. Do I have to checkout https://github.com/Freescale/fsl-community-bsp-platform/blob/dunfell/default.xml and change from yocto/meta-freescale to freescale/meta-freescale? Or from master-next/default.xml? So how is dunfell-next built or where do I get the manifest file from to check the BSP? Best regards, Georg |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform
Georg Hartinger
Hi Andrey, >
> Gesendet: Dienstag, 29. September 2020 19:06 > > > I'm sorry, but the gstreamer-plugins-bad doesn't build as backport to Dunfell. I accidentally missed the build error of the gstreamer plugins due to another failure in mesa build. > > There are several errors more on Dunfell packages and on master-next: > /home/devel/src/bsp-dunfell-next/sources/meta-freescale/recipes-bsp/imx-test/imx-test_git.bb:do_compile > /home/devel/src/bsp-dunfell-next/sources/poky/meta/recipes-graphics/mesa/mesa_20.1.8.bb:do_configure > /home/devel/src/bsp-dunfell-next/sources/meta-freescale/recipes-bsp/u-boot/u-boot-imx_2020.04.bb:do_compile > /home/devel/src/bsp-dunfell-next/sources/poky/meta/recipes-kernel/perf/perf.bb:do_compile > > I see that there is a bit of mismatch in PV of recipes you're having your build errors in. You are right, the versions differes, but the same packages fail (except perf). The above were the results of master-next (got from https://github.com/Freescale/fsl-community-bsp-platform) On dunfell: Summary: 4 tasks failed: /home/devel/src/bsp-dunfell/sources/meta-freescale/recipes-bsp/u-boot/u-boot-imx_2019.04.bb:do_compile /home/devel/src/bsp-dunfell/sources/meta-freescale/recipes-bsp/imx-test/imx-test_git.bb:do_compile /home/devel/src/bsp-dunfell/sources/poky/meta/recipes-graphics/mesa/mesa_20.0.2.bb:do_configure /home/devel/src/bsp-dunfell/sources/meta-freescale/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.16.imx.bb:do_compile > Can you post versions of all layers you're taking in your build (from the start of bitbake)? Also it would be great if you can patebin the compile log of gstreamer-plugins-bad, where the error can be observed. As already mentioned, I did a clean checkout with repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b dunfell. Then configured and built with (no mainline): MACHINE='imx6qdlsabresd' DISTRO='fsl-wayland' bitbake fsl-image-machine-test $ bitbake-layers show-layers NOTE: Starting bitbake server... layer path priority ========================================================================== meta /home/devel/src/bsp-dunfell/sources/poky/meta 5 meta-poky /home/devel/src/bsp-dunfell/sources/poky/meta-poky 5 meta-oe /home/devel/src/bsp-dunfell/sources/meta-openembedded/meta-oe 6 meta-multimedia /home/devel/src/bsp-dunfell/sources/meta-openembedded/meta-multimedia 6 meta-python /home/devel/src/bsp-dunfell/sources/meta-openembedded/meta-python 7 meta-freescale /home/devel/src/bsp-dunfell/sources/meta-freescale 5 meta-freescale-3rdparty /home/devel/src/bsp-dunfell/sources/meta-freescale-3rdparty 4 meta-freescale-distro /home/devel/src/bsp-dunfell/sources/meta-freescale-distro 4 And here is the log: https://pastebin.com/a7Hjn66T As already said, the include paths have to be changed to "#include <libdrm/drm_fourcc.h>" from "#include <drm_fourcc.h>". This was already fixed in master-next. Best regards Georg |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform
Andrey Zhizhikin
Hello Georg, On Tue, Sep 29, 2020 at 6:30 PM Georg Hartinger <Georg.Hartinger@...> wrote:
I see that there is a bit of mismatch in PV of recipes you're having your build errors in. For example: u-boot-imx: dunfell version is still 2019.04, while you have a 2020.04 (which is either from master-next or from dunfell-next) Can you post versions of all layers you're taking in your build (from the start of bitbake)? Also it would be great if you can patebin the compile log of gstreamer-plugins-bad, where the error can be observed.
-- Regards, Andrey. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform
Otavio Salvador
Georg,
Em ter., 29 de set. de 2020 às 13:30, Georg Hartinger <Georg.Hartinger@...> escreveu: ... https://github.com/Freescale/meta-freescale/tree/dunfell-nextCould you do some tests using our dunfell-next branch?Yes, what should I test? -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform
Georg Hartinger
Hi Otavio, >
> Von: Otavio Salvador <otavio.salvador@...> > Gesendet: Dienstag, 29. September 2020 13:36 > We intend to together with the rest of the changes from 5.4-2.1.x GA. I'm sorry, but the gstreamer-plugins-bad doesn't build as backport to Dunfell. I accidentally missed the build error of the gstreamer plugins due to another failure in mesa build. There are several errors more on Dunfell packages and on master-next: /home/devel/src/bsp-dunfell-next/sources/meta-freescale/recipes-bsp/imx-test/imx-test_git.bb:do_compile /home/devel/src/bsp-dunfell-next/sources/poky/meta/recipes-graphics/mesa/mesa_20.1.8.bb:do_configure /home/devel/src/bsp-dunfell-next/sources/meta-freescale/recipes-bsp/u-boot/u-boot-imx_2020.04.bb:do_compile /home/devel/src/bsp-dunfell-next/sources/poky/meta/recipes-kernel/perf/perf.bb:do_compile In addition, on Dunfell also the gstreamer-plugins-bad doesn't build. I wrote patches to fix imx-test and perf in Dunfell for my work but as already mentioned, I don't know how to handle the changes inside the recipe-sysroot of the gstreamer-plugins-bad package. So any ideas? > Could you do some tests using our dunfell-next branch? Yes, what should I test? Regards, Georg Hartinger Software Engineer ARM congatec AG |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
