[yocto] [meta-freescale] etnaviv image

[Stephen Arnold]

Apparently my cma arg was dorking up the gpu initialization; if you get
this error in dmesg, then adjusting the cmdline memory args is probably a
good idea:

$ dmesg | grep etnaviv

command buffer outside valid memory window

I had default cma size in kernel config, different (larger) size on the
command line, so I replaced cma with gpumem.  Kernel seems to like it
better than cma=foo

Steve

On Wed, May 31, 2017 at 4:29 PM, Stephen Arnold <stephen.arnold42 at gmail.com>
wrote:

> 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/9a839373/attachment.html>