Date   

Re: [PATCH] imx-gpu-viv: fix libvulkan soname issue

Max Krummenacher
 

Hi Ming

While this fixes the conflict I believe (or hope) that imx-gpu-viv/libvulkan_VSI provides the vulkan ICD (installable client driver) for the Vivante GPU while libvulkan from vulkan_loader provides the vulkan_loader.

So we likely need both shared objects to use vulkan.

I guess the proper fix is to change the soname to something different, preferably in the upstream binary, until then by patching the shared object. I sent a pull request on github.


Max

Am Di., 1. Okt. 2019 um 22:30 Uhr schrieb <liu.ming50@...>:

From: Ming Liu <liu.ming50@...>

Installing the vulkan driver in ${D}${libdir}/vulkan subdirectory is
not a proper fix for the conflict with vulkan-loader. The root cause
of this conflict is that both our libvulkan and vulkan-loader's
libvulkan have a same soname libvulkan.so.1, we should set PRIVATE_LIBS
in this case to fix the conflict. Or else, the soname would still be
detected during package_do_shlibs, and hence will lead to other
dependency problems for the recipes that depending on vulkan-loader.

For instance, this patch fixes a following error:
| ERROR: gstreamer1.0-plugins-bad-1.14.imx-r0 do_package_qa:
| QA Issue: /usr/lib/gstreamer-1.0/libgstvulkan.so contained in package gstreamer1.0-plugins-bad-vulkan requires libvulkan.so.1()(64bit),
| but no providers found in RDEPENDS_gstreamer1.0-plugins-bad-vulkan? [file-rdeps]
| ERROR: gstreamer1.0-plugins-bad-1.14.imx-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.

Signed-off-by: Ming Liu <liu.ming50@...>
---
 recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc b/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc
index ef10c96..e75ada0 100644
--- a/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc
+++ b/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc
@@ -233,12 +233,7 @@ do_install () {
     ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so

     if [ "${IS_MX8}" = "1" ]; then
-        # Install the vulkan driver in a sub-folder. When installed in the same
-        # folder as the vulkan loader layer library, an incorrect linkage is
-        # created from libvulkan.so.1 to our library instead of the loader
-        # layer library.
-        install -d ${D}${libdir}/vulkan
-        mv ${D}${libdir}/libvulkan-${backend}.so ${D}${libdir}/vulkan/libvulkan_VSI.so
+        mv ${D}${libdir}/libvulkan-${backend}.so ${D}${libdir}/libvulkan_VSI${SOLIBS}
     fi
     for header in ${GLES3_HEADER_REMOVALS}; do
         rm -f ${D}${includedir}/GLES3/${header}
@@ -307,9 +302,9 @@ FILES_libgbm-imx_mx8           = "${libdir}/libgbm${SOLIBS} ${libdir}/gbm_viv${S
 FILES_libgbm-imx-dev_mx8       = "${libdir}/pkgconfig/gbm.pc ${includedir}/gbm.h ${libdir}/libgbm${SOLIBSDEV}"
 RDEPENDS_libgbm-imx_append_mx8 = " libdrm"

-FILES_libvulkan-imx = "${libdir}/vulkan/libvulkan_VSI${SOLIBS} ${libdir}/libSPIRV_viv${SOLIBS}"
-FILES_libvulkan-imx-dev = "${includedir}/vulkan ${libdir}/vulkan/libvulkan_VSI${SOLIBSDEV}"
-INSANE_SKIP_libvulkan-imx += "dev-deps dev-so"
+FILES_libvulkan-imx = "${libdir}/libvulkan_VSI${SOLIBS} ${libdir}/libSPIRV_viv${SOLIBS}"
+FILES_libvulkan-imx-dev = "${includedir}/vulkan"
+PRIVATE_LIBS_libvulkan-imx = "libvulkan.so.1"

 FILES_libopenvx-imx = "${libdir}/libOpenVX${SOLIBS} ${libdir}/libOpenVXC${SOLIBS} ${libdir}/libOpenVXU${SOLIBS}"
 FILES_libopenvx-imx-dev = "${includedir}/VX ${libdir}/libopenVX${SOLIBSDEV}"
--
2.7.4

--
_______________________________________________
meta-freescale mailing list
meta-freescale@...
https://lists.yoctoproject.org/listinfo/meta-freescale


[PATCH] imx-gpu-viv: fix libvulkan soname issue

liu.ming50@...
 

From: Ming Liu <liu.ming50@...>

Installing the vulkan driver in ${D}${libdir}/vulkan subdirectory is
not a proper fix for the conflict with vulkan-loader. The root cause
of this conflict is that both our libvulkan and vulkan-loader's
libvulkan have a same soname libvulkan.so.1, we should set PRIVATE_LIBS
in this case to fix the conflict. Or else, the soname would still be
detected during package_do_shlibs, and hence will lead to other
dependency problems for the recipes that depending on vulkan-loader.

For instance, this patch fixes a following error:
| ERROR: gstreamer1.0-plugins-bad-1.14.imx-r0 do_package_qa:
| QA Issue: /usr/lib/gstreamer-1.0/libgstvulkan.so contained in package gstreamer1.0-plugins-bad-vulkan requires libvulkan.so.1()(64bit),
| but no providers found in RDEPENDS_gstreamer1.0-plugins-bad-vulkan? [file-rdeps]
| ERROR: gstreamer1.0-plugins-bad-1.14.imx-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.

Signed-off-by: Ming Liu <liu.ming50@...>
---
recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc b/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc
index ef10c96..e75ada0 100644
--- a/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc
+++ b/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc
@@ -233,12 +233,7 @@ do_install () {
ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so

if [ "${IS_MX8}" = "1" ]; then
- # Install the vulkan driver in a sub-folder. When installed in the same
- # folder as the vulkan loader layer library, an incorrect linkage is
- # created from libvulkan.so.1 to our library instead of the loader
- # layer library.
- install -d ${D}${libdir}/vulkan
- mv ${D}${libdir}/libvulkan-${backend}.so ${D}${libdir}/vulkan/libvulkan_VSI.so
+ mv ${D}${libdir}/libvulkan-${backend}.so ${D}${libdir}/libvulkan_VSI${SOLIBS}
fi
for header in ${GLES3_HEADER_REMOVALS}; do
rm -f ${D}${includedir}/GLES3/${header}
@@ -307,9 +302,9 @@ FILES_libgbm-imx_mx8 = "${libdir}/libgbm${SOLIBS} ${libdir}/gbm_viv${S
FILES_libgbm-imx-dev_mx8 = "${libdir}/pkgconfig/gbm.pc ${includedir}/gbm.h ${libdir}/libgbm${SOLIBSDEV}"
RDEPENDS_libgbm-imx_append_mx8 = " libdrm"

-FILES_libvulkan-imx = "${libdir}/vulkan/libvulkan_VSI${SOLIBS} ${libdir}/libSPIRV_viv${SOLIBS}"
-FILES_libvulkan-imx-dev = "${includedir}/vulkan ${libdir}/vulkan/libvulkan_VSI${SOLIBSDEV}"
-INSANE_SKIP_libvulkan-imx += "dev-deps dev-so"
+FILES_libvulkan-imx = "${libdir}/libvulkan_VSI${SOLIBS} ${libdir}/libSPIRV_viv${SOLIBS}"
+FILES_libvulkan-imx-dev = "${includedir}/vulkan"
+PRIVATE_LIBS_libvulkan-imx = "libvulkan.so.1"

FILES_libopenvx-imx = "${libdir}/libOpenVX${SOLIBS} ${libdir}/libOpenVXC${SOLIBS} ${libdir}/libOpenVXU${SOLIBS}"
FILES_libopenvx-imx-dev = "${includedir}/VX ${libdir}/libopenVX${SOLIBSDEV}"
--
2.7.4


Re: Sumo bison error

Bas Mevissen
 

On 26-09-19 15:48, Mauro Ziliani wrote:
Hi all.
I'm trying sumo for imx6dlsabresd.
bitbake core-image-minimal give me this error
| ../bison-3.0.4/lib/fseterr.c:77:3: error: #error "Please port gnulib fseterr.c to your platform! Look at the definitions of ferror and clearerr on your system, then report this to bug-gnulib."
Maybe some goes wrong with bison
Your problem is most likely with the host system being too new. What do you use to build on?

This is local.conf
MACHINE ??= 'imx6qdlsabresd'
DISTRO ?= 'fslc-x11'
PACKAGE_CLASSES ?= "package_deb"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS ??= "\
    STOPTASKS,${TMPDIR},1G,100K \
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,${SSTATE_DIR},1G,100K \
    STOPTASKS,/tmp,100M,100K \
    ABORT,${TMPDIR},100M,1K \
    ABORT,${DL_DIR},100M,1K \
    ABORT,${SSTATE_DIR},100M,1K \
    ABORT,/tmp,10M,1K"
PACKAGECONFIG_append_pn-qemu-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
CONF_VERSION = "1"
DL_DIR ?= "${BSPDIR}/downloads/"
ACCEPT_FSL_EULA = "1"
Ans this bblayers.confLCONF_VERSION = "7"
BBPATH = "${TOPDIR}"
BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) + '/../..')}"
BBFILES ?= ""
BBLAYERS = " \
  ${BSPDIR}/sources/poky/meta \
  ${BSPDIR}/sources/poky/meta-poky \
  \
  ${BSPDIR}/sources/meta-openembedded/meta-oe \
  ${BSPDIR}/sources/meta-openembedded/meta-multimedia \
  \
  ${BSPDIR}/sources/meta-freescale \
  ${BSPDIR}/sources/meta-freescale-3rdparty \
  ${BSPDIR}/sources/meta-freescale-distro \
"
BBLAYERS += " \
  ${BSPDIR}/sources/meta-openembedded/meta-networking \
  ${BSPDIR}/sources/meta-openembedded/meta-python \
  ${BSPDIR}/sources/meta-qt5 \
"
Any idea?
Best regards.
  MZ


Sumo bison error

Mauro Ziliani
 

Hi all.

I'm trying sumo for imx6dlsabresd.

bitbake core-image-minimal give me this error

| ../bison-3.0.4/lib/fseterr.c:77:3: error: #error "Please port gnulib fseterr.c to your platform! Look at the definitions of ferror and clearerr on your system, then report this to bug-gnulib."

Maybe some goes wrong with bison


This is local.conf

MACHINE ??= 'imx6qdlsabresd'
DISTRO ?= 'fslc-x11'
PACKAGE_CLASSES ?= "package_deb"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS ??= "\
    STOPTASKS,${TMPDIR},1G,100K \
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,${SSTATE_DIR},1G,100K \
    STOPTASKS,/tmp,100M,100K \
    ABORT,${TMPDIR},100M,1K \
    ABORT,${DL_DIR},100M,1K \
    ABORT,${SSTATE_DIR},100M,1K \
    ABORT,/tmp,10M,1K"
PACKAGECONFIG_append_pn-qemu-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
CONF_VERSION = "1"

DL_DIR ?= "${BSPDIR}/downloads/"
ACCEPT_FSL_EULA = "1"


Ans this bblayers.confLCONF_VERSION = "7"

BBPATH = "${TOPDIR}"
BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) + '/../..')}"

BBFILES ?= ""
BBLAYERS = " \
  ${BSPDIR}/sources/poky/meta \
  ${BSPDIR}/sources/poky/meta-poky \
  \
  ${BSPDIR}/sources/meta-openembedded/meta-oe \
  ${BSPDIR}/sources/meta-openembedded/meta-multimedia \
  \
  ${BSPDIR}/sources/meta-freescale \
  ${BSPDIR}/sources/meta-freescale-3rdparty \
  ${BSPDIR}/sources/meta-freescale-distro \
"


BBLAYERS += " \
  ${BSPDIR}/sources/meta-openembedded/meta-networking \
  ${BSPDIR}/sources/meta-openembedded/meta-python \
  ${BSPDIR}/sources/meta-qt5 \
"

Any idea?


Best regards.

  MZ


Mailing list update September 15th - platform change delayed

Michael Halstead
 

This Sunday I will take the Mailman mailing lists offline for updates in
preparation for the platform change. As part of the update I plan to
change the list addresses to their new dedicated domain
@lists.yoctoproject.org so we can start changing addresses in the
MAINTAINERS files and elsewhere.

Moderators, thanks for helping by clearing out the queues in advance. If
you have outstanding moderation or trouble clearing your queue please
reach out to me.

I will send a follow up e-mail with a new time line for the platform
change after these updates are in place.

--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer


Mailing list platform change September 15th

Michael Halstead
 

We are moving our lists from Mailman to Groups.io. E-mail to lists will
be delayed during the move window on September 15th between 9:00 and
17:00 UTC.

A new account will be created for you on the Groups.io platform and most
users will only need to update their list mailing address from the
@yoctoproject.org to @lists.yoctoproject.org.

Moderators please attend to all pending requests next Friday Sept. 13th
before beginning your weekend.

Please read more about the change on the wiki:

https://wiki.yoctoproject.org/wiki/index.php?title=GroupsMigration

If there are serious issues we will rollback the changes. We will e-mail
all lists when work is complete.

--
Michael Halstead
Linux Foundation / SysAdmin


Re: Repo sync meta-freescale Errors Out

Bas Mevissen
 

On 9/6/19 11:29 AM, Bas Mevissen wrote:
On 9/5/19 5:29 PM, ArvindAnche wrote:
Hello Recepients,

I had created the below ticket:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=13499 <https://bugzilla.yoctoproject.org/show_bug.cgi?id=13499>


When I try to run below two commands:

repo init -u https://github.com/Angstrom-distribution/angstrom-manifest <https://github.com/Angstrom-distribution/angstrom-manifest> -b angstrom-v2018.12-thud

repo sync

Alternatively also tried the below two commands:

sudo sysctl -w net.ipv4.tcp_window_scaling=0

repo --trace sync -j1


But in both the cases I get below error message multiple times:

curl: (22) The requested URL returned error: 404 Not Found

Server does not provide clone.bundle; ignoring.
This can be safely ignored. (Google it for explanation)

: export GIT_DIR=/home/aanche/work/angstrom-build/.repo/projects/layers/meta-freescale.git

: git fetch --progress yocto --tags +refs/heads/*:refs/remotes/yocto/* +refs/heads/thud:refs/remotes/yocto/thud 1>| 2>|

remote: Counting objects: 30073, done.

remote: Compressing objects: 100% (9790/9790), done.

fatal: the remote end hung up unexpectedly72 MiB | 290.00 KiB/s

fatal: early EOF

fatal: index-pack failed
Here something happened, possibly with your internet connection.


: git fetch --progress yocto --tags +refs/heads/*:refs/remotes/yocto/* +refs/heads/thud:refs/remotes/yocto/thud 1>| 2>|

remote: Counting objects: 30073, done.

remote: Compressing objects: 100% (9790/9790), done.

fatal: the remote end hung up unexpectedly54 MiB | 250.00 KiB/s

fatal: early EOF

fatal: index-pack failed
Again. Flaky connection?

error: Cannot fetch meta-freescale from http://git.yoctoproject.org/git/meta-freescale <http://git.yoctoproject.org/git/meta-freescale>

: load refs /home/aanche/work/angstrom-build/.repo/projects/layers/meta-freescale.git

: git rev-parse --verify refs/remotes/yocto/thud^0 1>| 2>|


error: Exited sync due to fetch errors

The obvious result of the errors above.


So for this do you have any recommendations or work arounds? I am kind of stuck at this point for creating the Linux kernel image. It would be great if you could suggest an alternative.

Really appreciate your time and help.
Quickest seems to just erase everything and do it again. I just tried the init and sync on Linux Mint 9.2 (Ubuntu Bionic based) and it worked fine.
If it fails again, maybe it is in the tools version. I used:
$ repo --version
... A new repo command ( 1.25) is available.
... You should upgrade soon:
    cp /home/bas/Workspace/<...>/.repo/repo/repo /usr/bin/repo
repo version v1.13.5.1
       (from https://gerrit.googlesource.com/git-repo)
repo launcher version 1.23
       (from /usr/bin/repo)
git 2.17.1
Python 2.7.15+ (default, Nov 27 2018, 23:36:35)
[GCC 7.3.0]
Additional:

If it does not work, try doing the repo stuff in a container with a different Linux version. Or try a different internet connection. The Angstrom manifest README.md mentions the issue as well, but gives no clue about the root cause.

Please note: this problem is not specific to meta-freescale. It might be an incompatibility between the Yocto Git server and the Google repo tool. Best place to get help is probably from the maintainers of repo or contact the angstrom maintainers.




Thanks,

Arvind


-- bas.


Re: Repo sync meta-freescale Errors Out

Bas Mevissen
 

On 9/5/19 5:29 PM, ArvindAnche wrote:
Hello Recepients,
I had created the below ticket:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13499 <https://bugzilla.yoctoproject.org/show_bug.cgi?id=13499>
When I try to run below two commands:
repo init -u https://github.com/Angstrom-distribution/angstrom-manifest <https://github.com/Angstrom-distribution/angstrom-manifest> -b angstrom-v2018.12-thud
repo sync
Alternatively also tried the below two commands:
sudo sysctl -w net.ipv4.tcp_window_scaling=0
repo --trace sync -j1
But in both the cases I get below error message multiple times:
curl: (22) The requested URL returned error: 404 Not Found
Server does not provide clone.bundle; ignoring.
This can be safely ignored. (Google it for explanation)
: export GIT_DIR=/home/aanche/work/angstrom-build/.repo/projects/layers/meta-freescale.git
: git fetch --progress yocto --tags +refs/heads/*:refs/remotes/yocto/* +refs/heads/thud:refs/remotes/yocto/thud 1>| 2>|
remote: Counting objects: 30073, done.
remote: Compressing objects: 100% (9790/9790), done.
fatal: the remote end hung up unexpectedly72 MiB | 290.00 KiB/s
fatal: early EOF
fatal: index-pack failed
Here something happened, possibly with your internet connection.

: git fetch --progress yocto --tags +refs/heads/*:refs/remotes/yocto/* +refs/heads/thud:refs/remotes/yocto/thud 1>| 2>|
remote: Counting objects: 30073, done.
remote: Compressing objects: 100% (9790/9790), done.
fatal: the remote end hung up unexpectedly54 MiB | 250.00 KiB/s
fatal: early EOF
fatal: index-pack failed
Again. Flaky connection?

error: Cannot fetch meta-freescale from http://git.yoctoproject.org/git/meta-freescale <http://git.yoctoproject.org/git/meta-freescale>
: load refs /home/aanche/work/angstrom-build/.repo/projects/layers/meta-freescale.git
: git rev-parse --verify refs/remotes/yocto/thud^0 1>| 2>|
error: Exited sync due to fetch errors
The obvious result of the errors above.

So for this do you have any recommendations or work arounds? I am kind of stuck at this point for creating the Linux kernel image. It would be great if you could suggest an alternative.
Really appreciate your time and help.
Quickest seems to just erase everything and do it again. I just tried the init and sync on Linux Mint 9.2 (Ubuntu Bionic based) and it worked fine.

If it fails again, maybe it is in the tools version. I used:

$ repo --version

... A new repo command ( 1.25) is available.
... You should upgrade soon:

cp /home/bas/Workspace/<...>/.repo/repo/repo /usr/bin/repo

repo version v1.13.5.1
(from https://gerrit.googlesource.com/git-repo)
repo launcher version 1.23
(from /usr/bin/repo)
git 2.17.1
Python 2.7.15+ (default, Nov 27 2018, 23:36:35)
[GCC 7.3.0]



Thanks,
Arvind
-- bas.


Repo sync meta-freescale Errors Out

ArvindAnche
 

Hello Recepients, 

I had created the below ticket: 

https://bugzilla.yoctoproject.org/show_bug.cgi?id=13499


When I try to run below two commands: 

repo init -u https://github.com/Angstrom-distribution/angstrom-manifest -b angstrom-v2018.12-thud

repo sync

Alternatively also tried the below two commands: 

sudo sysctl -w net.ipv4.tcp_window_scaling=0

repo --trace sync -j1


But in both the cases I get below error message multiple times:

curl: (22) The requested URL returned error: 404 Not Found

Server does not provide clone.bundle; ignoring.


: export GIT_DIR=/home/aanche/work/angstrom-build/.repo/projects/layers/meta-freescale.git

: git fetch --progress yocto --tags +refs/heads/*:refs/remotes/yocto/* +refs/heads/thud:refs/remotes/yocto/thud 1>| 2>|

remote: Counting objects: 30073, done.        

remote: Compressing objects: 100% (9790/9790), done.        

fatal: the remote end hung up unexpectedly72 MiB | 290.00 KiB/s    

fatal: early EOF

fatal: index-pack failed

: git fetch --progress yocto --tags +refs/heads/*:refs/remotes/yocto/* +refs/heads/thud:refs/remotes/yocto/thud 1>| 2>|

remote: Counting objects: 30073, done.        

remote: Compressing objects: 100% (9790/9790), done.        

fatal: the remote end hung up unexpectedly54 MiB | 250.00 KiB/s   

fatal: early EOF

fatal: index-pack failed

error: Cannot fetch meta-freescale from http://git.yoctoproject.org/git/meta-freescale

: load refs /home/aanche/work/angstrom-build/.repo/projects/layers/meta-freescale.git

: git rev-parse --verify refs/remotes/yocto/thud^0 1>| 2>|


error: Exited sync due to fetch errors



So for this do you have any recommendations or work arounds? I am kind of stuck at this point for creating the Linux kernel image. It would be great if you could suggest an alternative. 

Really appreciate your time and help. 


Thanks,

Arvind



Does the path fix arm-oe-linux-gnueabi-gcc: not found?

JH
 

Hi,

Does the patch file
u-boot-imx-Fix-x86_64-linux-gnu-gcc-compilation-error.patch fix
arm-oe-linux-gnueabi-gcc as well? I manually patch it:

Anyway, I manually pached it, it does not work, I still have the same
error. I must do something wrong, please correct me:

- Downloaded a patch file
u-boot-imx-Fix-x86_64-linux-gnu-gcc-compilation-error.patch

- Run the u-boot-imx-Fix-x86_64-linux-gnu-gcc-compilation-error.patch
run it in meta-freescale

- It created 0001-tools-allow-to-override-python.patch, I added it
meta-freescale/recipes-bsp/u-boot/files

- Edit u-boot-imx_2017.03.bb
SRC_URI = "git://source.codeaurora.org/external/imx/uboot-imx.git;protocol=https;branch=${SRCBRANCH}
\
file://0001-tools-allow-to-override-python.patch \
"

Build gain, still have the error:
| /bin/sh: 1: arm-oe-linux-gnueabi-gcc: not found
| /build/Nand/build/tmp-glibc/work/solar-oe-linux-gnueabi/u-boot-imx/2017.03-r0/git/scripts/Makefile.autoconf:79:
recipe for target 'u-boot.cfg' failed


Yocto built p2020rdb ramdisk questions

Matt
 

Hi all,

 

I have questions regarding ramdisk built based on the core-image-minimal (poky sumo tag sumo-19.0.1 and meta-freescale sumo branch is used):

 

  1. How can I configure the available memory size to use for rootfs (either a larger fixed size or growing dynamically)?

The rootfs available size of the default Yocto build seems to be capped at around 24MB. See df and mount outputs below:

 

# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root               23795     21071      1496  93% /
devtmpfs             480492         0    480492   0% /dev
tmpfs                   516520        32    516488   0% /run
tmpfs                   516520        24    516496   0% /var/volatile

# mount
/dev/root on / type ext4 (rw,relatime,block_validity,delalloc,barrier,user_xattr)

  1. This may not be relevant to the problem, but good to know: My understanding is that the Yocto built ramdisk based on core-image-minimal uses initrd, not initramfs. Is this correct? How can I tell if a system uses initrd or initramfs?

Any help is greatly appreciated. Thank you in advance.

 


Re: Which u-boot for imx6dlsabresd in Pyro?

Mauro Ziliani
 

Ok.

Thanks

Il 29/08/19 11:25, Marco ha scritto:
Hi Mauro,
the meta-freescale for Pyro says
PREFERRED_PROVIDER_virtual/bootloader ??= "u-boot-fslc"

https://github.com/Freescale/fsl-community-bsp-platform/blob/pyro/default.xml
https://github.com/Freescale/meta-freescale/blob/pyro/conf/machine/include/imx-base.inc

--
Marco Cavallini | KOAN sas | Bergamo - Italia
embedded software engineering
https://KoanSoftware.com

Il giorno gio 22 ago 2019 alle ore 16:28 Mauro Ziliani
<mauro@...> ha scritto:
Hi all.

Which is the right u-boot for a imx6dlsabresd derived board and Pyro?T

The preferred is u-boot-fslc, but in Jethro/Krogoth was u-boot-imx

--
_______________________________________________
meta-freescale mailing list
meta-freescale@...
https://lists.yoctoproject.org/listinfo/meta-freescale


Re: Which u-boot for imx6dlsabresd in Pyro?

Marco <cavallini.koan@...>
 

Hi Mauro,
the meta-freescale for Pyro says
PREFERRED_PROVIDER_virtual/bootloader ??= "u-boot-fslc"

https://github.com/Freescale/fsl-community-bsp-platform/blob/pyro/default.xml
https://github.com/Freescale/meta-freescale/blob/pyro/conf/machine/include/imx-base.inc

--
Marco Cavallini | KOAN sas | Bergamo - Italia
embedded software engineering
https://KoanSoftware.com

Il giorno gio 22 ago 2019 alle ore 16:28 Mauro Ziliani
<mauro@...> ha scritto:

Hi all.

Which is the right u-boot for a imx6dlsabresd derived board and Pyro?T

The preferred is u-boot-fslc, but in Jethro/Krogoth was u-boot-imx

--
_______________________________________________
meta-freescale mailing list
meta-freescale@...
https://lists.yoctoproject.org/listinfo/meta-freescale


Re: linux-fslc-lts-4.19

Andy Pont
 

Andreas wrote...

FWIW - We use linux-fscl-lts for our products. That*s why I introduced
linux-fscl-lts. It is on variscite-som imx6 and am VERY happy about it
since using un-tailored sources (have to admit that our images do not
contain much of multimedia but that is not the focus of energy meter
devices exactly...). Starts that I can have X AND wayland in same
image / our Qt/QML applications perform at least as good with vivante.
And Qt/X11 updates do not cause pain anymore (not matching headers /
API changes).
The more I read on this and the more answers come in from people the more confused I am making myself. Let me explain the background to what I am trying to do to see if someone can give me an idiots guide!

I am using the i.MX6Q SABRE SDP as an evaluation platform prior to custom hardware being designed.  The front end is based on Cog and WPE Webkit using the i.MX6 wpebackend-rdk which, as I understand it, runs directly on top of the framebuffer but needs the GPU drivers.  We think that is the best implementation as it means we can dispense with all the overhead of X11, Wayland and Qt.

In my current build I have the following set in local.conf:

MACHINE = “imx6qdlsabresd”
DISTRO = "fslc-framebuffer”

IMAGE_INSTALL_append then includes (amongst other things): packagegroup-fsl-tools-gpu gstreamer1.0-plugins-imx gstreamer1.0-plugins-imx-meta based on (a probable misinterpretation) of the information that I got from [1].

Am I using the right setting for DISTRO?  Is there a difference between using fsl-framebuffer and fslc-framebuffer?  Should it just be the regular Poky?

-Andy.





Re: linux-fslc-lts-4.19

Andreas Müller
 

On Wed, Aug 28, 2019 at 9:30 PM Otavio Salvador
<otavio.salvador@...> wrote:

Hello Andy,

On Wed, Aug 28, 2019 at 3:57 PM Andy Pont <andy.pont@...> wrote:
The use of Linux mainline requires the use of 'use-mainline-bsp'
override. To do that, you can:

At local.conf add:

MACHINEOVERRIDES_append = ":use-mainline-bsp"

Or add it to your machine definition.

That just seems to cause too many problems with building the rest of the system. The first complaint was:

ERROR: Nothing RPROVIDES 'gstreamer1.0-plugins-imx’

If I remove that from the local.conf file then:

ERROR: Nothing PROVIDES 'imx-gpu-viv’

For the time being I think the jump from 4.9 to 4.19 is too big a jump. Is there an easy way to get closer to to 4.9.190 the current 4.9 LTS version?
Yes, it is. But it is managed by our packagegroups and like.

Likely your image uses them hardcoded. We are using 5.2.10 internally
for few customers.
FWIW - We use linux-fscl-lts for our products. That*s why I introduced
linux-fscl-lts. It is on variscite-som imx6 and am VERY happy about it
since using un-tailored sources (have to admit that our images do not
contain much of multimedia but that is not the focus of energy meter
devices exactly...). Starts that I can have X AND wayland in same
image / our Qt/QML applications perform at least as good with vivante.
And Qt/X11 updates do not cause pain anymore (not matching headers /
API changes).

Maybe [1] - helps to see what is required from kernel point of view
and: do not use imx-specific recipes/packagegroups: they fail and are
not necessary.

Cheers

Andreas

[1] https://github.com/Freescale/meta-freescale-3rdparty/blob/master/conf/machine/imx6qdl-variscite-som.conf


NXP Solo - GPU Error for Chromium Browser 67 on Rocko

Pravin Yadav
 

We ported Chromium 67 on IMX6 Solo Rocko build and we are facing some errors related to GPU. For testing purpose, we disabled the GPU and it works fine but its affect the performance so what could be the reason for such errors? Also many people’s found similar type of error on other platform and suggested to disable the GPU but in embedded Linux it costs performance badly.

 

 

ERROR:gles2_cmd_decoder.cc(4693)] [.DisplayCompositor-0x5cfc8900]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glClear: framebuffer incomplete (check)

[837:837:0823/134415.646701:ERROR:gles2_cmd_decoder.cc(4693)] [.DisplayCompositor-0x5cfc8900]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete (check)

[837:837:0823/134415.648250:ERROR:gles2_cmd_decoder.cc(4693)] [.DisplayCompositor-0x5cfc8900]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete (check)

:ERROR:gles2_cmd_decoder.cc(4693)] [.DisplayCompositor-0x5cfc8900]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete (check)

 

TexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134615.965943:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134616.513997:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134617.559371:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134618.082101:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

 

[837:837:0823/134614.788719:ERROR:texture_manager.cc(3421)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glTexImage2D: <- error from previous GL command

[837:837:0823/134615.399498:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134615.965943:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134616.513997:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

 

 

Kind Regards,
Pravin Yadav
 
Renu Electronics Private Limited /  www.renuelectronics.com
/
Offering Quality Products and Services  

 


NXP Solo - GPU Error for Chromium Browser 67 on Rocko

Pravin Yadav
 

We ported Chromium 67 on IMX6 Solo Rocko build and we are facing some errors related to GPU. For testing purpose, we disabled the GPU and it works fine but its affect the performance so what could be the reason for such errors? Also many people’s found similar type of error on other platform and suggested to disable the GPU but in embedded Linux it costs performance badly.

 

 

ERROR:gles2_cmd_decoder.cc(4693)] [.DisplayCompositor-0x5cfc8900]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glClear: framebuffer incomplete (check)

[837:837:0823/134415.646701:ERROR:gles2_cmd_decoder.cc(4693)] [.DisplayCompositor-0x5cfc8900]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete (check)

[837:837:0823/134415.648250:ERROR:gles2_cmd_decoder.cc(4693)] [.DisplayCompositor-0x5cfc8900]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete (check)

:ERROR:gles2_cmd_decoder.cc(4693)] [.DisplayCompositor-0x5cfc8900]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete (check)

 

TexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134615.965943:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134616.513997:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134617.559371:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134618.082101:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

 

[837:837:0823/134614.788719:ERROR:texture_manager.cc(3421)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glTexImage2D: <- error from previous GL command

[837:837:0823/134615.399498:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134615.965943:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134616.513997:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

 


Re: linux-fslc-lts-4.19

Otavio Salvador <otavio.salvador@...>
 

Hello Andy,

On Wed, Aug 28, 2019 at 3:57 PM Andy Pont <andy.pont@...> wrote:
The use of Linux mainline requires the use of 'use-mainline-bsp'
override. To do that, you can:

At local.conf add:

MACHINEOVERRIDES_append = ":use-mainline-bsp"

Or add it to your machine definition.

That just seems to cause too many problems with building the rest of the system. The first complaint was:

ERROR: Nothing RPROVIDES 'gstreamer1.0-plugins-imx’

If I remove that from the local.conf file then:

ERROR: Nothing PROVIDES 'imx-gpu-viv’

For the time being I think the jump from 4.9 to 4.19 is too big a jump. Is there an easy way to get closer to to 4.9.190 the current 4.9 LTS version?
Yes, it is. But it is managed by our packagegroups and like.

Likely your image uses them hardcoded. We are using 5.2.10 internally
for few customers.

--
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: linux-fslc-lts-4.19

Andy Pont
 

Otavio wrote….

The use of Linux mainline requires the use of 'use-mainline-bsp'
override. To do that, you can:
 
At local.conf add:
 
MACHINEOVERRIDES_append = ":use-mainline-bsp"
 
Or add it to your machine definition.
That just seems to cause too many problems with building the rest of the system. The first complaint was:

ERROR: Nothing RPROVIDES 'gstreamer1.0-plugins-imx’

If I remove that from the local.conf file then:

ERROR: Nothing PROVIDES 'imx-gpu-viv’

For the time being I think the jump from 4.9 to 4.19 is too big a jump. Is there an easy way to get closer to to 4.9.190 the current 4.9 LTS version?

-Andy.


Re: linux-fslc-lts-4.19

Otavio Salvador <otavio.salvador@...>
 

Hello Andy,

On Mon, Aug 19, 2019 at 7:08 AM Andy Pont <andy.pont@...> wrote:

I am trying to create a Yocto Warrior buid for the i.MX6Q SABRE SDP board that I have using the linux-fslc-lts-4.19 kernel. In my local.conf file I have the following:

MACHINE = “imx6qdlsabresd”
DISTRO = "fslc-framebuffer”

PREFERRED_PROVIDER_virtual/kernel = "linux-fslc-lts-4.19”
The use of Linux mainline requires the use of 'use-mainline-bsp'
override. To do that, you can:

At local.conf add:

MACHINEOVERRIDES_append = ":use-mainline-bsp"

Or add it to your machine definition.

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

821 - 840 of 24893