Re: [meta-ti] [EXTERNAL] Re: [PATCH] ti-sgx-ddk-um: update SRCREV to pick up Mesa-based EGL/GLES libraries

2019-10-31 Thread Ruei, Eric

Hi, Andrew, Gowtham and Denys:

What is our conclusion (solution) for the package size increment?

Best regards,

Eric

On 10/30/2019 10:58 AM, Andrew F. Davis wrote:

On 10/30/19 10:53 AM, Ruei, Eric wrote:

On 10/30/2019 9:53 AM, Tammana, Gowtham wrote:




-Original Message-
From: meta-ti-boun...@yoctoproject.org [mailto:meta-ti-
boun...@yoctoproject.org] On Behalf Of Davis, Andrew
Sent: Wednesday, October 30, 2019 8:36 AM
To: Ruei, Eric; Ruei, Eric; meta-ti@yoctoproject.org
Subject: [EXTERNAL] Re: [meta-ti] [PATCH] ti-sgx-ddk-um: update
SRCREV to pick
up Mesa-based EGL/GLES libraries

On 10/30/19 9:31 AM, Ruei, Eric wrote:

On 10/30/2019 9:22 AM, Andrew F. Davis wrote:

On 10/29/19 9:20 AM, Eric Ruei wrote:

This is the initial step toward Mesa-based EGL/GLES libraries which
support all the required EGL 1.5 extensions. We plan to provide a
Mesa-pvr recipe to build Mesa from source and SGX/DDK patches where
ti-sgx-ddk-um shall provide the EGL/GLES plugins only at the next
step.

Signed-off-by: Eric Ruei 
---
    recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb | 8
+---
    1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
index 7a6f013e..3991d917 100644
--- a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
+++ b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
@@ -11,7 +11,7 @@ PR = "r34"
    BRANCH = "ti-img-sgx/thud/${PV}"
      SRC_URI =
"git://git.ti.com/graphics/omap5-sgx-ddk-um-

linux.git;protocol=git;branch=${BRANCH}"


-SRCREV = "87d7e5c1e4db1bab048939c9719059d549c1e8dd"
+SRCREV = "2a2e5bb090ced870d73ed4edbc54793e952cc6d8"
      TARGET_PRODUCT_omap-a15 = "jacinto6evm"
    TARGET_PRODUCT_ti33x = "ti335x"
@@ -47,7 +47,9 @@ S = "${WORKDIR}/git"
      do_install () {
    oe_runmake install DESTDIR=${D}
TARGET_PRODUCT=${TARGET_PRODUCT}
-    ln -sf libGLESv2.so.${PV} ${D}${libdir}/libGLESv2.so.1
+    ln -sf libGLESv2.so ${D}${libdir}/libGLESv2.so.1
+
+    rm -rf ${D}${includedir}/GL



Why remove this?




There is another component provides GL header files.
Denys: how do we resolve this conflict?




The DSP OpenCL implementation? That package needs fixed, not this one,
the OpenGL implementation (this driver) should provide the GL headers.


We don't support desktop GL, they shouldn't come from this package.

Gowtham



Andrew:

Do you agree? I can keep the line here tentatively until GL is removed
from the package itself.




I still believe we should be shipping the GL headers in this package.
But I won't object to removing the headers temporarily using this recipe
until the conflicting ones can be removed from the OpenCL package.

Andrew



Eric







      chown -R root:root ${D}
    }
@@ -58,7 +60,7 @@ FILES_${PN} +=  "${includedir}/*"
    FILES_${PN} +=  "${sysconfdir}/*"
      PACKAGES =+ "${PN}-plugins"
-FILES_${PN}-plugins = "${libdir}/libsrv_init.so
${libdir}/libsrv_um.so ${libdir}/libglslcompiler.so
${libdir}/libPVRScopeServices.so ${libdir}/libGLESv2.so
${libdir}/libEGL.so ${libdir}/libGLES_CM.so
${libdir}/libpvrDRMWSEGL.so  ${libdir}/libpvrGBMWSEGL.so
${libdir}/libpvrws_WAYLAND.so"
+FILES_${PN}-plugins = "${libdir}/libsrv_init.so
${libdir}/libsrv_um.so ${libdir}/libglslcompiler.so
${libdir}/libPVRScopeServices.so ${libdir}/libGLESv2.so
${libdir}/libEGL.so ${libdir}/libGLESv1_CM.so ${libdir}/libGLES_CM.so
${libdir}/libGLESv1_PVR_MESA.so ${libdir}/libGLESv2_PVR_MESA.so"
    RDEPENDS_${PN} += "${PN}-plugins"



The newer binaries after the DDK commit "um: Attempt to load shared
object with version extension automatically" do not need all this
plugin
stuff, it can all be dropped.

Andrew



      ALLOW_EMPTY_${PN}-plugins = "1"




--
___
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti




--
___
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti


Re: [meta-ti] [EXTERNAL] Re: [PATCH] ti-sgx-ddk-um: update SRCREV to pick up Mesa-based EGL/GLES libraries

2019-10-30 Thread Ruei, Eric

Hi, guys:

Is there anything that we do regarding the large package size (1M to 8M)?

Best regards,

Eric

On 10/30/2019 11:06 AM, Denys Dmytriyenko wrote:

On Wed, Oct 30, 2019 at 10:58:31AM -0400, Andrew F. Davis wrote:

On 10/30/19 10:53 AM, Ruei, Eric wrote:

On 10/30/2019 9:53 AM, Tammana, Gowtham wrote:




-Original Message-
From: meta-ti-boun...@yoctoproject.org [mailto:meta-ti-
boun...@yoctoproject.org] On Behalf Of Davis, Andrew
Sent: Wednesday, October 30, 2019 8:36 AM
To: Ruei, Eric; Ruei, Eric; meta-ti@yoctoproject.org
Subject: [EXTERNAL] Re: [meta-ti] [PATCH] ti-sgx-ddk-um: update
SRCREV to pick
up Mesa-based EGL/GLES libraries

On 10/30/19 9:31 AM, Ruei, Eric wrote:

On 10/30/2019 9:22 AM, Andrew F. Davis wrote:

On 10/29/19 9:20 AM, Eric Ruei wrote:

This is the initial step toward Mesa-based EGL/GLES libraries which
support all the required EGL 1.5 extensions. We plan to provide a
Mesa-pvr recipe to build Mesa from source and SGX/DDK patches where
ti-sgx-ddk-um shall provide the EGL/GLES plugins only at the next
step.

Signed-off-by: Eric Ruei 
---
    recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb | 8
+---
    1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
index 7a6f013e..3991d917 100644
--- a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
+++ b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
@@ -11,7 +11,7 @@ PR = "r34"
    BRANCH = "ti-img-sgx/thud/${PV}"
      SRC_URI =
"git://git.ti.com/graphics/omap5-sgx-ddk-um-

linux.git;protocol=git;branch=${BRANCH}"


-SRCREV = "87d7e5c1e4db1bab048939c9719059d549c1e8dd"
+SRCREV = "2a2e5bb090ced870d73ed4edbc54793e952cc6d8"
      TARGET_PRODUCT_omap-a15 = "jacinto6evm"
    TARGET_PRODUCT_ti33x = "ti335x"
@@ -47,7 +47,9 @@ S = "${WORKDIR}/git"
      do_install () {
    oe_runmake install DESTDIR=${D}
TARGET_PRODUCT=${TARGET_PRODUCT}
-    ln -sf libGLESv2.so.${PV} ${D}${libdir}/libGLESv2.so.1
+    ln -sf libGLESv2.so ${D}${libdir}/libGLESv2.so.1
+
+    rm -rf ${D}${includedir}/GL



Why remove this?




There is another component provides GL header files.
Denys: how do we resolve this conflict?




The DSP OpenCL implementation? That package needs fixed, not this one,
the OpenGL implementation (this driver) should provide the GL headers.


We don't support desktop GL, they shouldn't come from this package.

Gowtham



Andrew:

Do you agree? I can keep the line here tentatively until GL is removed
from the package itself.




I still believe we should be shipping the GL headers in this package.
But I won't object to removing the headers temporarily using this recipe
until the conflicting ones can be removed from the OpenCL package.


Previously DDK only provided headers in these dirs: EGL, GLES, GLES2, KHR, gbm.

And OpenCL required GL headers, hence there was a "hacky" package created
specifically for that:
http://arago-project.org/git/?p=meta-arago.git;a=blob;f=meta-arago-extras/recipes-ti/ocl/ocl-gl-headers_git.bb;hb=HEAD

If DDK now properly provides GL headers, the other package can be dropped.

But the question remains - should DDK actually provide GL headers, even though
it doesn't provide full support for it?



--
___
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti


Re: [meta-ti] [EXTERNAL] Re: [PATCH] ti-sgx-ddk-um: update SRCREV to pick up Mesa-based EGL/GLES libraries

2019-10-30 Thread Ruei, Eric

On 10/30/2019 9:53 AM, Tammana, Gowtham wrote:




-Original Message-
From: meta-ti-boun...@yoctoproject.org [mailto:meta-ti-
boun...@yoctoproject.org] On Behalf Of Davis, Andrew
Sent: Wednesday, October 30, 2019 8:36 AM
To: Ruei, Eric; Ruei, Eric; meta-ti@yoctoproject.org
Subject: [EXTERNAL] Re: [meta-ti] [PATCH] ti-sgx-ddk-um: update SRCREV to pick
up Mesa-based EGL/GLES libraries

On 10/30/19 9:31 AM, Ruei, Eric wrote:

On 10/30/2019 9:22 AM, Andrew F. Davis wrote:

On 10/29/19 9:20 AM, Eric Ruei wrote:

This is the initial step toward Mesa-based EGL/GLES libraries which
support all the required EGL 1.5 extensions. We plan to provide a
Mesa-pvr recipe to build Mesa from source and SGX/DDK patches where
ti-sgx-ddk-um shall provide the EGL/GLES plugins only at the next step.

Signed-off-by: Eric Ruei 
---
   recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb | 8 +---
   1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
index 7a6f013e..3991d917 100644
--- a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
+++ b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
@@ -11,7 +11,7 @@ PR = "r34"
   BRANCH = "ti-img-sgx/thud/${PV}"
     SRC_URI =
"git://git.ti.com/graphics/omap5-sgx-ddk-um-

linux.git;protocol=git;branch=${BRANCH}"


-SRCREV = "87d7e5c1e4db1bab048939c9719059d549c1e8dd"
+SRCREV = "2a2e5bb090ced870d73ed4edbc54793e952cc6d8"
     TARGET_PRODUCT_omap-a15 = "jacinto6evm"
   TARGET_PRODUCT_ti33x = "ti335x"
@@ -47,7 +47,9 @@ S = "${WORKDIR}/git"
     do_install () {
   oe_runmake install DESTDIR=${D} TARGET_PRODUCT=${TARGET_PRODUCT}
-    ln -sf libGLESv2.so.${PV} ${D}${libdir}/libGLESv2.so.1
+    ln -sf libGLESv2.so ${D}${libdir}/libGLESv2.so.1
+
+    rm -rf ${D}${includedir}/GL



Why remove this?




There is another component provides GL header files.
Denys: how do we resolve this conflict?




The DSP OpenCL implementation? That package needs fixed, not this one,
the OpenGL implementation (this driver) should provide the GL headers.


We don't support desktop GL, they shouldn't come from this package.

Gowtham



Andrew:

Do you agree? I can keep the line here tentatively until GL is removed 
from the package itself.


Eric







     chown -R root:root ${D}
   }
@@ -58,7 +60,7 @@ FILES_${PN} +=  "${includedir}/*"
   FILES_${PN} +=  "${sysconfdir}/*"
     PACKAGES =+ "${PN}-plugins"
-FILES_${PN}-plugins = "${libdir}/libsrv_init.so
${libdir}/libsrv_um.so ${libdir}/libglslcompiler.so
${libdir}/libPVRScopeServices.so ${libdir}/libGLESv2.so
${libdir}/libEGL.so ${libdir}/libGLES_CM.so
${libdir}/libpvrDRMWSEGL.so  ${libdir}/libpvrGBMWSEGL.so
${libdir}/libpvrws_WAYLAND.so"
+FILES_${PN}-plugins = "${libdir}/libsrv_init.so
${libdir}/libsrv_um.so ${libdir}/libglslcompiler.so
${libdir}/libPVRScopeServices.so ${libdir}/libGLESv2.so
${libdir}/libEGL.so ${libdir}/libGLESv1_CM.so ${libdir}/libGLES_CM.so
${libdir}/libGLESv1_PVR_MESA.so ${libdir}/libGLESv2_PVR_MESA.so"
   RDEPENDS_${PN} += "${PN}-plugins"



The newer binaries after the DDK commit "um: Attempt to load shared
object with version extension automatically" do not need all this plugin
stuff, it can all be dropped.

Andrew



     ALLOW_EMPTY_${PN}-plugins = "1"




--
___
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti


--
___
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti


Re: [meta-ti] [PATCH] ti-sgx-ddk-um: update SRCREV to pick up Mesa-based EGL/GLES libraries

2019-10-30 Thread Ruei, Eric

On 10/30/2019 9:22 AM, Andrew F. Davis wrote:

On 10/29/19 9:20 AM, Eric Ruei wrote:

This is the initial step toward Mesa-based EGL/GLES libraries which
support all the required EGL 1.5 extensions. We plan to provide a
Mesa-pvr recipe to build Mesa from source and SGX/DDK patches where
ti-sgx-ddk-um shall provide the EGL/GLES plugins only at the next step.

Signed-off-by: Eric Ruei 
---
  recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb 
b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
index 7a6f013e..3991d917 100644
--- a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
+++ b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
@@ -11,7 +11,7 @@ PR = "r34"
  BRANCH = "ti-img-sgx/thud/${PV}"
  
  SRC_URI = "git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git;protocol=git;branch=${BRANCH}"

-SRCREV = "87d7e5c1e4db1bab048939c9719059d549c1e8dd"
+SRCREV = "2a2e5bb090ced870d73ed4edbc54793e952cc6d8"
  
  TARGET_PRODUCT_omap-a15 = "jacinto6evm"

  TARGET_PRODUCT_ti33x = "ti335x"
@@ -47,7 +47,9 @@ S = "${WORKDIR}/git"
  
  do_install () {

  oe_runmake install DESTDIR=${D} TARGET_PRODUCT=${TARGET_PRODUCT}
-ln -sf libGLESv2.so.${PV} ${D}${libdir}/libGLESv2.so.1
+ln -sf libGLESv2.so ${D}${libdir}/libGLESv2.so.1
+
+rm -rf ${D}${includedir}/GL



Why remove this?




There is another component provides GL header files.
Denys: how do we resolve this conflict?

Eric



  
  chown -R root:root ${D}

  }
@@ -58,7 +60,7 @@ FILES_${PN} +=  "${includedir}/*"
  FILES_${PN} +=  "${sysconfdir}/*"
  
  PACKAGES =+ "${PN}-plugins"

-FILES_${PN}-plugins = "${libdir}/libsrv_init.so ${libdir}/libsrv_um.so 
${libdir}/libglslcompiler.so ${libdir}/libPVRScopeServices.so ${libdir}/libGLESv2.so 
${libdir}/libEGL.so ${libdir}/libGLES_CM.so ${libdir}/libpvrDRMWSEGL.so  
${libdir}/libpvrGBMWSEGL.so  ${libdir}/libpvrws_WAYLAND.so"
+FILES_${PN}-plugins = "${libdir}/libsrv_init.so ${libdir}/libsrv_um.so 
${libdir}/libglslcompiler.so ${libdir}/libPVRScopeServices.so ${libdir}/libGLESv2.so 
${libdir}/libEGL.so ${libdir}/libGLESv1_CM.so ${libdir}/libGLES_CM.so 
${libdir}/libGLESv1_PVR_MESA.so ${libdir}/libGLESv2_PVR_MESA.so"
  RDEPENDS_${PN} += "${PN}-plugins"



The newer binaries after the DDK commit "um: Attempt to load shared
object with version extension automatically" do not need all this plugin
stuff, it can all be dropped.

Andrew


  
  ALLOW_EMPTY_${PN}-plugins = "1"




--
___
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti


Re: [meta-ti] [PATCH] ti-sgx-ddk-um: update SRCREV to pick up Mesa-based EGL/GLES libraries

2019-10-30 Thread Ruei, Eric

On 10/29/2019 7:29 PM, Denys Dmytriyenko wrote:

On Tue, Oct 29, 2019 at 09:20:20AM -0400, Eric Ruei wrote:

This is the initial step toward Mesa-based EGL/GLES libraries which
support all the required EGL 1.5 extensions. We plan to provide a
Mesa-pvr recipe to build Mesa from source and SGX/DDK patches where
ti-sgx-ddk-um shall provide the EGL/GLES plugins only at the next step.


Eric,

The new binaries are huge. The compressed package went from 900 KB to 8 MB in
size and now both AM3 and AM4 won't fit into allocated rootfs size...



Denys:

The Mesa-based GLES/EGL is much bigger. The major increase is caused by 
the new file pvr_dri.so (28M) under usr/lib/dri. The LibEGL related 
libraries are also increased from sub-200K to 1.1 M and there is another 
library libglapi.so (900k).


Eric



Signed-off-by: Eric Ruei 
---
  recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb 
b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
index 7a6f013e..3991d917 100644
--- a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
+++ b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
@@ -11,7 +11,7 @@ PR = "r34"
  BRANCH = "ti-img-sgx/thud/${PV}"
  
  SRC_URI = "git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git;protocol=git;branch=${BRANCH}"

-SRCREV = "87d7e5c1e4db1bab048939c9719059d549c1e8dd"
+SRCREV = "2a2e5bb090ced870d73ed4edbc54793e952cc6d8"
  
  TARGET_PRODUCT_omap-a15 = "jacinto6evm"

  TARGET_PRODUCT_ti33x = "ti335x"
@@ -47,7 +47,9 @@ S = "${WORKDIR}/git"
  
  do_install () {

  oe_runmake install DESTDIR=${D} TARGET_PRODUCT=${TARGET_PRODUCT}
-ln -sf libGLESv2.so.${PV} ${D}${libdir}/libGLESv2.so.1
+ln -sf libGLESv2.so ${D}${libdir}/libGLESv2.so.1
+
+rm -rf ${D}${includedir}/GL
  
  chown -R root:root ${D}

  }
@@ -58,7 +60,7 @@ FILES_${PN} +=  "${includedir}/*"
  FILES_${PN} +=  "${sysconfdir}/*"
  
  PACKAGES =+ "${PN}-plugins"

-FILES_${PN}-plugins = "${libdir}/libsrv_init.so ${libdir}/libsrv_um.so 
${libdir}/libglslcompiler.so ${libdir}/libPVRScopeServices.so ${libdir}/libGLESv2.so 
${libdir}/libEGL.so ${libdir}/libGLES_CM.so ${libdir}/libpvrDRMWSEGL.so  
${libdir}/libpvrGBMWSEGL.so  ${libdir}/libpvrws_WAYLAND.so"
+FILES_${PN}-plugins = "${libdir}/libsrv_init.so ${libdir}/libsrv_um.so 
${libdir}/libglslcompiler.so ${libdir}/libPVRScopeServices.so ${libdir}/libGLESv2.so 
${libdir}/libEGL.so ${libdir}/libGLESv1_CM.so ${libdir}/libGLES_CM.so 
${libdir}/libGLESv1_PVR_MESA.so ${libdir}/libGLESv2_PVR_MESA.so"
  RDEPENDS_${PN} += "${PN}-plugins"
  
  ALLOW_EMPTY_${PN}-plugins = "1"

--
2.17.1

--
___
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti


--
___
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti


Re: [meta-ti] [EXTERNAL] [thud/master][PATCH] ti-sgx-ddk-um: add RDEPENDS on ti-sgx-ddk-km

2019-06-11 Thread Ruei, Eric

On 6/11/2019 12:46 PM, Denys Dmytriyenko wrote:

From: Denys Dmytriyenko 

Signed-off-by: Denys Dmytriyenko 
---
  recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb 
b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
index 02c9b75..2afddfc 100644
--- a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
+++ b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
@@ -22,11 +22,11 @@ INITSCRIPT_PARAMS = "defaults 8"
  
  inherit update-rc.d
  
-PR = "r33"

+PR = "r34"
  PROVIDES += "virtual/egl virtual/libgles1 virtual/libgles2 
omap5-sgx-ddk-um-linux"
  
  DEPENDS += "libdrm udev libgbm wayland libffi"

-RDEPENDS_${PN} += "libdrm libudev libgbm wayland libffi libdrm-omap"
+RDEPENDS_${PN} += "ti-sgx-ddk-km libdrm libdrm-omap libudev libgbm wayland 
libffi"
  
  RPROVIDES_${PN} = "libegl libgles1 libgles2 omap5-sgx-ddk-um-linux"

  RPROVIDES_${PN}-dev = "libegl-dev libgles1-dev libgles2-dev 
omap5-sgx-ddk-um-linux-dev"


Hi, Denys:

Is it required? The ti-sgx-ddk-um cannot run without ti-sgx-ddk-km so 
that RDEPENDS makes sense. However, we currently build non-sgx image 
with ti-sgx-ddk-um, but without ti-sgx-ddk-km because we have not 
figured out a way to build Qt5 without openGL. The ti-sgx-ddk-um will 
not be invoked at run-time, but it is required at build time.


Best regards,

Eric

--
___
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti


Re: [meta-ti] [PATCH v4 0/3] Enable SGX on k3 (AM654x)

2018-07-14 Thread Ruei, Eric
Thank you very much!

Have a wonderful weekend!

Best regards,

Eric


-Original Message-
From: Dmytriyenko, Denys 
Sent: Friday, July 13, 2018 9:16 PM
To: Ruei, Eric
Cc: meta-ti@yoctoproject.org
Subject: Re: [meta-ti] [PATCH v4 0/3] Enable SGX on k3 (AM654x)

Thanks! Looks good now, I'll merge it.


On Fri, Jul 13, 2018 at 04:54:06PM -0400, Eric Ruei wrote:
> Enable SGX on k3 (AM654x)
> 
> Eric Ruei (3):
>   conf: machine: k3: enable sgx
>   ti-sgx-ddk-um: add k3 (AM654x) support
>   ti-sgx-ddk-km: add k3 (AM654x) support
> 
>  conf/machine/include/k3.inc|  4 ++--
>  ...14.3699939.bb => ti-sgx-ddk-km_1.17.4948957.bb} | 12 +---
>  .../libgles/ti-sgx-ddk-um_1.14.3699939.bb  |  1 +
>  ...14.3699939.bb => ti-sgx-ddk-um_1.17.4948957.bb} | 22 
> +-
>  4 files changed, 13 insertions(+), 26 deletions(-)
>  copy recipes-bsp/powervr-drivers/{ti-sgx-ddk-km_1.14.3699939.bb => 
> ti-sgx-ddk-km_1.17.4948957.bb} (73%)
>  copy recipes-graphics/libgles/{ti-sgx-ddk-um_1.14.3699939.bb => 
> ti-sgx-ddk-um_1.17.4948957.bb} (81%)
> 
> -- 
> 1.9.1
> 
> -- 
> ___
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti
-- 
___
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti


Re: [meta-ti] [PATCH v3 3/3] ti-sgx-ddk-km: add k3 (AM654x) support

2018-07-13 Thread Ruei, Eric
The kernel module is the same for all window system.
The DDK 1.17 provides three window systems (nulldrmws, wayland and org 
(default)).
 I can create the one for nulldrmws by export the environment variable 
WINDOW_SYSTEM=nulldrmws
Is there a way that I can do that at the recipe?

Best regards,

Eric



-Original Message-
From: Dmytriyenko, Denys 
Sent: Friday, July 13, 2018 3:15 PM
To: Ruei, Eric
Cc: meta-ti@yoctoproject.org
Subject: Re: [meta-ti] [PATCH v3 3/3] ti-sgx-ddk-km: add k3 (AM654x) support

On Fri, Jul 13, 2018 at 03:10:16PM -0400, Eric Ruei wrote:
> - add K3 (AM654x) support based on SGX DDK 1.17
> 
> Signed-off-by: Eric Ruei 
> ---
>  ...gx-ddk-km_1.14.3699939.bb => ti-sgx-ddk-km_1.17.4948957.bb} | 10 
> --
>  1 file changed, 4 insertions(+), 6 deletions(-)
>  copy recipes-bsp/powervr-drivers/{ti-sgx-ddk-km_1.14.3699939.bb => 
> ti-sgx-ddk-km_1.17.4948957.bb} (75%)
> 
> diff --git a/recipes-bsp/powervr-drivers/ti-sgx-ddk-km_1.14.3699939.bb 
> b/recipes-bsp/powervr-drivers/ti-sgx-ddk-km_1.17.4948957.bb
> similarity index 75%
> copy from recipes-bsp/powervr-drivers/ti-sgx-ddk-km_1.14.3699939.bb
> copy to recipes-bsp/powervr-drivers/ti-sgx-ddk-km_1.17.4948957.bb
> index a4eb82a..3ce9105 100644
> --- a/recipes-bsp/powervr-drivers/ti-sgx-ddk-km_1.14.3699939.bb
> +++ b/recipes-bsp/powervr-drivers/ti-sgx-ddk-km_1.17.4948957.bb
> @@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = 
> "file://eurasia_km/README;beginline=13;endline=22;md5=74506d9
>  
>  inherit module
>  
> -COMPATIBLE_MACHINE = "ti33x|ti43x|omap-a15"
> +COMPATIBLE_MACHINE = "k3"
>  
>  MACHINE_KERNEL_PR_append = "o"
>  PR = "${MACHINE_KERNEL_PR}"
> @@ -26,11 +26,9 @@ SRC_URI = 
> "git://git.ti.com/graphics/omap5-sgx-ddk-linux.git;protocol=git;branch
>  
>  S = "${WORKDIR}/git"
>  
> -SRCREV = "d2b3959738cfcc6209e8e882d1989de790866c8f"
> +SRCREV = "b630d462f5fbb86e5f98965ba1af35da1207822f"
>  
> -TARGET_PRODUCT_omap-a15 = "jacinto6evm"
> -TARGET_PRODUCT_ti33x = "ti335x"
> -TARGET_PRODUCT_ti43x = "ti437x"
> +TARGET_PRODUCT_k3 = "ti654x"
>  
>  EXTRA_OEMAKE += 'KERNELDIR="${STAGING_KERNEL_DIR}" 
> TARGET_PRODUCT=${TARGET_PRODUCT}'
>  
> @@ -39,5 +37,5 @@ do_compile_prepend() {
>  }
>  
>  do_install() {
> -make -C ${STAGING_KERNEL_DIR} 
> SUBDIRS=${B}/eurasia_km/eurasiacon/binary2_omap_linux_release/target/kbuild 
> INSTALL_MOD_PATH=${D} PREFIX=${STAGING_DIR_HOST} modules_install
> +make -C ${STAGING_KERNEL_DIR} 
> SUBDIRS=${B}/eurasia_km/eurasiacon/binary_omap_linux_xorg_release/target_aarch64/kbuild
>  INSTALL_MOD_PATH=${D} PREFIX=${STAGING_DIR_HOST} modules_install

BTW, are these binaries with X11 or Wayland support? I see path has xorg here 
^^^


>  }
> -- 
> 1.9.1
> 
> -- 
> ___
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti
-- 
___
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti


Re: [meta-ti] [PATCH v3 2/3] ti-sgx-ddk-um: add k3 (AM654x) support

2018-07-13 Thread Ruei, Eric
Got it finally.
V4 is coming.

Eric


-Original Message-
From: Dmytriyenko, Denys 
Sent: Friday, July 13, 2018 3:12 PM
To: Ruei, Eric
Cc: meta-ti@yoctoproject.org
Subject: Re: [meta-ti] [PATCH v3 2/3] ti-sgx-ddk-um: add k3 (AM654x) support

On Fri, Jul 13, 2018 at 03:10:15PM -0400, Eric Ruei wrote:
> - add COMPATIBLE_MACHINE to distinguish AM3/4/5 with K3 (AM654x)
> - add k3 support based on SGX DDK 1.17
> 
> Signed-off-by: Eric Ruei 
> ---
>  recipes-graphics/libgles/ti-sgx-ddk-um_1.14.3699939.bb  |  1 +
>  ...ddk-um_1.14.3699939.bb => ti-sgx-ddk-um_1.17.4948957.bb} | 13 
> +
>  2 files changed, 6 insertions(+), 8 deletions(-)
>  copy recipes-graphics/libgles/{ti-sgx-ddk-um_1.14.3699939.bb => 
> ti-sgx-ddk-um_1.17.4948957.bb} (87%)
> 
> diff --git a/recipes-graphics/libgles/ti-sgx-ddk-um_1.14.3699939.bb 
> b/recipes-graphics/libgles/ti-sgx-ddk-um_1.14.3699939.bb
> index d17411e..ef33d3a 100644
> --- a/recipes-graphics/libgles/ti-sgx-ddk-um_1.14.3699939.bb
> +++ b/recipes-graphics/libgles/ti-sgx-ddk-um_1.14.3699939.bb
> @@ -3,6 +3,7 @@ HOMEPAGE = 
> "https://git.ti.com/graphics/omap5-sgx-ddk-um-linux;
>  LICENSE = "TI-TSPA"
>  LIC_FILES_CHKSUM = 
> "file://TI-Linux-Graphics-DDK-UM-Manifest.doc;md5=550702a031857e0426ef7d6f6cf2d9f4"
>  
> +COMPATIBLE_MACHINE = "ti33x|ti43x|omap-a15"
>  PACKAGE_ARCH = "${MACHINE_ARCH}"
>  
>  BRANCH = "ti-img-sgx/rocko/${PV}"
> diff --git a/recipes-graphics/libgles/ti-sgx-ddk-um_1.14.3699939.bb 
> b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
> similarity index 87%
> copy from recipes-graphics/libgles/ti-sgx-ddk-um_1.14.3699939.bb
> copy to recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
> index d17411e..8ac772d 100644
> --- a/recipes-graphics/libgles/ti-sgx-ddk-um_1.14.3699939.bb
> +++ b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
> @@ -1,14 +1,16 @@
>  DESCRIPTION = "Userspace libraries for PowerVR SGX chipset on TI SoCs"
>  HOMEPAGE = "https://git.ti.com/graphics/omap5-sgx-ddk-um-linux;
>  LICENSE = "TI-TSPA"
> -LIC_FILES_CHKSUM = 
> "file://TI-Linux-Graphics-DDK-UM-Manifest.doc;md5=550702a031857e0426ef7d6f6cf2d9f4"
> +LIC_FILES_CHKSUM = 
> "file://TI-Linux-Graphics-DDK-UM-Manifest.doc;md5=b17390502bc89535c86cfbbae961a2a8"
> +
> +COMPATIBLE_MACHINE = "k3"
>  
>  PACKAGE_ARCH = "${MACHINE_ARCH}"
>  
>  BRANCH = "ti-img-sgx/rocko/${PV}"
>  
>  SRC_URI = 
> "git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git;protocol=git;branch=${BRANCH}"
> -SRCREV = "358fe42d34a7570896e5d1639869da564ddd0484"
> +SRCREV = "a564d20ec1b6aed55b3e60aa9ff35f3809eca110"
>  
>  # There's only hardfp version available
>  python __anonymous() {
> @@ -17,14 +19,9 @@ python __anonymous() {
>  return
>  pkgn = d.getVar("PN")
>  pkgv = d.getVar("PV")
> -if "callconvention-hard" not in tunes:
> -bb.warn("%s-%s ONLY supports hardfp mode for now" % (pkgn, pkgv))
> -raise bb.parse.SkipPackage("%s-%s ONLY supports hardfp mode for now" 
> % (pkgn, pkgv))

Please remove the anonymous function entirely - it's useless now.


>  }
>  
> -TARGET_PRODUCT_omap-a15 = "jacinto6evm"
> -TARGET_PRODUCT_ti33x = "ti335x"
> -TARGET_PRODUCT_ti43x = "ti437x"
> +TARGET_PRODUCT_k3 = "ti654x"
>  
>  INITSCRIPT_NAME = "rc.pvr"
>  INITSCRIPT_PARAMS = "defaults 8"
> -- 
> 1.9.1
> 
> -- 
> ___
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti
-- 
___
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti


Re: [meta-ti] [PATCH v2 0/3] Enable SGX on k3 (AM654x)

2018-07-13 Thread Ruei, Eric
I do not see any comments on this one.

Eric


-Original Message-
From: Dmytriyenko, Denys 
Sent: Friday, July 13, 2018 1:30 PM
To: Ruei, Eric
Cc: meta-ti@yoctoproject.org
Subject: Re: [meta-ti] [PATCH v2 0/3] Enable SGX on k3 (AM654x)

Eric,

Thanks for addressing most of my comments! This looks much better, but there 
are still couple issues - please see inside.


On Wed, Jul 11, 2018 at 11:45:28AM -0400, Eric Ruei wrote:
> Enable SGX on k3 (AM654x)
> 
> Eric Ruei (3):
>   conf: machine: k3: enable sgx
>   ti-sgx-ddk-um: add k3 (AM654x) support
>   ti-sgx-ddk-km: add k3 (AM654x) support
> 
>  conf/machine/include/k3.inc|  4 +-
>  .../powervr-drivers/ti-sgx-ddk-km_1.17.4948957.bb  | 92 
> ++
>  .../libgles/ti-sgx-ddk-um_1.14.3699939.bb  |  1 +
>  ...14.3699939.bb => ti-sgx-ddk-um_1.17.4948957.bb} | 10 +--
>  4 files changed, 33 insertions(+), 74 deletions(-)
>  copy recipes-graphics/libgles/ti-sgx-ddk-um_1.14.3699939.bb => 
> recipes-bsp/powervr-drivers/ti-sgx-ddk-km_1.17.4948957.bb (2%)
>  copy recipes-graphics/libgles/{ti-sgx-ddk-um_1.14.3699939.bb => 
> ti-sgx-ddk-um_1.17.4948957.bb} (93%)
> 
> -- 
> 1.9.1
> 
> -- 
> ___
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti
-- 
___
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti


Re: [meta-ti] [rocko/master][PATCH v3] ti-sgx-ddk-km: update SGX kernel driver for k4.14

2018-03-14 Thread Ruei, Eric
Hi, Denys:

I see that the v2 is in.
Should I submit this one on top of v2 as a new patch?

Best regards,

Eric


From: Dmytriyenko, Denys
Sent: Wednesday, March 14, 2018 8:51 PM
To: Ruei, Eric
Cc: meta-ti@yoctoproject.org
Subject: Re: [meta-ti] [rocko/master][PATCH v3] ti-sgx-ddk-km: update SGX 
kernel driver for k4.14

It's already in rocko/master - no rebases



On Mar 14, 2018 17:46, "Ruei, Eric" <e-ru...@ti.com<mailto:e-ru...@ti.com>> 
wrote:
From: Anand Balagopalakrishnan <ana...@ti.com<mailto:ana...@ti.com>>

Signed-off-by: Anand Balagopalakrishnan <ana...@ti.com<mailto:ana...@ti.com>>
Signed-off-by: Eric Ruei <e-ru...@ti.com<mailto:e-ru...@ti.com>>
---
 recipes-bsp/powervr-drivers/ti-sgx-ddk-km_1.14.3699939.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-bsp/powervr-drivers/ti-sgx-ddk-km_1.14.3699939.bb 
b/recipes-bsp/powervr-drivers/ti-sgx-ddk-km_1.14.3699939.bb
index 0303797..55f6b9b 100644
--- a/recipes-bsp/powervr-drivers/ti-sgx-ddk-km_1.14.3699939.bb
+++ b/recipes-bsp/powervr-drivers/ti-sgx-ddk-km_1.14.3699939.bb
@@ -20,7 +20,7 @@ RPROVIDES_${PN} = "omapdrm-pvr"
 RREPLACES_${PN} = "omapdrm-pvr"
 RCONFLICTS_${PN} = "omapdrm-pvr"

-BRANCH = "ti-img-sgx/${PV}/k4.9"
+BRANCH = "ti-img-sgx/${PV}/k4.14"

 SRC_URI = 
"git://git.ti.com/graphics/omap5-sgx-ddk-linux.git;protocol=git;branch=${BRANCH}
 \
 
file://0001-srvkm-common-devicemem.c-suppress-implicit-fallthrou.patch
 \
@@ -28,7 +28,7 @@ 
file://0001-srvkm-common-devicemem.c-suppress-implicit-fallthrou.patch
 \

 S = "${WORKDIR}/git"

-SRCREV = "0086977380d3320d70a3abc78b95fa0641427073"
+SRCREV = "b144fa4b97cb69e54cabaad62daffcd4b5497c29"

 TARGET_PRODUCT_omap-a15 = "jacinto6evm"
 TARGET_PRODUCT_ti33x = "ti335x"
--
1.9.1

--
___
meta-ti mailing list
meta-ti@yoctoproject.org<mailto:meta-ti@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/meta-ti
-- 
___
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti


Re: [meta-ti] [EXTERNAL] Re: Weston Desktop Shell

2018-02-12 Thread Ruei, Eric
Hi, Adam:

The problem shows as the following line.

[19:24:55.055] initializing drm backend
[19:24:55.091] using /dev/dri/card1

The SGX DDK creates another dri-like device as card1, but it should not be used 
as DRM device.

Please apply the following patch to the Weston build.
0001-udev-seat-restrict-udev-enumeration-to-card0.patch.

You may need other patches under 
meta-arago.meta-arago-distro/recipes-graphics/wayland/weston including
0002-Weston-Allow-visual_id-to-be-0.patch

Best regards,

Eric



From: meta-ti-boun...@yoctoproject.org 
[mailto:meta-ti-boun...@yoctoproject.org] On Behalf Of Adam Lee
Sent: Monday, February 12, 2018 11:04 AM
To: meta-ti@yoctoproject.org
Subject: [EXTERNAL] Re: [meta-ti] Weston Desktop Shell

I spent a bit of time getting the logs:

root@am57xx-evm:~# weston --backend=drm-backend.so --tty=4
Date: 2018-01-08 UTC
[19:24:55.053] weston 2.0.0
   http://wayland.freedesktop.org
   Bug reports to: 
https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland=weston=2.0.0
   Build: c26dbf3-dirty weston-launch: Provide a default version 
that doesn't require PAM (2018-02-09 11:58:14 -0500)
[19:24:55.053] Command line: weston --backend=drm-backend.so --tty=4
[19:24:55.053] OS: Linux, 4.9.69-g89d085d1a4, #10 SMP PREEMPT Thu Feb 8 
12:11:21 EST 2018, armv7l
[19:24:55.053] Using config file '/etc//weston.ini'
[19:24:55.054] Output repaint window is 7 ms maximum.
[19:24:55.054] Loading module '/usr/lib/libweston-2/drm-backend.so'
[19:24:55.055] initializing drm backend
[19:24:55.091] using /dev/dri/card1
[19:24:55.091] Loading module '/usr/lib/libweston-2/gl-renderer.so'
failed to load module: /usr/lib/gbm/gbm_dri.so: cannot open shared object file: 
No such file or directory
failed to load module: /usr/lib/gbm/gbm_gallium_drm.so: cannot open shared 
object file: No such file or directory
loaded module : gbm_pvr.so
found valid GBM backend : gbm_pvr.so
PVR:(Error): [ 1157-> 1157] <  gbm_pvr_create_device():592|ERROR> 
Failed to create DBM device: No such device [0, ]
[19:24:55.095] failed to initialize egl
[19:24:55.120] fatal: failed to create compositor backend

Any insight as to why this is happening, it would be much appreciated.

Adam

On Fri, Feb 9, 2018 at 3:26 PM Adam Lee 
> wrote:
Has anyone successfully brought up Weston desktop shell on the current master 
on Beagleboard X15 or AM57xx-EVM? I am having EGL initialization error. I don't 
know if it is something I have mis-configured.

BR,

Adam


0001-udev-seat-restrict-udev-enumeration-to-card0.patch
Description: 0001-udev-seat-restrict-udev-enumeration-to-card0.patch


0002-Weston-Allow-visual_id-to-be-0.patch
Description: 0002-Weston-Allow-visual_id-to-be-0.patch
-- 
___
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti


Re: [meta-ti] ti-sgx-ddk-um_1.14.3699939: check for wayland in DISTRO_FEATURES

2017-08-17 Thread Ruei, Eric
Hi, Denys:

Yes and yes, we do need the wayland  libraries to be present at the target file 
system because they are required by the SGX DDM UM binaries. 
The SGX DDK UM supports the following three (EGL) window systems and 
auto-detect which one should be used.
libpvrDRMWSEGL.so: EGLFS (Raw)
libpvrGBMWSEGL.so: Wayland-Server, DRM owner such as kmscube, or QT QPA 
EGLFS_KMS.
libpvrws_WAYLAND.so: Wayland Client

Best regards,

Eric

-Original Message-
From: Dmytriyenko, Denys 
Sent: Thursday, August 17, 2017 12:14 PM
To: Ruei, Eric
Cc: Ankur Tyagi; meta-ti@yoctoproject.org; R, Karthik
Subject: Re: [meta-ti] ti-sgx-ddk-um_1.14.3699939: check for wayland in 
DISTRO_FEATURES

Thanks, Eric,

As I was suspecting, wayland libs are required to be present for SGX to work 
even in no-Wayland mode. Good thing OE detects those .so dependencies and 
automatically pulls them in for you.

Have you tried removing Wayland pieces from the rootfs after the fact? I'm 
guessing SGX would stop working due to dynamic linker/loader not being able to 
resolve all the dependencies hardcoded in .so...

--
Denys


On Thu, Aug 17, 2017 at 12:02:27PM -0400, Ruei, Eric wrote:
> Hi, Denys:
> 
> Yes, we can make PLSDK image with Weston disabled by removing wayland from 
> the DISTRO_FEATURES list.
> Conf/local.conf:
> DISTRO_FEATURES_remove = "wayland"
> 
> Therefore QT will use eglfs as the default QPA.
> 
> However, some of the wayland related libraries and components are still 
> present at the target file system.
> There is no need to update ti-sgx-ddk-um_1.14.3699939 recipe and SGX should 
> work by using libpvrDRMWSEGL.so.
> 
> Best regards,
> 
> Eric
> 
> 
> -Original Message-
> From: Dmytriyenko, Denys 
> Sent: Wednesday, August 16, 2017 4:15 PM
> To: Ankur Tyagi
> Cc: meta-ti@yoctoproject.org; Ruei, Eric; R, Karthik
> Subject: Re: [meta-ti] ti-sgx-ddk-um_1.14.3699939: check for wayland in 
> DISTRO_FEATURES
> 
> +Eric and Karthik.
> 
> On Sat, Aug 12, 2017 at 02:10:50PM +1200, Ankur Tyagi wrote:
> > So even if I added "wayland" in DISTRO_FEATURES_remove, it would still 
> > be packaged in resulting image.
> > 
> > I don't want to use x11, wayland and have also configured Qt to use 
> > eglfs qpa. But it seems wayland will be used anyhow. Am I correct ?
> 
> I suspect it will try to link/load the needed wayland libs, but I haven't 
> tried it myself.
> 
> 
> Eric,
> 
> Since you've been playing with eglfs lately, can you please confirm/clarify 
> whether SGX can work w/o Wayland?
> 
> 
> > Old branch (daisy) was not having such dependency on wayland, may I know
> > why it is now ?
> 
> The old 3D Graphics SDK supported 2 modes - X11 and raw FB. We haven't 
> supported X11 for years. The new SGX DDK binaries are mostly for Wayland 
> graphics stack, as far as I know, since that's what we support on our 
> platforms.
> 
> 
> Karthik,
> 
> Anything you want to add or clarify here?
> 
> -- 
> Denys
> 
> 
> > On Sat, Aug 12, 2017 at 8:07 AM, Denys Dmytriyenko <de...@ti.com> wrote:
> > 
> > > No, it's not an optional dependency, unfortunately:
> > >
> > > $ for i in lib*.so.*.*.*; do echo $i; arm-linux-gnueabihf-readelf -a $i |
> > > grep wayland; done
> > > libdbm.so.1.14.3699939
> > >  0x0001 (NEEDED) Shared library:
> > > [libwayland-server.so.0]
> > > libEGL.so.1.14.3699939
> > >  0x0001 (NEEDED) Shared library:
> > > [libwayland-server.so.0]
> > > libGLES_CM.so.1.14.3699939
> > >  0x0001 (NEEDED) Shared library:
> > > [libwayland-server.so.0]
> > > libGLESv2.so.1.14.3699939
> > >  0x0001 (NEEDED) Shared library:
> > > [libwayland-server.so.0]
> > > libglslcompiler.so.1.14.3699939
> > >  0x0001 (NEEDED) Shared library:
> > > [libwayland-server.so.0]
> > > libIMGegl.so.1.14.3699939
> > >  0x0001 (NEEDED) Shared library:
> > > [libwayland-server.so.0]
> > > 23: f715 4 FUNCGLOBAL DEFAULT   11
> > > wayland_drm_buffer_get_fo
> > > 39: f6f926 FUNCGLOBAL DEFAULT   11 wayland_drm_uninit
> > > 91: f66d56 FUNCGLOBAL DEFAULT   11 wayland_drm_buffer_get
> > >119: f6a584 FUNCGLOBAL DEFAULT   11 wayland_drm_init
> > >123: f719 4 FUNCGLOBAL DEFAULT   11
> > > wayland_drm_buffer_get_bu
> > > libpvr2d.so.1.14.3699939
> > >  0x0001 (NEEDED) Shared library

Re: [meta-ti] ti-sgx-ddk-um_1.14.3699939: check for wayland in DISTRO_FEATURES

2017-08-17 Thread Ruei, Eric
Hi, Denys:

Yes, we can make PLSDK image with Weston disabled by removing wayland from the 
DISTRO_FEATURES list.
Conf/local.conf:
DISTRO_FEATURES_remove = "wayland"

Therefore QT will use eglfs as the default QPA.

However, some of the wayland related libraries and components are still present 
at the target file system.
There is no need to update ti-sgx-ddk-um_1.14.3699939 recipe and SGX should 
work by using libpvrDRMWSEGL.so.

Best regards,

Eric


-Original Message-
From: Dmytriyenko, Denys 
Sent: Wednesday, August 16, 2017 4:15 PM
To: Ankur Tyagi
Cc: meta-ti@yoctoproject.org; Ruei, Eric; R, Karthik
Subject: Re: [meta-ti] ti-sgx-ddk-um_1.14.3699939: check for wayland in 
DISTRO_FEATURES

+Eric and Karthik.

On Sat, Aug 12, 2017 at 02:10:50PM +1200, Ankur Tyagi wrote:
> So even if I added "wayland" in DISTRO_FEATURES_remove, it would still 
> be packaged in resulting image.
> 
> I don't want to use x11, wayland and have also configured Qt to use 
> eglfs qpa. But it seems wayland will be used anyhow. Am I correct ?

I suspect it will try to link/load the needed wayland libs, but I haven't tried 
it myself.


Eric,

Since you've been playing with eglfs lately, can you please confirm/clarify 
whether SGX can work w/o Wayland?


> Old branch (daisy) was not having such dependency on wayland, may I know
> why it is now ?

The old 3D Graphics SDK supported 2 modes - X11 and raw FB. We haven't 
supported X11 for years. The new SGX DDK binaries are mostly for Wayland 
graphics stack, as far as I know, since that's what we support on our 
platforms.


Karthik,

Anything you want to add or clarify here?

-- 
Denys


> On Sat, Aug 12, 2017 at 8:07 AM, Denys Dmytriyenko <de...@ti.com> wrote:
> 
> > No, it's not an optional dependency, unfortunately:
> >
> > $ for i in lib*.so.*.*.*; do echo $i; arm-linux-gnueabihf-readelf -a $i |
> > grep wayland; done
> > libdbm.so.1.14.3699939
> >  0x0001 (NEEDED) Shared library:
> > [libwayland-server.so.0]
> > libEGL.so.1.14.3699939
> >  0x0001 (NEEDED) Shared library:
> > [libwayland-server.so.0]
> > libGLES_CM.so.1.14.3699939
> >  0x0001 (NEEDED) Shared library:
> > [libwayland-server.so.0]
> > libGLESv2.so.1.14.3699939
> >  0x0001 (NEEDED) Shared library:
> > [libwayland-server.so.0]
> > libglslcompiler.so.1.14.3699939
> >  0x0001 (NEEDED) Shared library:
> > [libwayland-server.so.0]
> > libIMGegl.so.1.14.3699939
> >  0x0001 (NEEDED) Shared library:
> > [libwayland-server.so.0]
> > 23: f715 4 FUNCGLOBAL DEFAULT   11
> > wayland_drm_buffer_get_fo
> > 39: f6f926 FUNCGLOBAL DEFAULT   11 wayland_drm_uninit
> > 91: f66d56 FUNCGLOBAL DEFAULT   11 wayland_drm_buffer_get
> >119: f6a584 FUNCGLOBAL DEFAULT   11 wayland_drm_init
> >123: f719 4 FUNCGLOBAL DEFAULT   11
> > wayland_drm_buffer_get_bu
> > libpvr2d.so.1.14.3699939
> >  0x0001 (NEEDED) Shared library:
> > [libwayland-server.so.0]
> > libpvrDRMWSEGL.so.1.14.3699939
> >  0x0001 (NEEDED) Shared library:
> > [libwayland-server.so.0]
> > libpvrGBMWSEGL.so.1.14.3699939
> >  0x0001 (NEEDED) Shared library:
> > [libwayland-server.so.0]
> > libPVRScopeServices.so.1.14.3699939
> >  0x0001 (NEEDED) Shared library:
> > [libwayland-server.so.0]
> > libpvr_wlegl.so.1.14.3699939
> >  0x0001 (NEEDED) Shared library:
> > [libwayland-server.so.0]
> >  0x0001 (NEEDED) Shared library:
> > [libwayland-client.so.0]
> > libpvrws_WAYLAND.so.1.14.3699939
> >  0x0001 (NEEDED) Shared library:
> > [libwayland-server.so.0]
> >  0x0001 (NEEDED) Shared library:
> > [libwayland-client.so.0]
> > libsrv_init.so.1.14.3699939
> >  0x0001 (NEEDED) Shared library:
> > [libwayland-server.so.0]
> > libsrv_um.so.1.14.3699939
> >  0x0001 (NEEDED) Shared library:
> > [libwayland-server.so.0]
> > libusc.so.1.14.3699939
> >  0x0001 (NEEDED) Shared library:
> > [libwayland-server.so.0]
> >
> > --
> > Denys
> >
> >
> > On Fri, Aug 11, 2017 at 12:47:24AM +1200, Ankur Tyagi wrote:
> > > Signed-off-by: Ankur Tyagi <ankur.tyag...@gmail.com>
> > > ---
> > >  recipes-graphics/libgles/ti-sgx-ddk-um_1.14.3699939.

Re: [meta-ti] [krogoth][PATCH 3/3] gstreamer1.0-plugins-bad: waylandsink: add input format I420 support

2017-03-16 Thread Ruei, Eric
Nak
Denys: can you ignore this series? I meant to send to meta-arago.

Eric


-Original Message-
From: meta-ti-boun...@yoctoproject.org 
[mailto:meta-ti-boun...@yoctoproject.org] On Behalf Of Ruei, Eric
Sent: Thursday, March 16, 2017 1:27 PM
To: meta-ti@yoctoproject.org
Subject: [meta-ti] [krogoth][PATCH 3/3] gstreamer1.0-plugins-bad: waylandsink: 
add input format I420 support

Signed-off-by: Eric Ruei <e-ru...@ti.com>
---
 ...waylandsink-add-input-format-I420-support.patch | 89 ++
 .../gstreamer1.0-plugins-bad_1.6.3.bbappend|  2 +
 2 files changed, 91 insertions(+)
 create mode 100644 
meta-arago-extras/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-gstwaylandsink-add-input-format-I420-support.patch

diff --git 
a/meta-arago-extras/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-gstwaylandsink-add-input-format-I420-support.patch
 
b/meta-arago-extras/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-gstwaylandsink-add-input-format-I420-support.patch
new file mode 100644
index 000..c4bf4b1
--- /dev/null
+++ b/meta-arago-extras/recipes-multimedia/gstreamer/gstreamer1.0-plugin
+++ s-bad/0001-gstwaylandsink-add-input-format-I420-support.patch
@@ -0,0 +1,89 @@
+From 4d04ea92f196b9e0880917cf029a95c9ebef0ea9 Mon Sep 17 00:00:00 2001
+From: Eric Ruei <e-ru...@ti.com>
+Date: Wed, 22 Feb 2017 10:49:01 -0500
+Subject: [PATCH] gstwaylandsink: add input format I420 support
+
+The software-based video decoder produces the output in I420 format. To 
+display the output without additional ARM MHz consumed in video format 
+conversion, the function gst_wl_memory_construct_wl_buffer is enhanced to 
support I420 format.
+
+Signed-off-by: Eric Ruei <e-ru...@ti.com>
+---
+ ext/wayland/wldrm.c | 41 ++---
+ 1 file changed, 34 insertions(+), 7 deletions(-)
+
+diff --git a/ext/wayland/wldrm.c b/ext/wayland/wldrm.c index 
+8f2c393..cb2b0f2 100644
+--- a/ext/wayland/wldrm.c
 b/ext/wayland/wldrm.c
+@@ -5,33 +5,60 @@
+ #include 
+ #include 
+ 
++GST_DEBUG_CATEGORY_EXTERN (gstwayland_debug); #define GST_CAT_DEFAULT 
++gstwayland_debug
++
++
+ struct wl_buffer *
+ gst_wl_drm_memory_construct_wl_buffer (GstMemory * mem, GstWlDisplay * 
display,
+ const GstVideoInfo * info)
+ {
+   gint video_width = GST_VIDEO_INFO_WIDTH (info);
+   gint video_height = GST_VIDEO_INFO_HEIGHT (info);
++  GstVideoFormat format = GST_VIDEO_INFO_FORMAT (info);
+   int fd = -1;
+   struct omap_bo *bo;
+   struct wl_buffer *buffer;
+-
+-  /* TODO get format, etc from caps.. and query device for
+-   * supported formats, and make this all more flexible to
+-   * cope with various formats:
+-   */
+-  uint32_t fourcc = GST_MAKE_FOURCC ('N', 'V', '1', '2');
++  uint32_t fourcc;
+   uint32_t name;
+   /* note: wayland and mesa use the terminology:
+*stride - rowstride in bytes
+*pitch  - rowstride in pixels
+*/
+   uint32_t strides[3] = {
+-GST_ROUND_UP_4 (video_width), GST_ROUND_UP_4 (video_width), 0,
++GST_ROUND_UP_4 (video_width), 0, 0,
+   };
+   uint32_t offsets[3] = {
+ 0, strides[0] * video_height, 0
+   };
+ 
++  if (format == GST_VIDEO_FORMAT_NV12)  {
++/* NV12 */
++fourcc = GST_MAKE_FOURCC ('N', 'V', '1', '2');
++strides[1] = GST_ROUND_UP_4 (video_width);  }  else if(format == 
++ GST_VIDEO_FORMAT_I420)  {
++/* YUV420 */
++fourcc = GST_MAKE_FOURCC ('Y', 'U', '1', '2');
++strides[1] = strides[2] = GST_ROUND_UP_4 (video_width/2);
++offsets[2] = offsets[1] + strides[1] * video_height/2;  }  else  {
++
++GST_DEBUG ("Unsupported video format: %d", format);
++/*
++ * There are two xRGB frames with width and height = 1 required in the 
begining of a video stream.
++ * If we consider them as errot, then it will case libwayland-clent.so 
crashes
++ * due to invalid error handling.
++ * Consider them as NV12 until we can figure out a better solution
++ */
++fourcc = GST_MAKE_FOURCC ('N', 'V', '1', '2');
++strides[1] = GST_ROUND_UP_4 (video_width);  }
++
+   fd = gst_fd_memory_get_fd (mem);
+ 
+   if (fd < 0 ) {
+--
+1.9.1
+
diff --git 
a/meta-arago-extras/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.6.3.bbappend
 
b/meta-arago-extras/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.6.3.bbappend
index 317b19e..bbd1d99 100644
--- 
a/meta-arago-extras/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.6.3.bbappend
+++ b/meta-arago-extras/recipes-multimedia/gstreamer/gstreamer1.0-plugin
+++ s-bad_1.6.3.bbappend
@@ -22,11 +22,13 @@ DEPENDS_append_ti33x = " \
 SRC_URI_append_omap-a15 = " \
 file://0001-kmssink-remove-DCE-dependencies.patch \
 file://0002-kmssink-add-YUYV-support.patch \
+file://0001-gstwaylandsink-add-input-format-I420-support.patch \
 "
 
 SRC_URI_append_ti43x = " \
 file://0001-kmssink-remove-DCE-dependencies.patch \
 file://0002-kmssink-add-YUYV-

Re: [meta-ti] ti-sgx-ddk-um / do_install failed / cp: cannot stat './targetfs//etc/*': No such file or directory

2017-01-04 Thread Ruei, Eric

Hi, All:

I try beaglebone and it does work.
MACHINE=beaglebone bitbake ti-sgx-ddk-um

Best regards,

Eric

-Original Message-
From: meta-ti-boun...@yoctoproject.org 
[mailto:meta-ti-boun...@yoctoproject.org] On Behalf Of Dmytriyenko, Denys
Sent: Wednesday, January 04, 2017 12:20 PM
To: Benjamin Bimmermann
Cc: meta-ti@yoctoproject.org
Subject: Re: [meta-ti] ti-sgx-ddk-um / do_install failed / cp: cannot stat 
'./targetfs//etc/*': No such file or directory

On Wed, Jan 04, 2017 at 08:32:47AM +, Benjamin Bimmermann wrote:
> Hello,
> 
> I'm trying to build the ti-sgx-ddk-for the AM33x.
> I've tried to build the Krogoth and the morty branch, but both failed.
> A few months ago I had this error yet. I also do not understand which files 
> he would like to copy, but not find.
> I have attached an extract from my log.

Try changing MACHINE from "beaglebone" to "am335x-evm".

-- 
Denys


> Thank you for your attentionBimmermann
> 
> 
> --
>  
> log.do_install.19908
> Log data follows:
> | DEBUG: Executing shell function do_install
> | NOTE: make -j7 install 
> DESTDIR=/home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image
>  TARGET_PRODUCT=
> | mkdir -p 
> /home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image/etc
> | mkdir -p 
> /home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image/usr/bin
> | mkdir -p 
> /home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image/usr/include
> | mkdir -p 
> /home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image/usr/lib
> | cp -ar ./targetfs//etc/* 
> /home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image/etc
> | cp: cannot stat './targetfs//etc/*': No such file or directory
> | Makefile:14: recipe for target 'install' failed
> | make: *** [install] Error 1
> | ERROR: oe_runmake failed
> | ERROR: Function failed: do_install (log file is located at 
> /home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/temp/log.do_install.19908)
> NOTE: recipe ti-sgx-ddk-um-1.14.3699939-r19: task do_install: Failed
> ERROR: Task 843 
> (/home/bimmermann/poky-krogoth/meta-ti/recipes-graphics/libgles/ti-sgx-ddk-um_1.14.3699939.bb,
>  do_install) failed with exit code '1'
> NOTE: Running task 2572 of 3217 (ID: 830, 
> /home/bimmermann/poky-krogoth/meta-BBB_QT5_PSS/meta-BBB_QT5_PSS/recipes-extras/thermal-init/thermal-init.bb,
>  do_install)
> --
> Build Configuration:
> BB_VERSION    = "1.30.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "Ubuntu-16.04"
> TARGET_SYS    = "arm-poky-linux-gnueabi"
> MACHINE   = "beaglebone"
> DISTRO    = "poky"
> DISTRO_VERSION    = "2.1.2"
> TUNE_FEATURES = "arm armv7a vfp thumb neon   callconvention-hard"
> TARGET_FPU    = "hard"
> meta-ti   = "krogoth:8663e1611ab6c5bfe36d323d9d9db4dada4bd532"
> meta-qt5  = "krogoth:2b1871f0d139dc3caaa779a32a1931409c245a36"
> meta-oe    = "krogoth:55c8a76da5dc099a7bc3838495c672140cedb78e"
> meta  
> meta-yocto    = "krogoth:ae9b341ecfcc60e970f29cfe04306411ad26c0cf"
> --

> -- 
> ___
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

-- 
___
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti
-- 
___
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti


Re: [meta-ti] ti-sgx-ddk-um / do_install failed / cp: cannot stat './targetfs//etc/*': No such file or directory

2017-01-04 Thread Ruei, Eric
Hi, Benjamin:

It looks like that the SOC_FAMILY is not set to “ti33x” for some reason.
Therefore the TARGET_PRODUCT is not set as shown below:

TARGET_PRODUCT_omap-a15 = "jacinto6evm"
TARGET_PRODUCT_ti33x = "ti335x"
TARGET_PRODUCT_ti43x = "ti437x"

Here is a sample log of DDK UM install.

DEBUG: Executing shell function do_install
NOTE: make -j 8 install 
DESTDIR=/home/a0850410/yocto_builds/sdk320_am4/oe-layersetup/build/arago-tmp-external-linaro-toolchain/work/am437x_evm-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19.tisdk1/image
 TARGET_PRODUCT=ti437x
mkdir -p 
/home/a0850410/yocto_builds/sdk320_am4/oe-layersetup/build/arago-tmp-external-linaro-toolchain/work/am437x_evm-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19.tisdk1/image/etc
mkdir -p 
/home/a0850410/yocto_builds/sdk320_am4/oe-layersetup/build/arago-tmp-external-linaro-toolchain/work/am437x_evm-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19.tisdk1/image/usr/bin
mkdir -p 
/home/a0850410/yocto_builds/sdk320_am4/oe-layersetup/build/arago-tmp-external-linaro-toolchain/work/am437x_evm-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19.tisdk1/image/usr/include
mkdir -p 
/home/a0850410/yocto_builds/sdk320_am4/oe-layersetup/build/arago-tmp-external-linaro-toolchain/work/am437x_evm-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19.tisdk1/image/usr/lib
cp -ar ./targetfs/ti437x/etc/* 
/home/a0850410/yocto_builds/sdk320_am4/oe-layersetup/build/arago-tmp-external-linaro-toolchain/work/am437x_evm-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19.tisdk1/image/etc
cp -ar ./targetfs/ti437x/bin/* 
/home/a0850410/yocto_builds/sdk320_am4/oe-layersetup/build/arago-tmp-external-linaro-toolchain/work/am437x_evm-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19.tisdk1/image/usr/bin
cp -ar ./targetfs/ti437x/include/* 
/home/a0850410/yocto_builds/sdk320_am4/oe-layersetup/build/arago-tmp-external-linaro-toolchain/work/am437x_evm-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19.tisdk1/image/usr/include
cp -ar ./targetfs/ti437x/lib/* 
/home/a0850410/yocto_builds/sdk320_am4/oe-layersetup/build/arago-tmp-external-linaro-toolchain/work/am437x_evm-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19.tisdk1/image/usr/lib
DEBUG: Shell function do_install finished

For the beagle board, it should be ti335x.

Best regards,

Eric




From: meta-ti-boun...@yoctoproject.org 
[mailto:meta-ti-boun...@yoctoproject.org] On Behalf Of Benjamin Bimmermann
Sent: Wednesday, January 04, 2017 3:33 AM
To: meta-ti@yoctoproject.org
Subject: [meta-ti] ti-sgx-ddk-um / do_install failed / cp: cannot stat 
'./targetfs//etc/*': No such file or directory

Hello,



I'm trying to build the ti-sgx-ddk-for the AM33x.

I've tried to build the Krogoth and the morty branch, but both failed.

A few months ago I had this error yet. I also do not understand which files he 
would like to copy, but not find.

I have attached an extract from my log.





Thank you for your attention
Bimmermann





--

log.do_install.19908
Log data follows:
| DEBUG: Executing shell function do_install
| NOTE: make -j7 install 
DESTDIR=/home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image
 TARGET_PRODUCT=
| mkdir -p 
/home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image/etc
| mkdir -p 
/home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image/usr/bin
| mkdir -p 
/home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image/usr/include
| mkdir -p 
/home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image/usr/lib
| cp -ar ./targetfs//etc/* 
/home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image/etc
| cp: cannot stat './targetfs//etc/*': No such file or directory
| Makefile:14: recipe for target 'install' failed
| make: *** [install] Error 1
| ERROR: oe_runmake failed
| ERROR: Function failed: do_install (log file is located at 
/home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/temp/log.do_install.19908)
NOTE: recipe ti-sgx-ddk-um-1.14.3699939-r19: task do_install: Failed
ERROR: Task 843 
(/home/bimmermann/poky-krogoth/meta-ti/recipes-graphics/libgles/ti-sgx-ddk-um_1.14.3699939.bb,
 do_install) failed with exit code '1'
NOTE: Running task 2572 of 3217 (ID: 830, 
/home/bimmermann/poky-krogoth/meta-BBB_QT5_PSS/meta-BBB_QT5_PSS/recipes-extras/thermal-init/thermal-init.bb,
 do_install)