[yocto] [meta-freescale] etnaviv image

Stephen Arnold stephen.arnold42 at gmail.com
Wed May 31 16:29:12 PDT 2017


Hmm, I built the same commits from your recipes, and I'm still getting the
glx error in my logs :/

Other than that, things seem to work okay...

Steve

On Sat, May 27, 2017 at 9:20 PM, Trevor Woerner <twoerner at gmail.com> wrote:

> Hey Stephen,
>
> On Fri, May 26, 2017 at 7:23 PM, Stephen Arnold
> <stephen.arnold42 at gmail.com> wrote:
> > @Trevor what's your config/setup?  Did you wind up using the
> > "use-mainline-bsp" thing?
>
> Yes.
>
> As I mentioned, I was working with a wandboard, on master, therefore
> my layers are:
> - openembedded-core
> - meta-freescale-3rdparty
> - meta-freescale
>
> If I was working on some other board that didn't require
> meta-freescale-3rdparty I wouldn't have needed that layer.
> Additionally, I had started by using meta-etnaviv as well. That layer
> hasn't seen any commits in roughly 10 months. Back then my guess is
> that "upstream" didn't include very many of the bits required to get
> this to work, therefore meta-etnaviv had to include recipes/bbappends
> for mesa, libdrm, xorg-xserver, etc... in addition to the etnaviv drm
> pieces themselves.
>
> I created my own clone of meta-etnaviv
> [https://github.com/twoerner/meta-etnaviv] and pushed all my
> commits/updates there with the intention of, eventually, sending a
> pull request to its author. But by the time I was done removing all
> the things that are no longer needed (i.e. all the bbappends, since
> upstream mesa, libdrm, etc... all include the necessary bits) and
> updating the remaining stuff, I was left with very little. So little,
> in fact, that I decided to simply fold what was left back into
> meta-freescale itself, conditional on the "use-mainline-bsp"
> MACHINEOVERRIDES, and sent those patches to the meta-fsl mailing list.
>
> If the maintainers of meta-freescale accept the assumption that
> use-mainline-bsp could be the flag that indicates interest between the
> binary vivante drivers and etnaviv, then I hope they like the patches
> and accept them into meta-freescale itself. Otherwise I could just
> send that pull request to meta-etanviv's author (or re-work the
> patches with whatever feedback I get). In any case, for wandboard
> use-mainline-bsp is needed since the default kernel for wandboard is
> linux-wandboard which is still stuck at 4.1.15 and is too old for this
> etnaviv stuff. However using use-mainline-bsp with the wandboard is
> broken, so I had to send some patches for that (u-boot and kernel) as
> well (hopefully those patches are accepted as well).
>
> Due to the fact so much of etnaviv is already upstream, getting
> etanviv working doesn't take very much. It just took me a while to
> reach that point, however :-)
>
> > I pretty much had to hack up some of the meta-fsl/meta-boundary stuff and
> > put everything else in local.conf.  It would be a little easier/cleaner
> if
> > the former had some ?= in a few places...
> >
> > Anyway, I masked the browser stuff so I haven't tested that far yet, but
> all
> > you really need for 3D under X is new kernel/libdrm/mesa for ~110 fps
> with
> > glxgears.
>
> I like to use mesa-demos and (especially) glmark2 as my programs of
> choice for testing GL stuff.
>
> > I added recipes for the x11-armada stuff, which seems to work for
> > 2D but coughs an error in the xorg log.
>
> I'm curious to know which x11-armada stuff you're using. I couldn't
> get the stuff that came with meta-etnaviv to compile so I looked
> around and found Russell King's code which seemed more up-to-date, and
> compiled. Plus my xorg log doesn't have any errors (see attachment).
>
> > I probably tested more with oe-core
> > than poky but both should work.
>
> I just tend to stick with oe-core.
>
> I'm hoping to make a couple blog posts with my findings.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20170531/15fa5cf0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Xorg.0.log
Type: text/x-log
Size: 17659 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20170531/15fa5cf0/attachment.bin>


More information about the yocto mailing list