Re: [yocto] etnaviv image

[Trevor Woerner]

w00t!!

It took a lot of hacking, but I was able to build and run an image for
the wandboard dual that uses etnaviv :-D

Patches to follow.

I now have 4 dev boards using open-source graphics:
1) rpi3-32 with vc4
2) dragonboard-410c with freedreno
3) minnow (turbot) with Intel's stuff
4) wandboard with etnaviv

glmark2-es2:

root@wandboard:~# glmark2-es2; cat /proc/loadavg
===
glmark2 2014.03
===
OpenGL Information
GL_VENDOR: etnaviv
GL_RENDERER:   Gallium 0.4 on Vivante GC880 rev 5106
GL_VERSION:OpenGL ES 2.0 Mesa 17.0.4
===
[build] use-vbo=false: FPS: 69 FrameTime: 14.493 ms
[build] use-vbo=true: FPS: 80 FrameTime: 12.500 ms
[texture] texture-filter=nearest: FPS: 68 FrameTime: 14.706 ms
[texture] texture-filter=linear: FPS: 68 FrameTime: 14.706 ms
[texture] texture-filter=mipmap: FPS: 66 FrameTime: 15.152 ms
[shading] shading=gouraud: FPS: 70 FrameTime: 14.286 ms
[shading] shading=blinn-phong-inf: FPS: 61 FrameTime: 16.393 ms
[shading] shading=phong: FPS: 47 FrameTime: 21.277 ms
[shading] shading=cel: FPS: 39 FrameTime: 25.641 ms
[bump] bump-render=high-poly: FPS: 52 FrameTime: 19.231 ms
[bump] bump-render=normals: FPS: 67 FrameTime: 14.925 ms
[bump] bump-render=height: FPS: 60 FrameTime: 16.667 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 32 FrameTime: 31.250 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 14 FrameTime: 71.429 ms
[pulsar] light=false:quads=5:texture=false: FPS: 61 FrameTime: 16.393 ms
libpng warning: iCCP: known incorrect sRGB profile
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
FPS: 67 FrameTime: 14.925 ms
Error: RenderObject::init: glCheckFramebufferStatus failed (0x8cdd)
libpng warning: iCCP: known incorrect sRGB profile
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
[desktop] effect=shadow:windows=4: FPS: 68 FrameTime: 14.706 ms
[buffer] 
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map:
FPS: 29 FrameTime: 34.483 ms
[buffer] 
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata:
FPS: 29 FrameTime: 34.483 ms
[buffer] 
columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map:
FPS: 31 FrameTime: 32.258 ms
[ideas] speed=duration:[ 2797.051681] etnaviv-gpu 13.gpu:
hangcheck detected gpu lockup!
[ 2797.059575] etnaviv-gpu 13.gpu:  completed fence: 50513
[ 2797.065622] etnaviv-gpu 13.gpu:  active fence: 50514
[ 2797.072346] etnaviv-gpu 13.gpu: hangcheck recover!
[ 2800.011603] etnaviv-gpu 13.gpu: hangcheck detected gpu lockup!
[ 2800.017890] etnaviv-gpu 13.gpu:  completed fence: 50514
[ 2800.023895] etnaviv-gpu 13.gpu:  active fence: 50515
[ 2800.029752] etnaviv-gpu 13.gpu: hangcheck recover!
[ 2803.051591] etnaviv-gpu 13.gpu: hangcheck detected gpu lockup!
[ 2803.057899] etnaviv-gpu 13.gpu:  completed fence: 50516
[ 2803.063874] etnaviv-gpu 13.gpu:  active fence: 50518
[ 2803.069702] etnaviv-gpu 13.gpu: hangcheck recover!
[ 2805.531626] etnaviv-gpu 13.gpu: hangcheck detected gpu lockup!
[ 2805.537973] etnaviv-gpu 13.gpu:  completed fence: 50518
[ 2805.544052] etnaviv-gpu 13.gpu:  active fence: 50520
[ 2805.551826] etnaviv-gpu 13.gpu: hangcheck recover!
 FPS: 0 FrameTime: inf ms
[jellyfish] : FPS: 28 FrameTime: 35.714 ms
[terrain] : FPS: 2 FrameTime: 500.000 ms
[shadow] : FPS: 30 FrameTime: 33.333 ms
Error: DistanceRenderTarget::setup: glCheckFramebufferStatus failed (0x8cdd)
Error: Failed to set up the render target for the depth pass
[refract] : Set up failed
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 61 FrameTime: 16.393 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 31 FrameTime: 32.258 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 62 FrameTime: 16.

Re: [yocto] etnaviv image

[Gary Thomas]

On 2017-05-25 10:48, Trevor Woerner wrote:

w00t!!

It took a lot of hacking, but I was able to build and run an image for
the wandboard dual that uses etnaviv :-D

Patches to follow.

I now have 4 dev boards using open-source graphics:
1) rpi3-32 with vc4
2) dragonboard-410c with freedreno
3) minnow (turbot) with Intel's stuff
4) wandboard with etnaviv


Would you mind sharing your configuration (conf/local.conf, conf/bblayers.conf)?
I'm mostly interested in trying this on my RaspberryPi3.

Thanks



glmark2-es2:

root@wandboard:~# glmark2-es2; cat /proc/loadavg
===
 glmark2 2014.03
===
 OpenGL Information
 GL_VENDOR: etnaviv
 GL_RENDERER:   Gallium 0.4 on Vivante GC880 rev 5106
 GL_VERSION:OpenGL ES 2.0 Mesa 17.0.4
===
[build] use-vbo=false: FPS: 69 FrameTime: 14.493 ms
[build] use-vbo=true: FPS: 80 FrameTime: 12.500 ms
[texture] texture-filter=nearest: FPS: 68 FrameTime: 14.706 ms
[texture] texture-filter=linear: FPS: 68 FrameTime: 14.706 ms
[texture] texture-filter=mipmap: FPS: 66 FrameTime: 15.152 ms
[shading] shading=gouraud: FPS: 70 FrameTime: 14.286 ms
[shading] shading=blinn-phong-inf: FPS: 61 FrameTime: 16.393 ms
[shading] shading=phong: FPS: 47 FrameTime: 21.277 ms
[shading] shading=cel: FPS: 39 FrameTime: 25.641 ms
[bump] bump-render=high-poly: FPS: 52 FrameTime: 19.231 ms
[bump] bump-render=normals: FPS: 67 FrameTime: 14.925 ms
[bump] bump-render=height: FPS: 60 FrameTime: 16.667 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 32 FrameTime: 31.250 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 14 FrameTime: 71.429 ms
[pulsar] light=false:quads=5:texture=false: FPS: 61 FrameTime: 16.393 ms
libpng warning: iCCP: known incorrect sRGB profile
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
FPS: 67 FrameTime: 14.925 ms
Error: RenderObject::init: glCheckFramebufferStatus failed (0x8cdd)
libpng warning: iCCP: known incorrect sRGB profile
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
[desktop] effect=shadow:windows=4: FPS: 68 FrameTime: 14.706 ms
[buffer] 
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map:
FPS: 29 FrameTime: 34.483 ms
[buffer] 
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata:
FPS: 29 FrameTime: 34.483 ms
[buffer] 
columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map:
FPS: 31 FrameTime: 32.258 ms
[ideas] speed=duration:[ 2797.051681] etnaviv-gpu 13.gpu:
hangcheck detected gpu lockup!
[ 2797.059575] etnaviv-gpu 13.gpu:  completed fence: 50513
[ 2797.065622] etnaviv-gpu 13.gpu:  active fence: 50514
[ 2797.072346] etnaviv-gpu 13.gpu: hangcheck recover!
[ 2800.011603] etnaviv-gpu 13.gpu: hangcheck detected gpu lockup!
[ 2800.017890] etnaviv-gpu 13.gpu:  completed fence: 50514
[ 2800.023895] etnaviv-gpu 13.gpu:  active fence: 50515
[ 2800.029752] etnaviv-gpu 13.gpu: hangcheck recover!
[ 2803.051591] etnaviv-gpu 13.gpu: hangcheck detected gpu lockup!
[ 2803.057899] etnaviv-gpu 13.gpu:  completed fence: 50516
[ 2803.063874] etnaviv-gpu 13.gpu:  active fence: 50518
[ 2803.069702] etnaviv-gpu 13.gpu: hangcheck recover!
[ 2805.531626] etnaviv-gpu 13.gpu: hangcheck detected gpu lockup!
[ 2805.537973] etnaviv-gpu 13.gpu:  completed fence: 50518
[ 2805.544052] etnaviv-gpu 13.gpu:  active fence: 50520
[ 2805.551826] etnaviv-gpu 13.gpu: hangcheck recover!
  FPS: 0 FrameTime: inf ms
[jellyfish] : FPS: 28 FrameTime: 35.714 ms
[terrain] : FPS: 2 FrameTime: 500.000 ms
[shadow] : FPS: 30 FrameTime: 33.333 ms
Error: DistanceRenderTarget::setup: glCheckFramebufferStatus failed (0x8cdd)
Error: Failed to set up the render target for the depth pass
[refract] : Set up failed
[conditionals] fragment

Re: [yocto] etnaviv image

[Trevor Woerner]

On Thu, May 25, 2017 at 5:01 AM, Gary Thomas  wrote:
> Would you mind sharing your configuration (conf/local.conf,
> conf/bblayers.conf)?
> I'm mostly interested in trying this on my RaspberryPi3.

Absolutely!

I'm hoping to do a couple blog posts about it soon-ish showing
comparative results of glmark2-es2
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] etnaviv image

[Fabien Lahoudere]

On Thu, 2017-05-25 at 11:01 +0200, Gary Thomas wrote:
> On 2017-05-25 10:48, Trevor Woerner wrote:
> > w00t!!
> > 
> > It took a lot of hacking, but I was able to build and run an image for
> > the wandboard dual that uses etnaviv :-D
> > 
> > Patches to follow.
> > 
> > I now have 4 dev boards using open-source graphics:
> > 1) rpi3-32 with vc4
> > 2) dragonboard-410c with freedreno
> > 3) minnow (turbot) with Intel's stuff
> > 4) wandboard with etnaviv
> 
> Would you mind sharing your configuration (conf/local.conf, 
> conf/bblayers.conf)?
> I'm mostly interested in trying this on my RaspberryPi3.
> 

I do this on rpi3 and it works fine.
https://fabienlahouderepro.blogspot.fr/2017/03/building-weston-image-with-yocto-for.html

> Thanks
> 
> > 
> > glmark2-es2:
> > 
> > root@wandboard:~# glmark2-es2; cat /proc/loadavg
> > ===
> >  glmark2 2014.03
> > ===
> >  OpenGL Information
> >  GL_VENDOR: etnaviv
> >  GL_RENDERER:   Gallium 0.4 on Vivante GC880 rev 5106
> >  GL_VERSION:OpenGL ES 2.0 Mesa 17.0.4
> > ===
> > [build] use-vbo=false: FPS: 69 FrameTime: 14.493 ms
> > [build] use-vbo=true: FPS: 80 FrameTime: 12.500 ms
> > [texture] texture-filter=nearest: FPS: 68 FrameTime: 14.706 ms
> > [texture] texture-filter=linear: FPS: 68 FrameTime: 14.706 ms
> > [texture] texture-filter=mipmap: FPS: 66 FrameTime: 15.152 ms
> > [shading] shading=gouraud: FPS: 70 FrameTime: 14.286 ms
> > [shading] shading=blinn-phong-inf: FPS: 61 FrameTime: 16.393 ms
> > [shading] shading=phong: FPS: 47 FrameTime: 21.277 ms
> > [shading] shading=cel: FPS: 39 FrameTime: 25.641 ms
> > [bump] bump-render=high-poly: FPS: 52 FrameTime: 19.231 ms
> > [bump] bump-render=normals: FPS: 67 FrameTime: 14.925 ms
> > [bump] bump-render=height: FPS: 60 FrameTime: 16.667 ms
> > libpng warning: iCCP: known incorrect sRGB profile
> > [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 32 FrameTime: 31.250 ms
> > libpng warning: iCCP: known incorrect sRGB profile
> > [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 14 FrameTime: 71.429 
> > ms
> > [pulsar] light=false:quads=5:texture=false: FPS: 61 FrameTime: 16.393 ms
> > libpng warning: iCCP: known incorrect sRGB profile
> > Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> > Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> > Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> > Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> > Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> > Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> > [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
> > FPS: 67 FrameTime: 14.925 ms
> > Error: RenderObject::init: glCheckFramebufferStatus failed (0x8cdd)
> > libpng warning: iCCP: known incorrect sRGB profile
> > Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> > Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> > Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> > Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> > Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> > Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> > Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> > Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> > [desktop] effect=shadow:windows=4: FPS: 68 FrameTime: 14.706 ms
> > [buffer] 
> > columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-
> > method=map:
> > FPS: 29 FrameTime: 34.483 ms
> > [buffer] 
> > columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-
> > method=subdata:
> > FPS: 29 FrameTime: 34.483 ms
> > [buffer] 
> > columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-
> > method=map:
> > FPS: 31 FrameTime: 32.258 ms
> > [ideas] speed=duration:[ 2797.051681] etnaviv-gpu 13.gpu:
> > hangcheck detected gpu lockup!
> > [ 2797.059575] etnaviv-gpu 13.gpu:  completed fence: 50513
> > [ 2797.065622] etnaviv-gpu 13.gpu:  active fence: 50514
> > [ 2797.072346] etnaviv-gpu 13.gpu: hangcheck recover!
> > [ 2800.011603] etnaviv-gpu 13.gpu: hangcheck detected gpu lockup!
> > [ 2800.017890] etnaviv-gpu 13.gpu:  completed fence: 50514
> > [ 2800.023895] etnaviv-gpu 13.gpu:  active fence: 50515
> > [ 2800.029752] etnaviv-gpu 13.gpu: hangcheck recover!
> > [ 2803.051591] etnaviv-gpu 13.gpu: hangcheck detected gpu lockup!
> > [ 2803.057899] etnaviv-gpu 13.gpu:  completed fence: 50516
> > [ 2803.063874] etnaviv-gpu 13.gpu:  active fence: 50518
> > [ 2803.069702] etnaviv-gpu 13.gpu: hangcheck recover!
> > [ 2805.531626] etnaviv-gpu 13.gpu: hangche

Re: [yocto] [meta-cgl][PATCH] core-image-cgl: Remove ROOTFS_PKGMANAGE_BOOTSTRAP

[Adrian Dudau]

It's been merged already:)

--Adrian


From: Alexandru Vaduva [vaduvajanalexan...@yahoo.com]
Sent: Thursday, May 25, 2017 10:28 AM
To: Adrian Dudau; yocto@yoctoproject.org
Subject: Re: [yocto] [meta-cgl][PATCH] core-image-cgl: Remove 
ROOTFS_PKGMANAGE_BOOTSTRAP

Looks good to me ;)
Can you also please push upstream the following patch: [yocto] 
[meta-cgl][PATCH] meta-cgl-common: remove dependency on meta-openclovis

Thanks,
Alex V.


On Wednesday, May 24, 2017, 3:25:34 PM GMT+3, Adrian Dudau 
 wrote:
run-postinsts is now installed by default in image.bbclass, so no need
to include it in each image.

Signed-off-by: Adrian Dudau 
mailto:adrian.du...@enea.com>>
---
meta-cgl-common/images/core-image-cgl-initramfs.bb | 2 +-
meta-cgl-common/images/core-image-cgl.bb  | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta-cgl-common/images/core-image-cgl-initramfs.bb 
b/meta-cgl-common/images/core-image-cgl-initramfs.bb
index 2ebbdf5..477f069 100644
--- a/meta-cgl-common/images/core-image-cgl-initramfs.bb
+++ b/meta-cgl-common/images/core-image-cgl-initramfs.bb
@@ -3,7 +3,7 @@ require core-image-cgl.bb
# Recipe is based on core-image-minimal.bb
DESCRIPTION = "Initramfs used to mount multipath device as root file system"

-PACKAGE_INSTALL = "initramfs-cgl-boot busybox base-passwd udev 
${ROOTFS_BOOTSTRAP_INSTALL}"
+PACKAGE_INSTALL = "initramfs-cgl-boot busybox base-passwd udev"

# Do not pollute the initrd image with rootfs features
IMAGE_FEATURES = ""
diff --git a/meta-cgl-common/images/core-image-cgl.bb 
b/meta-cgl-common/images/core-image-cgl.bb
index 7117493..86bf7d4 100644
--- a/meta-cgl-common/images/core-image-cgl.bb
+++ b/meta-cgl-common/images/core-image-cgl.bb
@@ -10,7 +10,6 @@ VALGRIND_armv7a ?= "valgrind"

# Include modules in rootfs
IMAGE_INSTALL += "\
-${ROOTFS_PKGMANAGE_BOOTSTRAP} \
packagegroup-core-buildessential \
packagegroup-core-selinux \
packagegroup-cgl \
--
2.7.4

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

Re: [yocto] Can Yocto treat layers like an external package?

[Koehler, Yannick (HPN Aruba)]

So far all reply seems to indicate that the fetching and retrieval of 
additional layers is not a bitbake problem and should be handled with external 
tools.

In my view, I fail to see how fetching a layer is different than fetching 
sources from a particular package.

There is in my opinion two kind of layers people will encounter:

  Private layers:
  Layer own by the current developer and likely to be heavily modified with new 
recipe of override of existing recipes.

  Vendor layers:
  Third-party layers, which normally should be use as is (without modification).

The case I am mostly interested about is the Vendor layers, if I pull in 
meta-openembedded or meta-freescale in my yocto distro, I will never touch 
those layer at the git level, instead whatever change I want will be done in my 
private layer which is the main reason for layer as I understand it (being able 
to change other’s vendor layer without changing them).

As such, all bitbake needs is to get a fetch location (SRC_URI) and a path to 
store the result (S), this is quite similar to a package, except that once the 
layer has been retrieve and put in place it still need to be updated and parsed.

I fail to see why people would seek a non-bitbake solution such as repo, 
submodules or others if bitbake was able to do that aspect.  If there is a 
project already for doing this, I would be interested in participating to its 
development and I may have one or two helper in my team to help out on this.

For private layers, I do understand and see why an external solution to bitbake 
would be better, since bitbake will not offer support for branch and change 
management which is normal as bitbake is only a build tool, not a developer 
tool.

--
Yannick Koehler

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Andrea Galbusera
Sent: Thursday, May 25, 2017 1:39 AM
To: Trevor Woerner 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Can Yocto treat layers like an external package?



Il 25 mag 2017 6:12 AM, "Trevor Woerner" 
mailto:twoer...@gmail.com>> ha scritto:
Hi Yannick,

This is a feature many people have been wanting for a while, but
getting there has been slow. So slow, in fact, that many projects have
simply gone ahead and implemented their own solutions, all of which
are different from each other, making it all that much harder to get
everyone back together to support one idea :-(

As Gary mentions, "repo" is a popular solution. See, for example, how
the Linaro people have done it with their "rpb" distro and associated
setup tools/scripts:

https://github.com/96boards/oe-rpb-manifest

The freescale project was the first such instance I saw (but I can't
say whether they were the first or not):

https://github.com/Freescale/fsl-community-bsp-platform
http://freescale.github.io/#download

Mark Hatle (windriver) has been working on and releasing a tool
they've been using internally for a while:

https://www.openembedded.org/wiki/OEDEM_2016#Windriver_.E2.80.98setup.E2.80.99_Demo

I'm sure there are better links for Mark's work, but I can't find them
at the moment. Hopefully someone jumps in and fills in the blanks :-)

https://github.com/Wind-River/wr-lx-setup


I'm sure there are other such examples.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

Re: [yocto] [meta-freescale] etnaviv image

[Andreas Müller]

On Thu, May 25, 2017 at 10:48 AM, Trevor Woerner  wrote:
> w00t!!
>
> It took a lot of hacking, but I was able to build and run an image for
> the wandboard dual that uses etnaviv :-D
>
> Patches to follow.
>
> I now have 4 dev boards using open-source graphics:
> 1) rpi3-32 with vc4
> 2) dragonboard-410c with freedreno
> 3) minnow (turbot) with Intel's stuff
> 4) wandboard with etnaviv
>
> glmark2-es2:
>
> root@wandboard:~# glmark2-es2; cat /proc/loadavg
> ===
> glmark2 2014.03
> ===
> OpenGL Information
> GL_VENDOR: etnaviv
> GL_RENDERER:   Gallium 0.4 on Vivante GC880 rev 5106
> GL_VERSION:OpenGL ES 2.0 Mesa 17.0.4
> ===
> [build] use-vbo=false: FPS: 69 FrameTime: 14.493 ms
> [build] use-vbo=true: FPS: 80 FrameTime: 12.500 ms
> [texture] texture-filter=nearest: FPS: 68 FrameTime: 14.706 ms
> [texture] texture-filter=linear: FPS: 68 FrameTime: 14.706 ms
> [texture] texture-filter=mipmap: FPS: 66 FrameTime: 15.152 ms
> [shading] shading=gouraud: FPS: 70 FrameTime: 14.286 ms
> [shading] shading=blinn-phong-inf: FPS: 61 FrameTime: 16.393 ms
> [shading] shading=phong: FPS: 47 FrameTime: 21.277 ms
> [shading] shading=cel: FPS: 39 FrameTime: 25.641 ms
> [bump] bump-render=high-poly: FPS: 52 FrameTime: 19.231 ms
> [bump] bump-render=normals: FPS: 67 FrameTime: 14.925 ms
> [bump] bump-render=height: FPS: 60 FrameTime: 16.667 ms
> libpng warning: iCCP: known incorrect sRGB profile
> [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 32 FrameTime: 31.250 ms
> libpng warning: iCCP: known incorrect sRGB profile
> [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 14 FrameTime: 71.429 ms
> [pulsar] light=false:quads=5:texture=false: FPS: 61 FrameTime: 16.393 ms
> libpng warning: iCCP: known incorrect sRGB profile
> Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
> FPS: 67 FrameTime: 14.925 ms
> Error: RenderObject::init: glCheckFramebufferStatus failed (0x8cdd)
> libpng warning: iCCP: known incorrect sRGB profile
> Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> Error: RenderObject::size: glCheckFramebufferStatus failed (0x8cdd)
> [desktop] effect=shadow:windows=4: FPS: 68 FrameTime: 14.706 ms
> [buffer] 
> columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map:
> FPS: 29 FrameTime: 34.483 ms
> [buffer] 
> columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata:
> FPS: 29 FrameTime: 34.483 ms
> [buffer] 
> columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map:
> FPS: 31 FrameTime: 32.258 ms
> [ideas] speed=duration:[ 2797.051681] etnaviv-gpu 13.gpu:
> hangcheck detected gpu lockup!
> [ 2797.059575] etnaviv-gpu 13.gpu:  completed fence: 50513
> [ 2797.065622] etnaviv-gpu 13.gpu:  active fence: 50514
> [ 2797.072346] etnaviv-gpu 13.gpu: hangcheck recover!
> [ 2800.011603] etnaviv-gpu 13.gpu: hangcheck detected gpu lockup!
> [ 2800.017890] etnaviv-gpu 13.gpu:  completed fence: 50514
> [ 2800.023895] etnaviv-gpu 13.gpu:  active fence: 50515
> [ 2800.029752] etnaviv-gpu 13.gpu: hangcheck recover!
> [ 2803.051591] etnaviv-gpu 13.gpu: hangcheck detected gpu lockup!
> [ 2803.057899] etnaviv-gpu 13.gpu:  completed fence: 50516
> [ 2803.063874] etnaviv-gpu 13.gpu:  active fence: 50518
> [ 2803.069702] etnaviv-gpu 13.gpu: hangcheck recover!
> [ 2805.531626] etnaviv-gpu 13.gpu: hangcheck detected gpu lockup!
> [ 2805.537973] etnaviv-gpu 13.gpu:  completed fence: 50518
> [ 2805.544052] etnaviv-gpu 13.gpu:  active fence: 50520
> [ 2805.551826] etnaviv-gpu 13.gpu: hangcheck recover!
>  FPS: 0 FrameTime: inf ms
> [jellyfish] : FPS: 28 FrameTime: 35.714 ms
> [terrain] : FPS: 2 FrameTime: 500.000 ms
> [shadow] : FPS: 30 FrameTime: 33.333 ms
> Error: DistanceRenderTarget::setup: glCheckFramebufferStatus failed (0x8cdd)
> Error: Failed to set up the render target for the depth pass
> [refract] 

Re: [yocto] Can Yocto treat layers like an external package?

[Marcelo E. Magallon]

On Thu, May 25, 2017 at 01:13:03PM +, Koehler, Yannick (HPN Aruba) wrote:

> The case I am mostly interested about is the Vendor layers, if I pull
> in meta-openembedded or meta-freescale in my yocto distro, I will
> never touch those layer at the git level, instead whatever change I
> want will be done in my private layer which is the main reason for
> layer as I understand it (being able to change other’s vendor layer
> without changing them).

A "solution" that we use is have a single repo with all the layers, and
manage that using git subtrees.

I would strongly discourage other people from implementing such a
solution, as it solved one problem (creating and updating a workspace
with the correct layers is trivial), but it has created many others. The
biggest one in my view is that people feel encouraged to make
modifications to the vendor layers, which makes updating harder than it
should. Having a single repo with layers within directories also makes
it cumbersome to implement access controls (basically "you can commit to
directories A, B and C, but not X, Y or Z"). It also encourages a kind
of coupling that makes things more complicated in the long run.

> I fail to see why people would seek a non-bitbake solution such as
> repo, submodules or others if bitbake was able to do that aspect.  If
> there is a project already for doing this, I would be interested in
> participating to its development and I may have one or two helper in
> my team to help out on this.

My guess is that's because bitbake would have to read a file with the
layer metadata, fetch the layers that you want, and then read the
recipes. If the layers are handled just like recipes, (with SRC_URI,
SRCREV, S, etc), bitbake needs to be able to read two different sets of
recipes. That might work by changing BBFILES or BBPATH. At that point it
the UI becomes a bit awkward, I think.

It doesn't sound too far fetched, though. bitbake already contains most
(all?) of the code to make this work. I think you would just need to
come up with a reasonable UI to interact with that.

With our solution, getting updated layers (non-vendor) it's just a
matter of "git pull". Solutions built around repo are equally simple.

> For private layers, I do understand and see why an external solution
> to bitbake would be better, since bitbake will not offer support for
> branch and change management which is normal as bitbake is only a
> build tool, not a developer tool.

Well, if you obtain layers using recipes (or something very close to
that), you could include branch information in SRC_URI, as usual.

Marcelo
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can Yocto treat layers like an external package?

[Koehler, Yannick (HPN Aruba)]

Hi Marcello,

Not sure if I understood what you meant but, I am using a single repo with 
submodule for vendor layers, as such, submodule kind of solve the "temptation" 
for our developer team to go play in there, since playing there is a minefields 
thanks to the complicated submodule process.  But, I do not want to rely on the 
difficulty of submodules to tell my dev not to go change the vendor layer, 
which is way I do not want them in my repo at all.

Note that private issues is a different matter and I am not addressing it here 
and there are multiple solution such as subtree, repo, submodules, upcoming 
GVFS, etc...

>It doesn't sound too far fetched, though. bitbake already contains most
>(all?) of the code to make this work. I think you would just need to come up 
>with a reasonable UI to interact with that.

This is my opinion, I think we could alter bitbake to retrieve the SRC_URI and 
S information from the bblayers.conf (instead of having recipes like for 
package). 

sample 
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "6"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  ##OEROOT##/meta \
  ##OEROOT##/meta-yocto \
  ##OEROOT##/meta-yocto-bsp \
  
##OEROOT##/meta-openembedded;SRC_URI="git://g...@github.com/openembedded/meta-openembedded;protocol=ssh;branch=master";SRCREV="${AUTOREV}"
 \
  "
BBLAYERS_NON_REMOVABLE ?= " \
  ##OEROOT##/meta \
  ##OEROOT##/meta-yocto \
  "

Bitbake could then fetch/update the layer from the SRC_URI into the location 
given "##OEROOT##/meta-openembedded" prior to parsing.

--
Yannick Koehler

-Original Message-
From: Magallon, Marcelo 
Sent: Thursday, May 25, 2017 10:40 AM
To: Koehler, Yannick (HPN Aruba) 
Cc: Andrea Galbusera ; Trevor Woerner ; 
yocto@yoctoproject.org
Subject: Re: [yocto] Can Yocto treat layers like an external package?

On Thu, May 25, 2017 at 01:13:03PM +, Koehler, Yannick (HPN Aruba) wrote:

> The case I am mostly interested about is the Vendor layers, if I pull 
> in meta-openembedded or meta-freescale in my yocto distro, I will 
> never touch those layer at the git level, instead whatever change I 
> want will be done in my private layer which is the main reason for 
> layer as I understand it (being able to change other’s vendor layer 
> without changing them).

A "solution" that we use is have a single repo with all the layers, and manage 
that using git subtrees.

I would strongly discourage other people from implementing such a solution, as 
it solved one problem (creating and updating a workspace with the correct 
layers is trivial), but it has created many others. The biggest one in my view 
is that people feel encouraged to make modifications to the vendor layers, 
which makes updating harder than it should. Having a single repo with layers 
within directories also makes it cumbersome to implement access controls 
(basically "you can commit to directories A, B and C, but not X, Y or Z"). It 
also encourages a kind of coupling that makes things more complicated in the 
long run.

> I fail to see why people would seek a non-bitbake solution such as 
> repo, submodules or others if bitbake was able to do that aspect.  If 
> there is a project already for doing this, I would be interested in 
> participating to its development and I may have one or two helper in 
> my team to help out on this.

My guess is that's because bitbake would have to read a file with the layer 
metadata, fetch the layers that you want, and then read the recipes. If the 
layers are handled just like recipes, (with SRC_URI, SRCREV, S, etc), bitbake 
needs to be able to read two different sets of recipes. That might work by 
changing BBFILES or BBPATH. At that point it the UI becomes a bit awkward, I 
think.

It doesn't sound too far fetched, though. bitbake already contains most
(all?) of the code to make this work. I think you would just need to come up 
with a reasonable UI to interact with that.

With our solution, getting updated layers (non-vendor) it's just a matter of 
"git pull". Solutions built around repo are equally simple.

> For private layers, I do understand and see why an external solution 
> to bitbake would be better, since bitbake will not offer support for 
> branch and change management which is normal as bitbake is only a 
> build tool, not a developer tool.

Well, if you obtain layers using recipes (or something very close to that), you 
could include branch information in SRC_URI, as usual.

Marcelo
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Include meta-qt5 in an eSDK build ?

[Jan-Simon Möller]

Hi !
How can I build an eSDK that includes meta-qt5 ?

The examples I found use the 'traditional' sdk and 
add the classes from meta-qt5.

But I have not seen the eSDK being used, yet.

-- 
--
Jan-Simon Möller
dl...@gmx.de
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Problem building glibc-locale

[Craig McQueen]

> 
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] 
> On Behalf Of Burton, Ross
>
> So you did:
>
> echo "DISTRO_FEATURES += \"usbhost\"" >> conf/local.conf
>
> But poky.conf does:
>
> DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC} 
> ${POKY_DEFAULT_DISTRO_FEATURES}"
>
> Which means that the final value of DISTRO_FEATURES is "usbhost", so none of 
> the locale support is enabled, and glibc packages badly.
>
> If you just want to add a feature, use DISTRO_FEATURES_append = " usbhost" 
> (leading whitespace in the string is critical).  Note that usbhost is a 
> default distro feature:
>
> meta/conf/distro/include/default-distrovars.inc:DISTRO_FEATURES_DEFAULT ?= 
> "acl alsa argp bluetooth ext2 irda largefile pcmcia usbgadget usbhost wifi 
> xattr nfs zeroconf pci 3g nfc x11"
>
> So you don't need to specify it unless you are defining a distribution from 
> scratch.
>
> Ross

I'm having this issue, when trying to use a modification of the poky-tiny 
distro (currently using morty). Does the poky-tiny distro do the right thing?

-- 
Craig McQueen

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

[yocto] yocto-jethro: how to define a machine which builds kernel in 64-bit whereas user space in 32bit

[sourabh banerjee]

For reference I looked up the default provided machine conf files inside
poky/meta.

Following seems to build qemuarm for 32bit, i.e. both kernel and user space
32bit
*
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/qemuarm.conf?h=jethro

And following seems to build qemuarm64 for 64 bit, i.e. both kernel and
user space 64bit
*
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/qemuarm64.conf?h=jethro

Please guide me how can I define a machine where kernel is built 64bit but
the user space is 32bit.
I attempted a few things by trying to override the TUNE flags but I am not
able to get it right.

Regards,
Sourabh
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto