Mity CPU Platforms » MitySOM-AM62, MitySOM-AM62A, & MitySOM-AM62P

Hi Nathan,

Short answer: adding the "ti-img-rogue-driver, wayland, and weston" recipes to your image should bring in everything you need to enable the GPU. If you don't need wayland/weston, take a look at the long answer to manually include the 3D library recipes in your image.

Long answer:

The recipe used for GPU acceleration for the AM62x is set in meta-ti/meta-ti-bsp/conf/machine/include/mesa-pvr.inc:

1:PREFERRED_PROVIDER_virtual/mesa ?= "mesa-pvr"@
2:PREFERRED_PROVIDER_virtual/egl ?= "mesa-pvr" 
3:PREFERRED_PROVIDER_virtual/libgles1 ?= "mesa-pvr" 
4:PREFERRED_PROVIDER_virtual/libgles2 ?= "mesa-pvr" 
5:PREFERRED_PROVIDER_virtual/libgles3 ?= "mesa-pvr" 
6:PREFERRED_PROVIDER_virtual/libgbm ?= "mesa-pvr" 
7:PREFERRED_PROVIDER_virtual/libglx ?= "mesa-pvr" 
8:PREFERRED_PROVIDER_virtual/libgl ?= "mesa-pvr" 

You can include egl, libgles1, libgl directly to your image or you can add something that will include these packages as dependencies (like weston or Qt).

The actual kernel driver is built in the ti-img-rogue-driver recipe, but that should be included automatically as a dependency of mesa-pvr.

FYI: Instructions for manually compiling the driver can be found in our wiki: https://support.criticallink.com/redmine/projects/mitysom_am62x/wiki/Linux_Kernel_PVR

Thanks!

Hi Bob,

We did the above and it does get the driver on target. However, when we run populate_sdk those libraries don't make it into the SDK. What do we need to do to get those libraries into the SDK so we can cross compile Qt for target?

Tim

These are our TOOLCHAIN_HOST_TASK and TOOLCHAIN_TARGET_TASK...

TOOLCHAIN_HOST_TASK="     nativesdk-packagegroup-sdk-host     packagegroup-cross-canadian-mitysom-am62x-ep00119            nativesdk-buildtools-perl-dummy" 
TOOLCHAIN_HOST_TASK:apppend=" nativesdk-cmake nativesdk-ninja " 

NOTE: cmake and ninja are for crossing qt6.

TOOLCHAIN_TARGET_TASK="     packagegroup-core-standalone-sdk-target               target-sdk-provides-dummy       packagegroup-core-boot           packagegroup-arago-base     packagegroup-arago-console         psplash     audit     git-revisions      swupdate     swupdate-www     swupdate-cert     u-boot-fw-utils      pru-icss     glmark2     packagegroup-arago-tisdk-crypto     gdbserver     ptpd   run-postinsts opkg psplash base-passwd shadow" 

Does there need to be something about mesa-pvr in TOOLCHAIN_TARGET_TASK? Like mesa-pvr-dev?

When we attempt to configure qt6, it seems to complain there is no opengl support.

CMake Error at qtbase/cmake/QtBuildInformation.cmake:534 (message):
  Feature "egl": Forcing to "ON" breaks its condition:

      ( QT_FEATURE_opengl OR QT_FEATURE_openvg ) AND EGL_FOUND AND ( QT_FEATURE_dlopen OR NOT UNIX OR INTEGRITY )

  Condition values dump:

      QT_FEATURE_opengl = "OFF" 
      QT_FEATURE_openvg = "OFF" 
      EGL_FOUND = "FALSE" 
      QT_FEATURE_dlopen = "ON" 
      UNIX = "1" 
      INTEGRITY = "0" 

We've successfully done this once, building the sdk off of the big fat tisdk-default-image. I would prefer to not do that, since it like 3.5 gb in size. Which I look at the fat sdk's TOOLCHAIN* vars they aren't much different.

Nathan and Tim,

It may be easier to try to fit into TI's way of doing things. They use bitbake meta-toolchain-arago-tisdk to build the toolchain (instead of populate_sdk) which you may be able to extend to make your modifications. The default TI toolchain includes cmake and ninja so you wouldn't need to include those manually.

The default TI build is dependent on Qt5 so you'll probably have to carry that along even if you don't use it.

Beyond this, we may need specific details of the exact modifications you are making to the build to better understand your goals.

Thanks Bob,

I'll try the (what I thought was the older) image method. I saw a posting from TI on e2e (an FAQ iirc) that stated they were moving to populate_sdk.

<Rant disclaimer="this is a TI rant, I am not frustrated with CL">

The most recent doc doesn't even discuss building the SDK on the page entitled... Building the SDK with Yocto.

https://software-dl.ti.com/processor-sdk-linux/esd/AM57X/09_03_06_05/exports/docs/linux/Overview_Building_the_SDK.html

It discusses recipes and building target images, but doesn't discuss building the SDK.  I was reading in to that to mean that we were supposed to fallback on the populate_sdk method.

In fact, when I searched the most recent doc for the text "meta-toolchain-arago-tisdk", I did't find it.  I find that search tool dubious though.

</Rant>

Crossing fingers... 11k tasks to go...

Thanks, Nathan

Note that you linked the 57x Processor SDK instructions. The Am62x version does mention the meta-toolchain-arago-tisdk
https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/10_01_10_04/exports/docs/linux/Overview_Building_the_SDK.html

I saw a posting from TI on e2e (an FAQ iirc) that stated they were moving to populate_sdk.

Hmm that is encouraging. The fact that TI maintains there own way of creating a toolchain outside of the normal yocto flow has caused us plenty of issues over the years. So hopefully they continue down this road.

Note that I am in process of releasing the 10.1 SDK files. Hopefully by end of day. If you've been building the 10 SDK yocto release, swapping to the 10.1 should be pretty seamless.

If you've been build the 9 SDK, then I strongly recommend moving to the 10 SDK as there were several stability fixes made by both TI and us.

Sorry, I have muddied the waters.

We are on 10 sdk from you guys for mitysom. (moving to 10.1 should be no problem).
We are on 9.3 sdk from ti for beagleboard x15.

Thanks,
Nathan