OpenGL (SGX-PVR drivers) on BeagleBone Black

I see some other activity on this problem at

http://eewiki.net/display/linuxonarm/BeagleBone+Black+Comments?focusedCommentId=15925605#comment-15925605

Not really, unless you have anything to add. :wink:

Regards,

Well, I at least see that someone else is thinking about the problem.

I got as far as building a ct-ng toolchain, before noticing the brand-new image 05/20. Doesn’t seem to have any new PVR support, which after reading that other thread doesn’t surprise me.

So, the way I understand that other thread is that even if I go through the process of rebuilding the kernel and building matching modules, the Graphics SDK still doesn’t have /etc/init.d/pvr-init and related required components that work with es8.0 and these AM3359 Sitara processors? Why do all the TI Graphics SDK wiki pages indicate that things are tested and working then?

Ben

Well they were tested in house at TI with the original BeagleBone
running v3.2.x (from arago) using Ti's special file system. :wink:

Regards,

It is on the list. Had to take care of some legal issues to allw people outside of TI work on it as there was no one in TI brave enough to tackle the 3.8 Kernel.

Gerald

Oh ok, I didn’t realize that the original BeagleBone was same processor just a different speed grade.

So there are working kernel modules, user-mode drivers, init-scripts, and demos for these chips… just not updated for kernel 3.8+. That’s more promising (especially since I’ve recently been looking at DM8168 where development seems to have stalled at kernel 2.6.37 – and more annoyingly, old versions of BusyBox which can’t build with recent glibc due to rpc).

I’m really starting to dislike these “platform support packages” where the patches never get integrated into mainline.

Here is the story. When we started all this, TI was to have 3.8 kernel support in Q2. Right at the launch time. It didn’t happen. It was moved out to “Q4 2013”.

So, we are trying to find ways to clean up the mess. 3D was one of the things that was later down the list and needed some paperwork to get other people to work on it.

Gerald

Here is the story. When we started all this, TI was to have 3.8 kernel support in Q2. Right at the launch time. It didn’t happen. It was moved out to “Q4 2013”.

So, we are trying to find ways to clean up the mess. 3D was one of the things that was later down the list and needed some paperwork to get other people to work on it.

Thanks for the transparency. The only thing I’d consider actually broken about any of this is that the information which I guess was given by TI to 300,000 tech news sites said this stuff was included, instead of saying “coming in a software update later this year”, and all those sites promptly headlined “OMG New BeagleBone Black is a faster Raspberry Pi at the same price level!”. I’m pretty sure both hobbyists and engineers are most understanding of “it’s coming in a software update” than “it doesn’t work as advertised and now I need another solution for the project / research / classwork I had earmarked it for”. But I recognize that isn’t the fault of anyone providing community support in this and other forums. And I thank you for the hard work you’re doing to resolve these shortcomings in the software package.

BTW, OpenGL ES is good for more than just 3D. Texturing, blending, and computational shaders all provide much more performance on the graphics coprocessor than trying to implement them on the ARM Cortex.

Ben Voigt

Oh, I understand. Believe me. But, not to get into too many details, the ones saying that, well, they are in another group from the ones that delayed it. So, they are in they same boat as us, left hanging. TI is made up of dozens of different group. Sort of like the Borg Collective, except without the mind hive!

But, we are busting it to catch up. If we had stayed with 3.2, we would not be in this situation. But, that is water over the dam.

Gerald

Would it still be possible for us to use 3.2 including the working 3D/GLES-drivers in case we don’t really need 4.0 features?

Hi,

so does all this mean, that the lastest GFX SDK 4.09… is only build tested against kernel 3.8 and never ran against that kernel?
Well, I plan to switch from 3.2 to 3.8 (or even mainline) for an upcomming project and during some pre-testing I noticed that the SDK 4.09…
cleanly builds against 3.8.13 and the pvrsrvkm kernel module even loads but ‘/usr/local/bin/pvrsrvctl --start --no-module’ from /etc/init.d/rc.pvr
fails with err=4 (s’tracing brings up … open("/dev/pvrsrvkm", O_RDWR) = -1 ENOMEM (Cannot allocate memory)).

So is this some kind of expected or even known issue with the SDK under 3.8?

Matthias

So nobody ever tested the GFX SDK against kernel 3.8? The current SDK’s release notes state "This release is build tested only for SUPPORT_XORG=0 against 3.8 kernel."

I gave it a test against 3.8.13. The pvrsrvkm module loads fine. But pvrsrvctl fails with err=4. Some stracing shew that
open() syscall on /dev/pvrsrvkm fails with ENOMEM. Does digging into this make sense? Or should it work and I am doing something wrong :slight_smile:

Matthias

You cannot test what does not yet exist. It is complicated TI supply support for the 3.8 Kernel as has been mentioned many many times here. So, we had to get the license over to Circuitco to allow them to use the SDK and put it into the 3.8 kernel tat they support. The license was completed last week. So, once that is done, then they will test it.

Gerald

Has there been anymore development on this front?

Nathaniel Lewis

ping -f

Did TI have up on SGX support for the BBB and Linux 3.8?

Thanks,
//richard

No support from TI.

Gerald

That’s very sad to hear. :frowning:

Thanks,
//richard

TI has moved to 3.12. So any support from TI would have to be on 3.12,

Gerald

Cool, they have finally joined the device tree dark side i see. :wink:

Regards,

Dark? Yes dark. Very dark.

Gerald