This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BEAGL-BONE-BLACK: Building the Arago Project coresdk and configuring the proper PowerVR graphics settings

Other Parts Discussed in Thread: PROCESSOR-SDK-AM335X


I am building TI Linux to experiment with graphics on the BeagleBone Black. Per the instructions, I create the image as follows:

  • git clone git:// tisdk
  • cd tisdk
  • ./ -f configs/coresdk/coresdk-
  • Change local.conf such that:
    • MACHINE ?= "beaglebone"
  • . conf/setenv
  • bitbake tisdk-default-image

(Note: I have done the one-time operation to disable dash.)

There are specific instructions to configure the pixel format when using the BBB. Mentioned is modification of the /etc/powervr.ini file. This is where my trouble begins - there is no powervr.ini file.

I have been able to piece together a powervr.ini file, by referencing the SGX Debug Info and the ImgTec release.


Unfortunately, I believe this to be incorrect. The SGX Debug Info lists out two options for the WindowSystem:


Neither of these libraries is present in /usr/lib.

I have been able to locate an email archive and a corresponding git commit where these libraries are removed from the recipe. The message indicates the removal is work towards a Mesa-based EGL/GLES.

Additional relevant information can be found in the power-vr drivers recipe for the BeagleBone Black:


Here you can see WINDOW_SYSTEM has been set to nulldrmws.

This define controls how the SGX driver is built, as the makefile shows:


else ifeq ($(WINDOW_SYSTEM),nulldrmws)

This leads me to the following questions:

  1. Does the PowerVR driver still require
  2. If so, how can I satisfy that requirement given the library was removed from meta-ti?
  3. If not, is it necessary to supply a different value in the powervr.ini file? What is it supposed to be?

Thank you much in advance for your help!

  • Hi Brad,

    the proper Yocto MACHINE target for building for the BeagleBone Black is am335x-evm (per the instructions you already found). Can you please give this a shot and see if this solves your issue.

    Regards, Andreas

  • Thank you for the suggestion. Unfortunately I started my experiments with the pre-built image for the am335x-evm [link]. This image too has no powervr.ini file, and both documented libraries for the WindowSystem are missing from the /usr/lib location. After analyzing the recipes this is expected.

    If you compare meta-ti/conf/machine/beaglebone.conf [link] and meta-ti/conf/machine/am335x-evm [link] they are both compatible with the BeagleBone Black. Each of these configurations extends the same TI configuration for the 33x:

    require conf/machine/include/

    The main reason I chose beaglebone over am335x-evm was that I am using an HDMI display, and it seemed the am335x-evm configuration assumed the built-in LCD by setting MACHINE_GUI_CLASS to "smallscreen". I have only traced that to the boot logo size, so I really don't think it matters anyway.

    Both the pre-built image and the one I built are problematic.The Matrix GUI fails to launch, and instead displays an error message about http://localhost that I haven't been able to sort out.

    To workaround this, I exit Weston to try the Graphics Demos [link] from the null-window system mode. All of the Raw binaries fail. I can, however, run the kmscube if I pass the "--format=RG16" argument.

    I really want to try the Qt examples out, but I am also unable to launch those from null-window system mode. I have tried setting environment variable QT_QPA_PLATFORM=eglfs, but I get, "Could not initialize egl display". If I use QT_QPA_PLATFORM=linuxfb I can run the Qt examples. Unfortunately I fear this platform is without the hardware acceleration that I'm chasing.

  • I have some findings to share. Per the original questions, the TLDNR is as-follows:

    1. No
    2. N/A
    3. WindowSystem should be deleted from powervr.ini

    The Migration from prior releases explains these findings [] and []. The window system functionality of the "missing" libraries is now embedded into Additionally, the window system load has changed from static to dynamic, so the configuration entry in powervr.ini is no longer applicable.

    The latter migration also explains why the Qt examples were failing to launch from null-window system mode. The documentation in [3.6.11] is incorrect; /etc/profile.d/ should not be modified. QT_QPA_EGLFS_INTEGRATION should remain eglfs_kms when using the BeagleBone Black. After reverting to that setting I can use QT_QPA_PLATFORM=eglfs and run the examples successfully.

    I have also determined I can kill the failed matrix GUI by issuing Windows Key + k. This keeps Weston active, and from there I can launch the 3D demos from the terminal. They all run.

    So I'm left with a couple of things to sort out. The matrix GUI error and running the 3D demos from null-window system mode. For the latter, documentation in [3.6.3] notes, "Some of the demos under null windowing system require the user to pass in the drm connector id." Instructions are given on how to find the connector id, but the format of how to pass the connector id to the demo binary is never explained.

    Finally, there is one last piece of evidence here that suggests the graphics configuration is not yet quite right. When I run PVRPerfServerDeveloper in /opt/img-powervr-sdk/PVRHub/PVRPerfServer the application fails to work.

    Error: failed to initialise services connection (driver support not found).
    * Not connected to PowerVR driver.

    Any help offered with these remaining items would be much appreciated!

  • Hi Brad, your concerns are very graphic-specifics, let me get this ticket routed to our GFX expert for additional insight.

  • Hello,

    With regards to the PVRPerServer, the binary is outdated and my recommendation is to install it from IMG website: In the download option, please select PVRTune for SGX. 

    Thank you for the updates on the powervr.ini docs and yes they are outdated. I will file an internal ticket to update them to avoid further confusion. Could you please provide more information on which 3D demos you are having trouble running?


  • Hi Krunal,

    Thank you for taking the time to help.

    Per your link, I registered with Imagination and downloaded the latest PVRTune for SGX. The PVRPerfServerDeveloper now reports as "v14.143 32-bits - Build 17.1@4676419". For reference, the binary originally in the TI SDK reports as "v14.111.1 - Build 3.5@3533642". Unfortunately, both applications fail with the same error message.

    Error: failed to initialise services connection (driver support not found).
    * Not connected to PowerVR driver.

    Regarding the 3D applications, as previously mentioned, all run successfully under Wayland. However, when I follow the instructions in [3.6.1] to run the applications in null-window system mode, none of the applications work.

    The specific applications I have tried are:

    root@beaglebone:/usr/bin/SGX/demos/DRM# ls
    OGLES2ChameleonMan  OGLES2ExampleUI  OGLES2MagicLantern
    OGLES2Coverflow     OGLES2FilmTV     OGLES2Navigation

    The error messages start with "display failed to set mode: Invalid argument." This leads me to believe I need to pass additional arguments to the demo application, but I am so far unable to determine what the CLI syntax is.

    I have also tried the versions under the "Raw" folder. All these applications fail with "PVRShell: Unable to initialise EGL."

    Kind regards,


  • I have continued to troubleshoot, but I haven't had any further success. My focus is currently on PVRPerfServerDeveloper, because the lack of GPU utilization information makes it difficult to assess the capability of the platform.

    To reduce variables, I have reverted to using the pre-built SDK for the AM335x [link].

    Here is the full output from the application:

    root@am335x-evm:/opt/PVRTune/PVRPerfServer/Linux_armv7hf# ./PVRPerfServerDeveloper
    ./PVRPerfServerDeveloper: /usr/lib/ no version information available (required by ./PVRPerfServerDeveloper)
    ./PVRPerfServerDeveloper: /usr/lib/ no version information available (required by ./PVRPerfServerDeveloper)
    ./PVRPerfServerDeveloper: /usr/lib/ no version information available (required by ./PVRPerfServerDeveloper)
    ./PVRPerfServerDeveloper: /usr/lib/ no version information available (required by ./PVRPerfServerDeveloper)
    PVRPerfServerDeveloper v14.143 32-bits - Build 17.1@4676419.
    Copyright (C) Imagination Technologies Ltd. All rights reserved.
    * Support:  
    * OS:                 Linux version 5.10.100-g7a7a3af903 (oe-user@oe-host) (arm-none-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) #1 PREEMPT Sat May 14 22:36:58 UTC 2022
    * Time (local):       Thu, 01 Sep 2022 18:50:38 +0000 (18:50:38)
    * Time (UTC):         Thu, 01 Sep 2022 18:50:38 +0000 (18:50:38)
    Error: failed to initialise services connection (driver support not found).
    * Not connected to PowerVR driver.
    * Processor count:    1
    This server is am335x-evm:6520 (lo:,eth0:
    Waiting for connection (press q to quit)...
    200.0ps [GPU data unavailable!] : 00/00,Tu

    I had been focused on the "driver support not found" bit, but after a night's sleep I think the "/usr/lib/ no version information" could perhaps be indicating a more fundamental problem.

    Could the root of this issue be that Imagination's binaries are built against an incompatible C/C++ runtime to what is packaged in the Arago root filesystem?

  • Hello,

    Could you please ask the above information on the following forum: . IMG developed the PVRPerfServer and they will be able to further comment on the dependencies. 


  • I have posted the question on the IMG forum, as requested [link].

    Thank you for your help.

  • The IMG forum has uncovered the problem. The Arago root filesystem is missing a symbolic link required by the application:

    ln -s /usr/lib/ /usr/lib/

    It is likely the PVRPerfServerDeveloper application loads the library at runtime via a dlopen() call. As such, it uses the most generic name,

    I have dug a bit deeper on the Arago side. These libraries are installed via meta-ti/recipes-graphics/libgles/

    Have a look at the SRC_URI at the specified branch [link]. The missing symbolic link is actually in the source. So why doesn't it end up in the image?

  • I see the following in the default filesystem:

    lrwxrwxrwx 1 root root 35 May 24 2021 ->
    lrwxrwxrwx 1 root root 35 May 24 2021 ->
    -rw-r--r-- 1 root root 9656 May 24 2021

    Are you saying the above symbolic links are not correct?


  • The above symbolic links are correct, but not all of them are present in my disk image.

    Have a look:

    you@linux-pc:~$ wget
    ... saved
    you@linux-pc:~$ echo fd979528fea5dda8606d0784babd26ba tisdk-default-image-am335x-evm.wic.xz | md5sum --check -
    tisdk-default-image-am335x-evm.wic.xz: OK
    you@linux-pc:~$ xz -d tisdk-default-image-am335x-evm.wic.xz
    you@linux-pc:~$ mkdir rootfs
    you@linux-pc:~$ loop_device=`losetup -f`
    you@linux-pc:~$ sudo losetup -P $loop_device tisdk-default-image-am335x-evm.wic
    you@linux-pc:~$ sudo mount --read-only "$loop_device"p2 rootfs/
    you@linux-pc:~$ ls -l rootfs/usr/lib/libPVR*
    lrwxrwxrwx 1 root root   35 May 14 17:55 rootfs/usr/lib/ ->
    -rw-r--r-- 1 root root 9656 May 14 17:49 rootfs/usr/lib/
    you@linux-pc:~$ sudo umount rootfs
    you@linux-pc:~$ sudo losetup -d $loop_device
    you@linux-pc:~$ rm -rf rootfs/
    you@linux-pc:~$ rm tisdk-default-image-am335x-evm.wic

    As you can see, the disk image from the PROCESSOR-SDK-AM335X page [link] does not have the symbol link present on the rootfs partition.

    In addition to the pre-built SDK from TI, I also have tried building my own, as indicated earlier in this thread, and confirmed that wic file is missing the symbolic link as well.

    Thanks and regards,


  • Hi Brad,

    Thanks! I will share the above finding with our dev team.