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 <[email protected]> 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 <[email protected]> > wrote: > >> Hey Stephen, >> >> On Fri, May 26, 2017 at 7:23 PM, Stephen Arnold >> <[email protected]> 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. >> > >
-- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
