meta-freescale@lists.yoctoproject.org

Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform

Otavio Salvador

#24429

Hello,

Em qua., 30 de set. de 2020 às 14:51, Georg Hartinger
<Georg.Hartinger@...> escreveu:
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.Please open issues on github for those errors.

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.

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.Yes. If you use the NXP BSP this is mostly the same.

...
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-literalPlease 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

#24428

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

Mit freundlichen Grüßen / Best regards,

Georg Hartinger

Software Engineer ARM

Tel:	+49 (991) 2700-169
Email:	Georg.Hartinger@...	Fax:	+49 (991) 2700-27169
Web:	www.congatec.com

_____________________________________________________________________

congatec AG

|

Auwiesenstraße 5

|

94469

Deggendorf

|

Germany

_____________________________________________________________________

Vorstand/Executive Board: Jason Carlson (CEO), G. Edi, J. Wenzl, T. Schultze
Aufsichtsratsvorsitzender/Chairman of Supervisory Board: Dr. Wolfgang Hanrieder
HRB Deggendorf 2731

Datenschutz - Der Inhalt dieser E-Mail ist vertraulich. Wenn Sie diese E-Mail irrtümlich erhalten haben, löschen Sie sie bitte und
benachrichtigen Sie bitte umgehend per Antwort-E-Mail den Absender. In diesem Fall darf die E-Mail weder kopiert oder
für andere Zwecke verwendet, noch darf ihr Inhalt anderen Personen offengelegt werden.
Privacy Policy - Any e-mail sent from congatec may contain information which is confidential. If you are not the intended recipient, you may not
disclose, copy or use it; please notify the sender immediately and delete this e-mail and any copies from your systems.

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

#24427

Hello,

Please check dunfell branch to check if it works.

Em qua., 30 de set. de 2020 às 03:14, bartvanderlaan
<bartvanderlaan@...> escreveu:

Show quoted text

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:

[    0.007136] CPU: Testing write buffer coherency: ok
[    0.008708] CPU0: update cpu_capacity 1024
[    0.008738] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.011558] Setting up static identity map for 0x80100000 - 0x80100078
[    0.012194] rcu: Hierarchical SRCU implementation.
[    0.013650] smp: Bringing up secondary CPUs ...
[    0.016375] smp: Brought up 1 node, 1 CPU
[    0.016405] SMP: Total of 1 processors activated (48.00 BogoMIPS).
[    0.016427] CPU: All CPU(s) started in SVC mode.

Board with rescue image:

CPU: Testing write buffer coherency: ok
CPU0: update cpu_capacity 1024
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x80100000 - 0x80100058
CPU1: update cpu_capacity 1024
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
Brought up 2 CPUs
SMP: Total of 2 processors activated (32.00 BogoMIPS).
CPU: All CPU(s) started in SVC mode.

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.

github.com

Freescale/linux-fslc/blob/c7a0e482a175b632bfd5522bc6d5bfe7785ee9a9/kernel/smp.c#L578

Copy

idle_threads_init();
cpuhp_threads_init();

pr_info("Bringing up secondary CPUs ...\n");

/* FIXME: This should be done in userspace --RR */
for_each_present_cpu(cpu) {
if (num_online_cpus() >= setup_max_cpus)
break;
if (!cpu_online(cpu))
cpu_up(cpu);
}

num_nodes = num_online_nodes();
num_cpus = num_online_cpus();
pr_info("Brought up %d node%s, %d CPU%s\n",
num_nodes, (num_nodes > 1 ? "s" : ""),
num_cpus, (num_cpus > 1 ? "s" : ""));

/* Any cleanup work */
smp_cpus_done(setup_max_cpus);




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.

github.com

Freescale/linux-fslc/blob/c7a0e482a175b632bfd5522bc6d5bfe7785ee9a9/kernel/cpu.c#L168

Copy


return -EAGAIN;
}

if (!step->multi_instance) {
WARN_ON_ONCE(lastp && *lastp);
cb = bringup ? step->startup.single : step->teardown.single;
if (!cb)
return 0;
trace_cpuhp_enter(cpu, st->target, state, cb);
ret = cb(cpu);
trace_cpuhp_exit(cpu, st->state, state, ret);
return ret;
}
cbm = bringup ? step->startup.multi : step->teardown.multi;
if (!cbm)
return 0;

/* Single invocation for instance add/remove */
if (node) {
WARN_ON_ONCE(lastp && *lastp);




The callback invocations for this list below did pass without this error just before that for cpu1:

1; CPUHP_CREATE_THREADS
2; CPUHP_PERF_PREPARE
35; CPUHP_WORKQUEUE_PREP
37; CPUHP_HRTIMERS_PREPARE
40; CPUHP_SMPCFD_PREPARE
41; CPUHP_RELAY_PREPARE
44; CPUHP_RCUTREE_PREP
62; CPUHP_TIMERS_PREPARE

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.

Best regards,
Bart van der Laan

-- 
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

#24426

Hello Georg,


Em qua., 30 de set. de 2020 às 05:18, Georg Hartinger
<Georg.Hartinger@...> escreveu:
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-testWe 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

#24425

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

Mit freundlichen Grüßen / Best regards,

Georg Hartinger

Software Engineer ARM

Tel:	+49 (991) 2700-169
Email:	Georg.Hartinger@...	Fax:	+49 (991) 2700-27169
Web:	www.congatec.com

_____________________________________________________________________

congatec AG

|

Auwiesenstraße 5

|

94469

Deggendorf

|

Germany

_____________________________________________________________________

Vorstand/Executive Board: Jason Carlson (CEO), G. Edi, J. Wenzl, T. Schultze
Aufsichtsratsvorsitzender/Chairman of Supervisory Board: Dr. Wolfgang Hanrieder
HRB Deggendorf 2731

Datenschutz - Der Inhalt dieser E-Mail ist vertraulich. Wenn Sie diese E-Mail irrtümlich erhalten haben, löschen Sie sie bitte und
benachrichtigen Sie bitte umgehend per Antwort-E-Mail den Absender. In diesem Fall darf die E-Mail weder kopiert oder
für andere Zwecke verwendet, noch darf ihr Inhalt anderen Personen offengelegt werden.
Privacy Policy - Any e-mail sent from congatec may contain information which is confidential. If you are not the intended recipient, you may not
disclose, copy or use it; please notify the sender immediately and delete this e-mail and any copies from your systems.

Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform

Andrey Zhizhikin

#24424

Hello Georg,

On Tue, Sep 29, 2020 at 9:14 PM Georg Hartinger <Georg.Hartinger@...> wrote:

Hi Andrey,

>
Mit freundlichen Grüßen / Best regards,

Georg Hartinger
Software Engineer ARM

Tel: +49 (991) 2700-169
Email: Georg.Hartinger@...
Fax: +49 (991) 2700-27169
Web: www.congatec.com
_____________________________________________________________________



congatec AG | Auwiesenstraße 5 | 94469
Deggendorf | Germany
_____________________________________________________________________
Vorstand/Executive Board: Jason Carlson (CEO), G. Edi, J. Wenzl, T. Schultze
Aufsichtsratsvorsitzender/Chairman of Supervisory Board: Dr. Wolfgang Hanrieder
HRB Deggendorf 2731

Datenschutz - Der Inhalt dieser E-Mail ist vertraulich. Wenn Sie diese E-Mail irrtümlich erhalten haben, löschen Sie sie bitte und
benachrichtigen Sie bitte umgehend per Antwort-E-Mail den Absender. In diesem Fall darf die E-Mail weder kopiert oder
für andere Zwecke verwendet, noch darf ihr Inhalt anderen Personen offengelegt werden.
Privacy Policy - Any e-mail sent from congatec may contain information which is confidential. If you are not the intended recipient, you may not
disclose, copy or use it; please notify the sender immediately and delete this e-mail and any copies from your systems.
Von: meta-freescale@... <meta-freescale@...> Im Auftrag von Andrey Zhizhikin via lists.yoctoproject.org
> 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.

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.

Best regards
Georg

--

Regards,
Andrey.

IMX7D bring up of second core

bartvanderlaan

#24423

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:

[ 0.007136] CPU: Testing write buffer coherency: ok

[ 0.008708] CPU0: update cpu_capacity 1024

[ 0.008738] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000

[ 0.011558] Setting up static identity map for 0x80100000 - 0x80100078

[ 0.012194] rcu: Hierarchical SRCU implementation.

[ 0.013650] smp: Bringing up secondary CPUs ...

[ 0.016375] smp: Brought up 1 node, 1 CPU

[ 0.016405] SMP: Total of 1 processors activated (48.00 BogoMIPS).

[ 0.016427] CPU: All CPU(s) started in SVC mode.

Board with rescue image:

CPU: Testing write buffer coherency: ok

CPU0: update cpu_capacity 1024

CPU0: thread -1, cpu 0, socket 0, mpidr 80000000

Setting up static identity map for 0x80100000 - 0x80100058

CPU1: update cpu_capacity 1024

CPU1: thread -1, cpu 1, socket 0, mpidr 80000001

Brought up 2 CPUs

SMP: Total of 2 processors activated (32.00 BogoMIPS).

CPU: All CPU(s) started in SVC mode.

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.

github.com

Freescale/linux-fslc/blob/c7a0e482a175b632bfd5522bc6d5bfe7785ee9a9/kernel/smp.c#L578

Copy

idle_threads_init();
cpuhp_threads_init();
pr_info("Bringing up secondary CPUs ...\n");
/* FIXME: This should be done in userspace --RR */
for_each_present_cpu(cpu) {
if (num_online_cpus() >= setup_max_cpus)
break;
if (!cpu_online(cpu))
cpu_up(cpu);
}
num_nodes = num_online_nodes();
num_cpus = num_online_cpus();
pr_info("Brought up %d node%s, %d CPU%s\n",
num_nodes, (num_nodes > 1 ? "s" : ""),
num_cpus, (num_cpus > 1 ? "s" : ""));
/* Any cleanup work */
smp_cpus_done(setup_max_cpus);

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.

github.com

Freescale/linux-fslc/blob/c7a0e482a175b632bfd5522bc6d5bfe7785ee9a9/kernel/cpu.c#L168

Copy

return -EAGAIN;
}
if (!step->multi_instance) {
WARN_ON_ONCE(lastp && *lastp);
cb = bringup ? step->startup.single : step->teardown.single;
if (!cb)
return 0;
trace_cpuhp_enter(cpu, st->target, state, cb);
ret = cb(cpu);
trace_cpuhp_exit(cpu, st->state, state, ret);
return ret;
}
cbm = bringup ? step->startup.multi : step->teardown.multi;
if (!cbm)
return 0;
/* Single invocation for instance add/remove */
if (node) {
WARN_ON_ONCE(lastp && *lastp);

The callback invocations for this list below did pass without this error just before that for cpu1:

1; CPUHP_CREATE_THREADS
2; CPUHP_PERF_PREPARE
35; CPUHP_WORKQUEUE_PREP
37; CPUHP_HRTIMERS_PREPARE
40; CPUHP_SMPCFD_PREPARE
41; CPUHP_RELAY_PREPARE
44; CPUHP_RCUTREE_PREP
62; CPUHP_TIMERS_PREPARE

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.

Best regards,
Bart van der Laan

Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform

Otavio Salvador

#24422

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

#24421

Hi Otavio,

>

Mit freundlichen Grüßen / Best regards,

Georg Hartinger

Software Engineer ARM

Tel:	+49 (991) 2700-169
Email:	Georg.Hartinger@...	Fax:	+49 (991) 2700-27169
Web:	www.congatec.com

_____________________________________________________________________

congatec AG

|

Auwiesenstraße 5

|

94469

Deggendorf

|

Germany

_____________________________________________________________________

Vorstand/Executive Board: Jason Carlson (CEO), G. Edi, J. Wenzl, T. Schultze
Aufsichtsratsvorsitzender/Chairman of Supervisory Board: Dr. Wolfgang Hanrieder
HRB Deggendorf 2731

Datenschutz - Der Inhalt dieser E-Mail ist vertraulich. Wenn Sie diese E-Mail irrtümlich erhalten haben, löschen Sie sie bitte und
benachrichtigen Sie bitte umgehend per Antwort-E-Mail den Absender. In diesem Fall darf die E-Mail weder kopiert oder
für andere Zwecke verwendet, noch darf ihr Inhalt anderen Personen offengelegt werden.
Privacy Policy - Any e-mail sent from congatec may contain information which is confidential. If you are not the intended recipient, you may not
disclose, copy or use it; please notify the sender immediately and delete this e-mail and any copies from your systems.

Von: Otavio Salvador <otavio.salvador@...>
> 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

#24420

Hi Andrey,

>

Mit freundlichen Grüßen / Best regards,

Georg Hartinger

Software Engineer ARM

Tel:	+49 (991) 2700-169
Email:	Georg.Hartinger@...	Fax:	+49 (991) 2700-27169
Web:	www.congatec.com

_____________________________________________________________________

congatec AG

|

Auwiesenstraße 5

|

94469

Deggendorf

|

Germany

_____________________________________________________________________

Vorstand/Executive Board: Jason Carlson (CEO), G. Edi, J. Wenzl, T. Schultze
Aufsichtsratsvorsitzender/Chairman of Supervisory Board: Dr. Wolfgang Hanrieder
HRB Deggendorf 2731

Datenschutz - Der Inhalt dieser E-Mail ist vertraulich. Wenn Sie diese E-Mail irrtümlich erhalten haben, löschen Sie sie bitte und
benachrichtigen Sie bitte umgehend per Antwort-E-Mail den Absender. In diesem Fall darf die E-Mail weder kopiert oder
für andere Zwecke verwendet, noch darf ihr Inhalt anderen Personen offengelegt werden.
Privacy Policy - Any e-mail sent from congatec may contain information which is confidential. If you are not the intended recipient, you may not
disclose, copy or use it; please notify the sender immediately and delete this e-mail and any copies from your systems.

Von: meta-freescale@... <meta-freescale@...> Im Auftrag von Andrey Zhizhikin via lists.yoctoproject.org
> 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

#24419

Hello Georg,

On Tue, Sep 29, 2020 at 6:30 PM Georg Hartinger <Georg.Hartinger@...> wrote:

Hi Otavio,

>
Mit freundlichen Grüßen / Best regards,

Georg Hartinger
Software Engineer ARM

Tel: +49 (991) 2700-169
Email: Georg.Hartinger@...
Fax: +49 (991) 2700-27169
Web: www.congatec.com
_____________________________________________________________________



congatec AG | Auwiesenstraße 5 | 94469
Deggendorf | Germany
_____________________________________________________________________
Vorstand/Executive Board: Jason Carlson (CEO), G. Edi, J. Wenzl, T. Schultze
Aufsichtsratsvorsitzender/Chairman of Supervisory Board: Dr. Wolfgang Hanrieder
HRB Deggendorf 2731

Datenschutz - Der Inhalt dieser E-Mail ist vertraulich. Wenn Sie diese E-Mail irrtümlich erhalten haben, löschen Sie sie bitte und
benachrichtigen Sie bitte umgehend per Antwort-E-Mail den Absender. In diesem Fall darf die E-Mail weder kopiert oder
für andere Zwecke verwendet, noch darf ihr Inhalt anderen Personen offengelegt werden.
Privacy Policy - Any e-mail sent from congatec may contain information which is confidential. If you are not the intended recipient, you may not
disclose, copy or use it; please notify the sender immediately and delete this e-mail and any copies from your systems.
-----Ursprüngliche Nachricht-----
> 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

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.

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

--

Regards,
Andrey.

Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform

Otavio Salvador

#24418

Georg,

Em ter., 29 de set. de 2020 às 13:30, Georg Hartinger
<Georg.Hartinger@...> escreveu:
...
Could you do some tests using our dunfell-next branch?Yes, what should I test?https://github.com/Freescale/meta-freescale/tree/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

#24417

Hi Otavio,

>

Mit freundlichen Grüßen / Best regards,

Georg Hartinger

Software Engineer ARM

Tel:	+49 (991) 2700-169
Email:	Georg.Hartinger@...	Fax:	+49 (991) 2700-27169
Web:	www.congatec.com

_____________________________________________________________________

congatec AG

|

Auwiesenstraße 5

|

94469

Deggendorf

|

Germany

_____________________________________________________________________

Vorstand/Executive Board: Jason Carlson (CEO), G. Edi, J. Wenzl, T. Schultze
Aufsichtsratsvorsitzender/Chairman of Supervisory Board: Dr. Wolfgang Hanrieder
HRB Deggendorf 2731

Datenschutz - Der Inhalt dieser E-Mail ist vertraulich. Wenn Sie diese E-Mail irrtümlich erhalten haben, löschen Sie sie bitte und
benachrichtigen Sie bitte umgehend per Antwort-E-Mail den Absender. In diesem Fall darf die E-Mail weder kopiert oder
für andere Zwecke verwendet, noch darf ihr Inhalt anderen Personen offengelegt werden.
Privacy Policy - Any e-mail sent from congatec may contain information which is confidential. If you are not the intended recipient, you may not
disclose, copy or use it; please notify the sender immediately and delete this e-mail and any copies from your systems.

-----Ursprüngliche Nachricht-----
> 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

Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform

Otavio Salvador

#24416

Em ter., 29 de set. de 2020 às 06:56, Georg Hartinger
<Georg.Hartinger@...> escreveu:
the gstreamer-plugins-bad build on master-next. I copied them to dunfell and they also build (also on old Ubuntu 16.04).

Is it possible to backport them officially?We intend to together with the rest of the changes from 5.4-2.1.x GA.
Could you do some tests using our dunfell-next branch?

-- 
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

#24415

Hi Otavio,

the gstreamer-plugins-bad build on master-next. I copied them to dunfell and they also build (also on old Ubuntu 16.04).

Is it possible to backport them officially?

Best regards,
Georg

Regards,

Georg Hartinger
Software Engineer ARM
congatec AG
>

Mit freundlichen Grüßen / Best regards,

Georg Hartinger

Software Engineer ARM

Tel:	+49 (991) 2700-169
Email:	Georg.Hartinger@...	Fax:	+49 (991) 2700-27169
Web:	www.congatec.com

_____________________________________________________________________

congatec AG

|

Auwiesenstraße 5

|

94469

Deggendorf

|

Germany

_____________________________________________________________________

Vorstand/Executive Board: Jason Carlson (CEO), G. Edi, J. Wenzl, T. Schultze
Aufsichtsratsvorsitzender/Chairman of Supervisory Board: Dr. Wolfgang Hanrieder
HRB Deggendorf 2731

Datenschutz - Der Inhalt dieser E-Mail ist vertraulich. Wenn Sie diese E-Mail irrtümlich erhalten haben, löschen Sie sie bitte und
benachrichtigen Sie bitte umgehend per Antwort-E-Mail den Absender. In diesem Fall darf die E-Mail weder kopiert oder
für andere Zwecke verwendet, noch darf ihr Inhalt anderen Personen offengelegt werden.
Privacy Policy - Any e-mail sent from congatec may contain information which is confidential. If you are not the intended recipient, you may not
disclose, copy or use it; please notify the sender immediately and delete this e-mail and any copies from your systems.

-----Ursprüngliche Nachricht-----
> Von: Georg Hartinger
> Gesendet: Montag, 28. September 2020 23:24
> An: meta-freescale@...
> Betreff: Re: [meta-freescale] gstreamer-plugins-bad build error in dunfell for
> SABRESD platform
>
> Hi Otavio
>
>
> > >
> > > The error is in gstreamer1.0-plugins-bad_1.16.imx:
> > >
> > > a2e124a@@gstwaylandsink@sha/wlvideoformat.c.o' -c
> > > ../git/ext/wayland/wlvideoformat.c
> > > | In file included from ../git/ext/wayland/wlvideoformat.c:30:
> > > | ../git/ext/wayland/wlvideoformat.h:29:10: fatal error: drm_fourcc.h:
> > > | No such file or directory
> > > | 29 | #include <drm_fourcc.h>
> > >
> > > The correct include path for this file would be <libdrm/drm_fourcc.h> so
> if I change all those includes it works.
> > > But also all "#include <drm.h>" inside the recipe-sysroot folder have to
> be replaced with "#include <libdrm/drm.h>".
> > >
> > > The strange thing is, that the gstreamer1.0-plugins-base does have
> > > that extended include path (also in the recipe-sysroot folder)
> > >
> > > Any idea on how to fix this? I know I could write a patch for the sources
> itself, but how to handle the recipe-sysroot folder stuff?
> >
> >
> > Please check the meta-freescale at dunfell-next branch and see if you
> > reproduce the issue.
> >
> >
>
> I tested it with master-next and got an error complaining about the gcc
> version:
>
> ERROR: OE-core's config sanity checker detected a potential
> misconfiguration.
> Either fix the cause of this error or at your own risk disable the checker (see
> sanity.conf).
> Following is the list of potential problems / advisories:
>
> Your version of gcc is older than 6.0 and will break builds. Please install a
> newer version of gcc (you could use the project's buildtools-extended-tarball
> or use scripts/install-buildtools).
>
>
> A gcc --version results in:
> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609
>
>
> So I will setup a new development machine with Ubuntu 20.04 tomorrow and
> test it again.
>
>
> Thanks, and best regards,
>
> Georg Hartinger
> Software Engineer ARM
> congatec AG

Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform

Georg Hartinger

#24414

Hi Otavio

> >
> > The error is in gstreamer1.0-plugins-bad_1.16.imx:
> >
> > a2e124a@@gstwaylandsink@sha/wlvideoformat.c.o' -c
> > ../git/ext/wayland/wlvideoformat.c
> > | In file included from ../git/ext/wayland/wlvideoformat.c:30:
> > | ../git/ext/wayland/wlvideoformat.h:29:10: fatal error: drm_fourcc.h:
> > | No such file or directory
> > | 29 | #include <drm_fourcc.h>
> >
> > The correct include path for this file would be <libdrm/drm_fourcc.h> so if I change all those includes it works.
> > But also all "#include <drm.h>" inside the recipe-sysroot folder have to be replaced with "#include <libdrm/drm.h>".
> >
> > The strange thing is, that the gstreamer1.0-plugins-base does have
> > that extended include path (also in the recipe-sysroot folder)
> >
> > Any idea on how to fix this? I know I could write a patch for the sources itself, but how to handle the recipe-sysroot folder stuff?
>
>
> Please check the meta-freescale at dunfell-next branch and see if you
> reproduce the issue.
>
>

I tested it with master-next and got an error complaining about the gcc version:

ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:

Your version of gcc is older than 6.0 and will break builds. Please install a newer version of gcc (you could use the project's buildtools-extended-tarball or use scripts/install-buildtools).

A gcc --version results in:
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609

So I will setup a new development machine with Ubuntu 20.04 tomorrow and test it again.

Thanks, and best regards,

Georg Hartinger
Software Engineer ARM
congatec AG

Mit freundlichen Grüßen / Best regards,

Georg Hartinger

Software Engineer ARM

Tel:	+49 (991) 2700-169
Email:	Georg.Hartinger@...	Fax:	+49 (991) 2700-27169
Web:	www.congatec.com

_____________________________________________________________________

congatec AG

|

Auwiesenstraße 5

|

94469

Deggendorf

|

Germany

_____________________________________________________________________

Vorstand/Executive Board: Jason Carlson (CEO), G. Edi, J. Wenzl, T. Schultze
Aufsichtsratsvorsitzender/Chairman of Supervisory Board: Dr. Wolfgang Hanrieder
HRB Deggendorf 2731

Datenschutz - Der Inhalt dieser E-Mail ist vertraulich. Wenn Sie diese E-Mail irrtümlich erhalten haben, löschen Sie sie bitte und
benachrichtigen Sie bitte umgehend per Antwort-E-Mail den Absender. In diesem Fall darf die E-Mail weder kopiert oder
für andere Zwecke verwendet, noch darf ihr Inhalt anderen Personen offengelegt werden.
Privacy Policy - Any e-mail sent from congatec may contain information which is confidential. If you are not the intended recipient, you may not
disclose, copy or use it; please notify the sender immediately and delete this e-mail and any copies from your systems.

Re: gstreamer-plugins-bad build error in dunfell for SABRESD platform

Otavio Salvador

#24413

Hello Georg,

Em seg., 28 de set. de 2020 às 13:18, Georg Hartinger
<Georg.Hartinger@...> escreveu:

I get build errors when building plain yocto Dunfell for the iMX6 SABRESD plattform (not mainline)

The setup was (under Ubuntu 16.04):
$ repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b dunfell
$ MACHINE=imx6qdlsabresd DISTRO=fsl-wayland source setup-environment build-fsl-wayland
$ bitbake fsl-image-machine-test


The error is in gstreamer1.0-plugins-bad_1.16.imx:

a2e124a@@gstwaylandsink@sha/wlvideoformat.c.o' -c ../git/ext/wayland/wlvideoformat.c
| In file included from ../git/ext/wayland/wlvideoformat.c:30:
| ../git/ext/wayland/wlvideoformat.h:29:10: fatal error: drm_fourcc.h: No such file or directory
| 29 | #include <drm_fourcc.h>

The correct include path for this file would be <libdrm/drm_fourcc.h> so if I change all those includes it works.
But also all "#include <drm.h>" inside the recipe-sysroot folder have to be replaced with "#include <libdrm/drm.h>".

The strange thing is, that the gstreamer1.0-plugins-base does have that extended include path (also in the recipe-sysroot folder)

Any idea on how to fix this? I know I could write a patch for the sources itself, but how to handle the recipe-sysroot folder stuff?
Please check the meta-freescale at dunfell-next branch and see if you
reproduce the issue.


-- 
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

gstreamer-plugins-bad build error in dunfell for SABRESD platform

Georg Hartinger

#24412

Hi all,

I get build errors when building plain yocto Dunfell for the iMX6 SABRESD plattform (not mainline)

The setup was (under Ubuntu 16.04):
$ repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b dunfell
$ MACHINE=imx6qdlsabresd DISTRO=fsl-wayland source setup-environment build-fsl-wayland
$ bitbake fsl-image-machine-test

The error is in gstreamer1.0-plugins-bad_1.16.imx:

a2e124a@@gstwaylandsink@sha/wlvideoformat.c.o' -c ../git/ext/wayland/wlvideoformat.c
| In file included from ../git/ext/wayland/wlvideoformat.c:30:
| ../git/ext/wayland/wlvideoformat.h:29:10: fatal error: drm_fourcc.h: No such file or directory
| 29 | #include <drm_fourcc.h>

The correct include path for this file would be <libdrm/drm_fourcc.h> so if I change all those includes it works.
But also all "#include <drm.h>" inside the recipe-sysroot folder have to be replaced with "#include <libdrm/drm.h>".

The strange thing is, that the gstreamer1.0-plugins-base does have that extended include path (also in the recipe-sysroot folder)

Any idea on how to fix this? I know I could write a patch for the sources itself, but how to handle the recipe-sysroot folder stuff?

Best Regards,

Georg Hartinger
Software Engineer ARM
congatec AG

Mit freundlichen Grüßen / Best regards,

Georg Hartinger

Software Engineer ARM

Tel:	+49 (991) 2700-169
Email:	Georg.Hartinger@...	Fax:	+49 (991) 2700-27169
Web:	www.congatec.com

_____________________________________________________________________

congatec AG

|

Auwiesenstraße 5

|

94469

Deggendorf

|

Germany

_____________________________________________________________________

Vorstand/Executive Board: Jason Carlson (CEO), G. Edi, J. Wenzl, T. Schultze
Aufsichtsratsvorsitzender/Chairman of Supervisory Board: Dr. Wolfgang Hanrieder
HRB Deggendorf 2731

Datenschutz - Der Inhalt dieser E-Mail ist vertraulich. Wenn Sie diese E-Mail irrtümlich erhalten haben, löschen Sie sie bitte und
benachrichtigen Sie bitte umgehend per Antwort-E-Mail den Absender. In diesem Fall darf die E-Mail weder kopiert oder
für andere Zwecke verwendet, noch darf ihr Inhalt anderen Personen offengelegt werden.
Privacy Policy - Any e-mail sent from congatec may contain information which is confidential. If you are not the intended recipient, you may not
disclose, copy or use it; please notify the sender immediately and delete this e-mail and any copies from your systems.

Re: OpenGL ES on i.MX8

Joshua Watt

#24411

On Mon, Sep 14, 2020 at 3:56 PM Peter Bergin <peter@...> wrote:

Hi Andy,

On 2020-09-14 13:20, Andy Pont wrote:
Trying to find an equivalent configuration for the i.MX8m I am unable
to find an equivalent method.  The Vivante user space libraries don’t
seem to exist in a framebuffer or DRM form, instead they all seem to
require Wayland or X11.

Can someone more knowledgeable than I confirm whether that is the case
or whether I am missing something?

-Andy.this is the statement from NXP
(https://source.codeaurora.org/external/imx/imx-manifest/tree/README?h=imx-linux-zeus#n53).
As seen they do not actively support the framebuffer distro for i.Mx8
targets on their official BSP.

The recipe for vivante user space lib imx-gpu-viv also have a guard for
mx8 that only builds it when wayland is enabled.
(https://github.com/Freescale/meta-freescale/blob/e0fa0255795ce584b3b5ad74c330cabeb0caa28d/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc#L60).

I'm also interested in the same question as you are as I'm in a start up
phase for a i.Mx8 project where we would like to run with OpenGL or
Vulkan directly against DRM and avoid display manager. Would be great to
hear someone from NXP give their picture of this. I have tried the NXP
community but without any info so far.
(https://community.nxp.com/t5/i-MX-Graphics/vulkan-without-display-server-Wayland-X11/m-p/1134083#M1)FWIW, standing up a GLES/DRM/KMS application isn't terribly hard. I've
done it on an IMX8 before without too much trouble. kmscube is
probably the best place to start as it is a pretty complete example.

However, I would also highly recommend looking at running your
application under the weston (wayland) fullscreen shell. It's just as
powerful except you don't have to deal with all the twiddly DRM/KMS
APIs, and the "overhead" is pretty much non-existent because you
render directly to a DMA buf which weston presents to the display.


Best regards,
/Peter

Re: OpenGL ES on i.MX8

Peter Bergin

#24410

Hi Andy,

On 2020-09-14 13:20, Andy Pont wrote:
Trying to find an equivalent configuration for the i.MX8m I am unable to find an equivalent method.  The Vivante user space libraries don’t seem to exist in a framebuffer or DRM form, instead they all seem to require Wayland or X11.

Can someone more knowledgeable than I confirm whether that is the case or whether I am missing something?

-Andy.this is the statement from NXP (https://source.codeaurora.org/external/imx/imx-manifest/tree/README?h=imx-linux-zeus#n53). As seen they do not actively support the framebuffer distro for i.Mx8 targets on their official BSP.

The recipe for vivante user space lib imx-gpu-viv also have a guard for mx8 that only builds it when wayland is enabled. (https://github.com/Freescale/meta-freescale/blob/e0fa0255795ce584b3b5ad74c330cabeb0caa28d/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc#L60).

I'm also interested in the same question as you are as I'm in a start up phase for a i.Mx8 project where we would like to run with OpenGL or Vulkan directly against DRM and avoid display manager. Would be great to hear someone from NXP give their picture of this. I have tried the NXP community but without any info so far. (https://community.nxp.com/t5/i-MX-Graphics/vulkan-without-display-server-Wayland-X11/m-p/1134083#M1)

Best regards,
/Peter