SGXDebug

NOTE: This page is currently under construction and will go through major changes.

Last updated: 09/07/2016

Welcome to the SGX Debug page. This page contains tips / techniques for debugging SGX issues.

Introduction

The TI OMAP/AM/DM SGX Graphics Driver is closely tied to the environment it is running under, and the configuration it is built with. This article mentions debugging methods specific to Linux.

Baselining the current SGX driver environment

The current SGX driver environment on the target can be observed using the below script.

https://gforge.ti.com/gf/download/docmanfileversion/203/3715/gfx_check.sh

This script performs the below actions:

#!/bin/sh
echo "WSEGL settings"
cat /etc/powervr.ini
echo "------"
echo "ARM CPU information"
cat /proc/cpuinfo
echo "------"
echo "SGX driver information"
cat /proc/pvr/version
echo "------"
echo "Framebuffer settings"
fbset -i
echo "------"
echo "Rotation settings"
cat /sys/class/graphics/fb0/rotate
echo "------"
echo "Kernel Module information"
lsmod
echo "------"
echo "Boot settings"
cat /proc/cmdline
echo "------"
echo "Linux Kernel version"
uname -a

Build time configuration of the SGX driver

The SGX driver can be configured for debug or release mode.

Details of how to build the driver in these modes is provided in the below link.

http://processors.wiki.ti.com/index.php/GSG:_AM35x_and_OMAP35x_Rebuilding_the_Software#Rebuilding_the_Graphics_SGX_Kernel_Modules

Debug mode operation

In the debug mode of operation, the SGX driver keeps track of different states and logging information. The speed of operations during the debug mode will be slower than Release mode. After quitting the graphics OpenGL/ES application, the driver dumps the state of the application that can be used to gain valuable information about the way the application ran, and how SGX was used during the OpenGL ES API calls.

Typical output (first few lines) of the Debug mode dump is shown below:

PVR:  Total Frames                                         1522

PVR:  Profiled Frames                         (0-1522)       1522

PVR:  Average Elapsed Time per Profiled Frame (ms)           17

PVR:  Average Driver Time per Profiled Frame (ms)            18

PVR:  Estimated FPS                                          58.4956

Release mode operation

This is the default mode of operation and no debug information is available from inside the SGX driver.

Run-time checks/configuration of the SGX driver

One can confirm whether the SGX drivers have been properly installed by checking the following-

• One should have seen the message on serial console- "Loaded PowerVR consumer services" just before getting the linux command prompt.
• lsmod shows pvrsrvkm, omaplfb modules inserted successfully without any error messages on console.

The SGX driver can be configured at run-time on the target using a configuration file.

The configuration file is installed by the Graphics SDK installer at,

/etc/powervr.ini

Configuration items are specified using the below syntax

KeyWord=ParamValue

Important configuration parameters are mentioned below.

WindowSystem

* WindowSystem - This configuration item controls the low level window system that the EGL implementation should hook it up. This item takes the below values 

libpvrQWSWSEGL.so (for integration with Qt/Embedded only - this library comes from the Qt/Embedded package)

libpvrPVR2D_FRONTWSEGL.so (for direct writes to FrameBuffer - FRONT mode of operation - directly writes to FrameBuffer without waiting for vsync - fastest mode of operation)

libpvrPVR2D_FLIPWSEGL.so (for VSync synchronised writes to Framebuffer - slower, but avoids tearing)

libpvrPVR2D_BLITWSEGL.so (for direct writes to back-buffer, which later gets written to FrameBuffer with sync)

libpvrPVR2D_X11WSEGL.so (for integration with X11/KDrive only)

libpvrPVR2D_DRIWSEGL.so (for integration with X11/DRI/DRM drivers only)

For eg if one wants to configure front buffer mode, then edit /etc/powervr.ini to have following line-
WindowSystem=libpvrPVR2D_FRONTWSEGL.so
For flip buffer mode- WindowSystem=libpvrPVR2D_FLIPWSEGL.so

ParamBufferSize

* ParamBufferSize - This configuration item takes "number of bytes" as value.

This parameter buffer size can be increased, when complex 3D scenes are used in the application. For simple 2D applications, changing this parameter makes no effect. For eg to set 32MB as ParamBufferSize, edit /etc/powervr.ini to add below line-
ParamBufferSize=33554432

DisableHWTextureUpload

*  DisableHWTextureUpload - This configuration item enables/disables the use of SGX Transfer queue hardware. 
* If set to 1, uses software upload (copying from driver to SGX) of textures, rather than transfer queue (using the SGX hardware). 
* Useful to rule out problems in TQ.

Finding the extensions supported by SGX driver

A quick check of the extensions supported by the SGX driver can be done using "eglinfo" utility. A sample first few lines of this output are shown below.

EGL config number: 0
EGL vendor string: Imagination Technologies
EGL version string: 1.4 build 1.5.15.3130
EGL extensions: EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_vg_parent_image EGL 
EGL client APIs are: OpenGL_ES OpenVG 

EGL config Attributes:
 EGL_CONFIG_ID = 0x1 
 EGL_BUFFER_SIZE = 0x10 
 EGL_RED_SIZE = 0x5 
 EGL_GREEN_SIZE = 0x6 

 ...

Extension (and other) information can be obtained at run-time with the eglQueryString() api. See the example C code below:

// The display needs to be set according to your platform
// EGLDisplay display; 
char* extensions;
extensions = eglQueryString(display, EGL_EXTENSIONS);
printf("%s\n", extensions);

SGX Driver Failure Modes (Installation)

Unable to install the kernel modules (pvrsrvkm.ko or omaplfb.ko)

1. The Linux kernel has to be built with "modules" support (make uImage modules) - refer to http://processors.wiki.ti.com/index.php/AM35x-OMAP35x_Graphics_SDK_Getting_Started_Guide

2. The kernel modules of the Graphics driver have to be built, after the linux kernel is built in the above manner. ie, the kernel modules need to match the kernel version that will actually run on the target. Then do a make install to the target, per the documentation in the Getting Started Guide.

3. On the target, use the omap-demo, or the current soc-demo scripts, to load the modules. On some platforms(387x/389x), there is additional dependancy of fbdev on syslink. Please read and follow the instructions - http://processors.wiki.ti.com/index.php/GSG:_AM35x_and_OMAP35x_Executing_the_Graphics_SDK_Demos#Running_the_Demos_from_Command_Line for such cases.

4. If the display driver (omaplfb.ko) does not load, most likely it is because of insufficient memory allocated to the frame buffer for the required resolution and FLIP mode, or there is a real problem with registering the VSync interrupts on the platform. Post it on the E2E forum with the output of the gfx_check.sh script linked in earlier section.

5. If the services kernel module (pvrsrvkm.ko) does not load, it is likely because of mismatches between user mode binaries and kernel modules. If the kernel modules are built correctly as specified, post the issue on the E2E forum with the output of the gfx_check.sh script linked in earlier section.

Unable to build the graphics SDK - getting the error /lib/libgcc_s.so.1: file not recognized

The instructions in this section are applicable only if you are getting the below error while building graphics SDK package -
Please note that the below error is rarely seen & hence read/follow the instructions given in this section only if you are getting below error. Otherwise you can safely ignore/skip this section.
arm-arago-linux-gnueabi-g++ -o ./Obj/devmem2 ./Obj/devmem2.o -lm -ldl -L/lib -Wl
/lib/libgcc_s.so.1: file not recognized: File format not recognized
collect2: ld returned 1 exit status
make[1]: *** [Obj/devmem2] Error 1

The above error means its trying to link to host library instead of the cross toolchain library.
The above error is rarely seen, in case you happen to notice such an error, then edit tools/devmem2/Makefile.
Replace TOOLCHAIN variable in this Makefile with absoulte toolchain path on your system.
For eg if you are using arago toolchain & say its installed under /opt/toolchain, then replace TOOLCHAIN variable used as part of PLAT_LINK in tools/devmem2/Makefile as below-
/opt/toolchain/arago-2011.09/armv7a/arm-arago-linux-gnueabi ie edit PLAT_LINK in tools/devmem2/Makefile as below-
PLAT_LINK = -lm -ldl -L/opt/toolchain/arago-2011.09/armv7a/arm-arago-linux-gnueabi/lib -Wl

If its code sourcery toolchain & say for eg its installed under /opt/toolchain -
PLAT_LINK = -lm -ldl -L/opt/toolchain/cs/arm2009q1/arm-none-linux-gnueabi/libc/lib -Wl

Give the correct cross toolchain library path based on your system as part of PLAT_LINK variable in tools/devmem2/Makefile & you will be able to get rid of this error.

Unable to build graphics SDK with SUPPORT_XORG=1 for 3.3 & above kernels

If you are not able to build Graphics SDK with SUPPORT_XORG=1 & are getting the drm related errors -
Edit GFX_Linux_KM/services4/3rdparty/linux_drm/Kbuild to remove drm_sman.o from the list for 3.3 kernel.
For 3.4 till 3.8 kernel, edit GFX_Linux_KM/services4/3rdparty/linux_drm/Kbuild to remove drm_sman.o and add drm_prime.o to list
Also if you are getting a warning with 3.4 & above kernels - pci_bus_read_config_dword() undefined, then define a dummy function in GFX_Linux_KM/services4/3rdparty/linux_drm/pvr_drm_stubs.c of the graphics SDK release package & build. This should help in getting rid of the warning
For 3.2 & below kernels(till 2.6.37) no modification required & the default Kbuild provided in release package should work without any changes.

SGX Driver Failure Modes (Run time)

Vertical Tearing

Ensure that FLIP mode of operation is selected in powervr.ini in WindowSystem

Artifacts/ Clipping issues/ Missing objects

This could potentially be due to an incorrect usage in the OpenGL application, or point to an issue in the driver. Note that the deferred rendering mode of the SGX HW, will cause different behaviour compared to the immediate renderers found on desktops.

Possible checks include increasing the "ParamBufferSize" in powervr.ini.

If this does not help, please contact TI through the Linux E2E forums (http://e2e.ti.com/)

gles1_texture stream, gles2_texture_stream applications fail

This is because these applications require bufferclass_example kernel module/driver. This is not built by default since the graphics SDK is supporting bufferclass_ti driver(bufferclass_ti module seen on issuing lsmod command) , a modified/updated bufferclass example driver which supports fast texture streaming useful for rapidly changing textures like video. The examples provided require older bc_example module which is not supported/not built by default. However the older driver source is purposefully retained as it will be helpful in debug purpsoe in case any problems seen with bufferclass_ti driver. Users interested in running the gles1_texture_stream and gles2_texture_stream apps should follow steps as below-

Steps to build

---

Edit the GFX_Linux_KM/Kbuild in SDK package to add below line -

               obj-y += services4/3rdparty/bufferclass_example/

Now create Kbuild file under GFX_Linux_KM/services4/3rdparty/bufferclass_example with following data -

                EXTRA_CFLAGS =  -DLINUX \ 
               -I$(PVR_BUILD_DIR)/include4 \
               -I$(PVR_BUILD_DIR)/services4/include \
               -I$(PVR_BUILD_DIR)/services4/system/$(PVR_SYSTEM) \
               -I$(PVR_BUILD_DIR)/services4/system/include \
                ifeq ($(TI_PLATFORM),ti81xx)
                EXTRA_CFLAGS += -DPLAT_TI81xx
                endif
                obj-m :=  bc_example.o
                bc_example-y := bufferclass_example.o bufferclass_example_linux.o bufferclass_example_private.o

Edit the bufferclass_example_linux.c file to enable -

           #define DEBUG
          #define LDM_PLATFORM

Now issue SDK build for required platform(core). For eg for OMAP3-

            make BUILD=release OMAPES=3.x all_km

This will build the bc_example.ko under GFX_Linux_KM/services4/3rdparty/bufferclass_example.

Steps to Run

---

Copy the bc_example.ko to your NFS target. insmod bc_example.ko. Run the applications for ES1.1 and ES2.0 present under the required core. Say for OMAP3 with Core 1.2.1, it will be under-

           cd /opt/gfxlibraries/gfx_rel_es3.x
          ./gles2_texture_stream
         ./gles1_texture_stream

Press 'q' to stop.

Integration of Qt framework with SGX PowerVR drivers do not work

Integration of SGX drivers into standalone Qt framework requires more careful attention to the steps. Below is an attempt to create a list of issues that are likely to come up during this procedure.

Symptoms:

./hellogl_es2 -qws -display powervr

does not work - invocation fails, or shows a green patch where the 3D rendered image should have been

Refer to below document with with a list of points that should be taken care to enable Qt acceleration with powervr.

https://gforge.ti.com/gf/download/docmanfileversion/265/4572/qt_powervr_dbg.txt

Integration of xyz framework with PowerVR drivers do not work

Please ensure that the powervr.ini is configured to use the right plug-in. For example, Qt's powervr binary via the WindowSystem option "libpvrQWSWSEGL.so".

Because of the way software frameworks use the OpenGL ES backend, there will be differences in visual quality and could also result in missing/non-updating regions. Ensure that the corresponding framework is well tested with PowerVR drivers and that all the APIs and GL extensions expected to be available in the OpenGL driver are available.

Use "eglinfo" to confirm that the extensions expected by a framework are available in the SGX driver.

SGXPERF2 (a part of Xgxperf) can be used as a starting point to check all APIs.

Demos are not running at required speed, How to check & Change SGX clock rate?

Typically, for performance measurements, it is expected to use "FRONT"mode of WindowSystem plugin (configured in powervr.ini) for measuring the run rate in fps. If in this mode, the demos are running slower than expected, check and ensure that the clock frequency set for the SGX driver is correct. This can be done by the following code in the KM kernel drivers -

File - GFX_Linux_KM/services4/system/ti335x/sysutils_linux.c
(For AM335x..similarly you can change the required file based on your platform) Function - EnableSGXClocks()
You can print the SGX clock rate in debug build as below -

IMG_UINT32 rate = clk_get_rate(psSysSpecData->psSGX_FCK);
PVR_TRACE(("Sgx clock is %dMHz", HZ_TO_MHZ(rate)));

Depending on the TI platform used, this will vary from 96 to 200 MHz. Ensure that SGX is running at the right clock.

To set the clock rate you just need to do following -

Change SYS_SGX_CLOCK_SPEED to required value in GFX_Linux_KM/services4/system/ti335x/sysconfig.h ---The example is shown for AM335x, similarly you can change in your device specific folder present under system folder.
Rebuild & insert the .kos. 

If this is right & still demos are not running with expected performance, it is needed to optimise the application, and its usage of OpenGL API.

Some demos are jerky, also see H/W recovery errors sometimes

Increase ParamBufferSize to 16 or 32 MB. Refer to the earlier section(section 4.1 -WindowSystem) in this page which describes configuring this.

EGL_BAD_ALLOC on running graphics demos or sample apps & kernel panic on inserting graphics kernel modules

Please check whether the platform specific demo script has been run. The script is present under targetfs folder of graphics SDK release. Its named -

• omap-demo for OMAP35xx/AM35xx/AM37xx
• 38xx-demo for 387x/389x,814x/816x
• 335x-demo for AM335x

The script specific to your platform/device as mentioned above should be run first. You can make this script getting called as part of your boot up scripts so that it is run automatically each time you boot.

Lock related warnings seen on OMAP35x/AM35x/37xx with 2.6.37 kernel

This section is applicable for OMAP35x/AM35x/37xx devices booted with Linux PSP 04.02.00.07(2.6.37 kernel)only. One can ignore the below lock related warnings seen on bootup with 2.6.37 kernel.

[   28.945281]
[   28.945281] =============================================
[   28.952514] [ INFO: possible recursive locking detected ]
[   28.958190] 2.6.37 #1
[   28.960571] ---------------------------------------------
[   28.966217] pvrsrvinit/1371 is trying to acquire lock:
[   28.971618]  (psPVRSRVMutex){+.+.+.}, at: [<bf00b7e4>] PVRMMapRegisterArea+0x10/0x60 [pvrsrvkm]
[   28.980987]
[   28.980987] but task is already holding lock:
[   28.987091]  (psPVRSRVMutex){+.+.+.}, at: [<bf00e55c>] PVRSRV_BridgeDispatchKM+0x1c/0xec [pvrsrvkm]
[   28.996734]
[   28.996734] other info that might help us debug this:
[   29.003601] 1 lock held by pvrsrvinit/1371:
[   29.007995]  #0:  (psPVRSRVMutex){+.+.+.}, at: [<bf00e55c>] PVRSRV_BridgeDispatchKM+0x1c/0xec [pvrsrvkm]
[   29.018066]
[   29.018066] stack backtrace:
[   29.022705] [<c004a958>] (unwind_backtrace+0x0/0xe4) from [<c00a0344>] (__lock_acquire+0xdec/0x17a8)
[   29.032287] [<c00a0344>] (__lock_acquire+0xdec/0x17a8) from [<c00a0dd8>] (lock_acquire+0xd8/0xfc)
[   29.041625] [<c00a0dd8>] (lock_acquire+0xd8/0xfc) from [<c040c908>] (mutex_lock_nested+0x58/0x2dc)
[   29.051147] [<c040c908>] (mutex_lock_nested+0x58/0x2dc) from [<bf00b7e4>] (PVRMMapRegisterArea+0x10/0x60 [pvrsrvkm])
[   29.062408] [<bf00b7e4>] (PVRMMapRegisterArea+0x10/0x60 [pvrsrvkm]) from [<bf00e390>] (OSAllocPages_Impl+0x64/0xa0 [pvrsrvkm])
[   29.074584] [<bf00e390>] (OSAllocPages_Impl+0x64/0xa0 [pvrsrvkm]) from [<bf005150>] (BM_ImportMemory+0xe4/0x290 [pvrsrvkm])
[   29.086425] [<bf005150>] (BM_ImportMemory+0xe4/0x290 [pvrsrvkm]) from [<bf009874>] (RA_Alloc+0xb4/0x238 [pvrsrvkm])
[   29.097564] [<bf009874>] (RA_Alloc+0xb4/0x238 [pvrsrvkm]) from [<bf004b34>] (BM_Alloc+0xac/0x298 [pvrsrvkm])
[   29.108062] [<bf004b34>] (BM_Alloc+0xac/0x298 [pvrsrvkm]) from [<bf00a780>] (AllocDeviceMem+0x7c/0x104 [pvrsrvkm])
[   29.119140] [<bf00a780>] (AllocDeviceMem+0x7c/0x104 [pvrsrvkm]) from [<bf00ac9c>] (_PVRSRVAllocDeviceMemKM+0x80/0x158 [pvrsrvkm])
[   29.131591] [<bf00ac9c>] (_PVRSRVAllocDeviceMemKM+0x80/0x158 [pvrsrvkm]) from [<bf014f5c>] (PVRSRVAllocDeviceMemBW+0xa4/0x1a8 [pvrsrvkm])
[   29.144805] [<bf014f5c>] (PVRSRVAllocDeviceMemBW+0xa4/0x1a8 [pvrsrvkm]) from [<bf0126a8>] (BridgedDispatchKM+0xd4/0x12c [pvrsrvkm])
[   29.157470] [<bf0126a8>] (BridgedDispatchKM+0xd4/0x12c [pvrsrvkm]) from [<bf00e600>] (PVRSRV_BridgeDispatchKM+0xc0/0xec [pvrsrvkm])
[   29.170013] [<bf00e600>] (PVRSRV_BridgeDispatchKM+0xc0/0xec [pvrsrvkm]) from [<c0107e34>] (vfs_ioctl+0x20/0x3c)
[   29.180603] [<c0107e34>] (vfs_ioctl+0x20/0x3c) from [<c0108504>] (do_vfs_ioctl+0x4e4/0x52c)
[   29.189361] [<c0108504>] (do_vfs_ioctl+0x4e4/0x52c) from [<c0108598>] (sys_ioctl+0x4c/0x6c)
[   29.198150] [<c0108598>] (sys_ioctl+0x4c/0x6c) from [<c0044c00>] (ret_fast_syscall+0x0/0x3c)

If one wants to get rid of the above warning message, one can do so with kernel menuconfig option as stated below
Run menuconfig-> Enter inside Kernel Hacking option -> Disable the below options
[ ] Lock debugging: prove locking correctness
[ ] Spinlock debugging: sleep-inside-spinlock checking
Build the uImage and graphics SDK now.
Boot up the board and one should not see any lock related warnings now.

High CPU load while using glTexImage2D, or when using OpenVG

The SGX driver uses CPU for some of its tasks for the above mentioned APIs. This will cause an increase of CPU load. [OpenVG API support is removed from 4.08.x release onwards]

It is recommended to reduce the size of the textures, or use simpler VG objects, to reduce CPU load.

GLES2 + VG or GLES2 + PVR2D for 2D configuration performance is poor

Since both GLES2 and VG and PVR2D are supported with the same core, due to synchronisation overheads, the performance will be poor. It is not recommended to use this approach on SGX devices.

Qt/E demos do not work when powerVR is enabled

1. Confirm that the GLES2 demos provided in the Graphics SDK are running properly with default SDK configuration of the window system.

2. Confirm that the Qt Window System is correctly configured (Refer http://processors.wiki.ti.com/index.php/SGXDbg#WindowSystem)

3. Confirm that both kernel modules (omaplfb.ko and pvrsrvkm.ko) are successfully loaded.

4. Confirm with fbset command to check alpha to be non zero. If not set to appropriate value using fbset. QT supports 16, 32 bpp but expects alpha to be non zero for 32 bpp.

5. If above steps are correct, post to E2E forum with the output of the gfx_check.sh script linked in earlier section. Also attach the console log, with the below option enabled in the environment

"QT_DEBUG_PLUGINS=1"

Problems switching the display output from LCD to DVI on OMAP35x

NOTE :DVI output for AM35x is not supported in PSP release 03.

Switching the display output from LCD to DVI during boot time

This can be done by changing in the bootargs to include the following

omapdss.def_disp="dvi" 

For example, in case of NFS mount

OMAP3EVM # setenv bootargs 'console=ttyS0,115200n8=noinitrd=rw ip=dhcp 
root=/dev/nfs nfsroot=<your nfs_path>,nolock, mem=128M vram=8M 
omapfb.vram=0:4M,1:3M,2:3M omapdss.def_disp="dvi"'

pvrsrvkm, omaplfb modules not inserted & getting SrvInit failed message

This section is applicable only if you are using AM335x with 3.2 kernel having sgx hwmod support
If you observe pvrsrvkm,omaplfb modules are not inserted & see the below message on running 335x-demo script -
/usr/local/bin/pvrsrvctl: SrvInit failed (already initialized?) (err=4)

This may mean you have a kernel source that does not have sgx hwmod support but you may be building graphics SDK with PM_RUNTIME=1
Issue make help -

$ make help

Usage (for build): make BUILD={debug | release} OMAPES={3.x | 5.x | 6.x | 8.x} FBDEV={yes | no} SUPPORT_XORG= {1 | 0 } PM_RUNTIME={1 | 0) all
PM_RUNTIME supported for OMAPES=8.x(ie AM335x only)
      Platform                                  OMAPES
      --------                                  ------
      OMAP35x(SGX core 1.2.1)                    3.x
      OMAP37x/AM37x(SGX core 1.2.5)              5.x
      816x(389x)/814x(387x)(SGX core 1.2.5)      6.x
      335x(SGX core 1.2.5 )                      8.x
--> Specifying OMAPES is mandatory. BUILD=release and FBDEV=yes SUPPORT_XORG=0(not enabled) PM_RUNTIME=0 by default
Usage (for install): make BUILD=(debug | release} OMAPES={3.x | 5.x | 6.x | 8.x} EGLIMAGE={1 | 0} install
--> See online Graphics Getting Started Guide for further details.

Please note that building with PM_RUNTIME=1 is required only when you have a kernel with SGX hwmod change/patch applied. [1]
Also PM_RUNTIME option is applicable only for AM335x & 3.2 kernel having SGX hwmod patch. Please check the kernel sources and if it has the changes made in above patch, then you need to build graphics SDK with PM_RUNTIME=1 & this will solve the problem you are facing.

SGX drivers not inserted successfully & observing sysfs: cannot create duplicate filename '/bus/platform/devices/pvrsrvkm' message

If you are seeing the below error message/logs on inserting the SGX driver kernel modules for AM335x -

Starting PVR
[ 19.345458] PVR: PVRCore_Init
[ 19.350494] PVR: PVRSRVDriverProbe(pDevice=cf5fe200)
[ 19.355895] PVR: EnableSystemClocks: Enabling System Clocks
[ 19.361816] PVR: GPTIMER11 clock is 24MHz
[ 19.366577] ------------[ cut here ]------------
[ 19.371459] WARNING: at fs/sysfs/dir.c:481 sysfs_add_one+0x88/0xa8()
[ 19.378082] sysfs: cannot create duplicate filename '/bus/platform/devices/pvrsrvkm'
[ 19.386169] Modules linked in: pvrsrvkm(O+) wl12xx_sdio(O) wl12xx(O) mac80211(O) cfg80211(O) [last unloaded: wl12xx_sdio]
[ 19.397644] Backtrace: 
[ 19.400238] [<c0017dbc>] (dump_backtrace+0x0/0x10c) from [<c04140c0>] (dump_stack+0x18/0x1c)
[ 19.409057] r6:c00fc5f8 r5:00000009 r4:cf3d7d18 r3:c05f7f0c
[ 19.415008] [<c04140a8>] (dump_stack+0x0/0x1c) from [<c003f1dc>] (warn_slowpath_common+0x54/0x6c)
[ 19.424285] [<c003f188>] (warn_slowpath_common+0x0/0x6c) from [<c003f298>] (warn_slowpath_fmt+0x38/0x40)
[ 19.434204] r8:00000001 r7:ce117000 r6:ce117000 r5:ce237bd0 r4:ffffffef
[ 19.441040] r3:00000009
[ 19.443756] [<c003f260>] (warn_slowpath_fmt+0x0/0x40) from [<c00fc5f8>] (sysfs_add_one+0x88/0xa8)
[ 19.453033] r3:ce117000 r2:c051174c
[ 19.456787] [<c00fc570>] (sysfs_add_one+0x0/0xa8) from [<c00fce94>] (sysfs_do_create_link+0xf8/0x1e0)
[ 19.466400] r7:cf3d7d70 r6:cf013db0 r5:ce237bd0 r4:ce237cc0
[ 19.472351] [<c00fcd9c>] (sysfs_do_create_link+0x0/0x1e0) from [<c00fcf90>] (sysfs_create_link+0x14/0x18)
[ 19.482360] [<c00fcf7c>] (sysfs_create_link+0x0/0x18) from [<c021fd30>] (bus_add_device+0xcc/0x184)
[ 19.491790] [<c021fc64>] (bus_add_device+0x0/0x184) from [<c021e090>] (device_add+0x430/0x574)
[ 19.500793] r8:00000000 r7:c0617920 r6:bf1579f8 r5:00000000 r4:bf1579f0
[ 19.507629] r3:00000000
[ 19.510375] [<c021dc60>] (device_add+0x0/0x574) from [<c02223a0>] (platform_device_add+0xfc/0x1e8)
[ 19.519714] [<c02222a4>] (platform_device_add+0x0/0x1e8) from [<c02226d8>] (platform_device_register+0x28/0x2c)
[ 19.530273] r7:cf3d6000 r6:c063e480 r5:bf157bc8 r4:bf1579e8
[ 19.536529] [<c02226b0>] (platform_device_register+0x0/0x2c) from [<bf1680ec>] (PVRCore_Init+0xec/0x398 [pvrsrvkm])
[ 19.547424] r4:bf157bc8 r3:00000000
[ 19.551300] [<bf168000>] (PVRCore_Init+0x0/0x398 [pvrsrvkm]) from [<c000876c>] (do_one_initcall+0x128/0x1a8)
[ 19.561584] [<c0008644>] (do_one_initcall+0x0/0x1a8) from [<c006c004>] (sys_init_module+0x3e4/0x1b68)
[ 19.571228] [<c006bc20>] (sys_init_module+0x0/0x1b68) from [<c0014740>] (ret_fast_syscall+0x0/0x30)
[ 19.580657] ---[ end trace fe4eb62d7dfee746 ]---
[ 19.585601] PVR: PVRSRVDriverRemove(pDevice=cf5fe200)
[ 19.591125] PVR: DisableSystemClocks: Disabling System Clocks
[ 19.597290] PVR_K:(Error): PVRCore_Init: unable to register platform device (-17) [999, root/DevApps/Graphics_SDK_4_10/GF]
Error: could not insert module /lib/modules/3.2.0/extra/pvrsrvkm.ko: File exists

This means the kernel sources you are using has the SGX HWMOD support integrated but you are not building graphics SDK with PM_RUNTIME=1 command line option. Check the kernel sources to have the SGX HWMOD support. Check if the changes in below patch is already present in kernel sources you are using - http://gitorious.org/rowboat/kernel/commit/d3ab5e87304b45dc594351ed091a6ae451f40de7?format=patch

In this case, please build graphics SDK with PM_RUNTIME=1 command line option & that should help in solving the above error/issue.

Switching the display output from LCD to DVI during run time after boot on OMAP35x

Once the EVM is booted, you can change the output display from LCD to DVI from the Linux shell in a terminal window connected to the EVM board’s serial port.

Issue following commands to switch output device from LCD to DVI

Step 1:

target $ echo 0 > /sys/devices/platform/omapdss/display0/enabled
target $ echo "" > /sys/devices/platform/omapdss/manager0/display
target $ fbset -fb /dev/fb0 -xres 640 -yres 480 -vxres 640 -vyres 480
target $ echo "dvi" > /sys/devices/platform/omapdss/manager0/display
target $ echo 1 > /sys/devices/platform/omapdss/display2/enabled
target $ fbset -fb /dev/fb0 -xres 640 -yres 480 -vxres 640 -vyres 480

Step 2:

target $ fbset -depth 32 -rgba 8/16,8/8,8/0,8/24
target $ /etc/init.d/rc.pvr stop
target $ /etc/init.d/rc.pvr start

After this, the demos should run properly on DVI.

Changing the display resolution run time

If one has a setup running graphics SDK but would like to change the default display resolution, one has to follow the below steps on the target(EVM)-

• rmmod omaplfb.ko
• fbset -xres required width -yres required height -vxres width -vyres height. For eg if one wants to change to 800x480 display from 1080p, he can do so by issuing the command - fbset -xres 800 -yres 480 -vxres 800 -vyres 480 on EVM.
• insmod omaplfb.ko (can be found under /opt/gfxlibraries/gfx_rel_es*.x, * depends on platform as already explained in user guide).
• Now one could run the Graphics application/tests with changed resolution.

On s system where graphics SDK modules are not yet installed, one could do fbset for required resolution before insertion of omaplfb itself for changes to take effect.

NOTE - Important thing to note here is if you are switching between displays like from LCD to HDMI or vice versa, make sure fb0 is tied to the display being used. Refer to respective PSP user guide on instructions for associating fb0 with the required display.

Testing the support for ARGB8888 in Frame Buffer Driver

The ARGB8888 is supported by default in DVI mode.For DVI mode boot bootargs need to be changed as given below.

OMAP3EVM # setenv bootargs 'console=ttyS0,115200n8=noinitrd=rw ip=dhcp 
root=/dev/nfs nfsroot=<your nfs_path>,nolock, mem=128M vram=8M 
omapfb.vram=0:4M,1:3M,2:3M omapdss.def_disp="dvi"'

Note that if you are switching to ARGB8888 mode after bootup it is mandatory to reload omaplfb.ko kernel module

SGX Performance Analysis Tools

Shader Cycles

To understand how many cycles are taken by a shader (from a GLSL perspective), the PVRUnisco tool can be used. This is provided as part of the Graphics SDK from TI (http://processors.wiki.ti.com/index.php/OMAP35x_Graphics_SDK_Getting_Started_Guide).

Integration with DRI/DRM (Xorg)

Xorg driver is available with Graphics SDK release 04.04.00.01 onwards.

To build with Xorg enabled, user has to provide SUPPORT_XORG=1 in make command line. Refer to build and install steps at - http://processors.wiki.ti.com/index.php/Graphics_SDK_Quick_installation_and_user_guide After build and install, when you boot up the board there are some checkpoints/guidelines for user to check whether his system is ready to run X apps.

• Check if rc.pvr script has run on the EVM serial console. If not run it manually as /etc/init.d/rc.pvr start.

• Look for the DRI setup complete message on the EVM serial console as below -

  (II) pvr(0): [DRI2] Setup complete
  (==) pvr(0): Direct rendering enabled
  
  Ignore all other error/warning messages as they are applicable more to desktop OpenGL world than here.

• lsmod shows drm and pvrsrvkm

     root@omap3evm:/opt/gfxlibraries/gfx_rel_es3.x# lsmod
     Module                  Size  Used by
     pvrsrvkm              170060  2
     drm                   125235  3 pvrsrvkm

• ps shows X running

   root@omap3evm:/opt/gfxlibraries/gfx_rel_es3.x# ps
   PID USER       VSZ STAT COMMAND
   1730 root     15180 S    /usr/local/XSGX/bin/X -verbose -config /usr/local/XSG

• Now one is ready to run X- apps. But before that set 2 variables as below-

export LD_LIBRARY_PATH=/usr/local/XSGX/lib (assuming one has done the make install step correctly, then one will find XSGX folder under /usr/local of your file system)

export DISPLAY=:0

• Now one can run unit test app under /opt/gfxlibraries/gfx_rel_es3.x as -

 ./xgles1test1

This will show 2 fast flipping triangles on the display. This means your system is now ready to integrate X apps.

The display goes blank and i see some drmCommandWrite error messages

For the errors on (EE) pvr(0): PVRDisplayCommandNoArgs: drmCommandWrite failed (-22), they are coming due to DPMS enabled display. Power management kicks in and blanks the display and when X tries to write to display, you will see the errors. This is expected as the default timeout is 10 minutes. You can fine tune them to higher values as per your requirements in xorg.conf (Note that value mentioned are in minutes)

Section ServerFlags

       Option          "BlankTime"     "100"
       Option          "StandbyTime"   "100"
       Option          "SuspendTime"   "100"
       Option          "OffTime"       "100"

EndSection.

Observing lower performance and sometimes SGX Hardware recovery error messages with Xorg driver

This issue is applicable for graphics SDK releases 04.05.00.03 & below only.
By default S/W cursor is enabled with Xorg driver. This can lead to lower performance. Also sometimes one might notice SGX Hardware recovery error messages. In these cases, one can disable the cursor in device section of xorg.xonf (found under /usr/local/XSGX/etc/xorg.conf in target file system on EVM) by adding the following line to device section in xorg.conf-

      Option          "NoCursor"       "true"

Restart the EVM.

X fails to start

• You should be running the platform specific demo script(omap-demo for AM35xx/37xx, 38xx-demo for 387x/389x/816x/814x, 335x-demo for AM335x) present under targetfs folder of graphics SDK release. This will take care of installing the graphics libraries to required location, inserting the graphics kernel modules & starting X.

• If you are trying to get Xorg running manually ie not running the demo script as mentioned above, please take care to use the xorg specfic scripts, libraries for installation - install_dri.sh, rc_dri.pvr, libsrv_um_dri.so(This should be linked as libsrv_um.so for Xorg).

• If X is failing to start with the error message - (WW) xf86OpenConsole: setpgid failed: Operation not permitted -
  

Check if matrix gui in file system is running using ps command. If yes, stop it with /etc/init.d/matrix-gui-e stop. Then stop/start the graphics driver with /etc/init.d/rc.pvr stop followed by /etc/init.d/rc.pvr start.

• If you are getting some error like SrvInit failed (error 4) or No screens found, make sure that pvrsrvkm, drm modules are loaded successfully & X is running. Check for the lsmod output to show pvrsrvkm, drm modules & ps command to show X running. If pvrsrvkm fails to load(you do not see pvrsrvkm on issuing lsmod command), then issue depmod -a command, reboot the board & repeat the steps.

• Also check if you have xorg.conf file under /usr/local/XSGX/etc directory on the target(EVM). If not copy the file xorg.conf from targetfs folder present in the graphics SDK release package to this path(/usr/local/XSGX/etc) on target.

Garbled display with full screen using Xorg DRI driver on OMAP35xx/AM35xx/37xx devices

Check if VRFB is enabled in bootargs. If enabled, disable it & run your Xorg application in full screen. VRFB hardware has a fixed line length(2048) which results in fixed stride value for a given bpp. Also there is a known issue with frame buffer driver(linux kernel) where vram size passed in bootargs is not taking into effect with VRFB enabled. Due to this one may end up having only 1 buffer for full screen resolution. Also X isn't aware of this special condition of fixed stride for VRFB & hence would result in garbled display as it would still go with normal path of rendering with a pitch value obatined from framebuffer driver.

Getting could not create flip chain message on running Xorg apps/demos in full screen

If you see the below message on running apps/demos with Xorg DRI driver, then it means SGX driver frame buffer memory requirements are not met.

(EE) pvr(0): [dri] PVRDRI2CreateFlipChain: Couldn't create flip chain
(EE) pvr(0): [dri] PVRDRI2AssignAndExportBuffers: Couldn't create flip chain

This flip chain creation happens for full screen only. If you see the above messages then it means SGX is not getting required number of buffers. You can confirm it by building SGX driver in debug mode(enabling DEBUG macro in omaplfb.h). This would print the number of swap chain buffers that is getting created.It should be atleast 3 buffers.

In such cases, if the platform supports increasing frame buffer memory by passing vram size in bootargs, then double the vram size passed in bootargs. If platform does not support increasing frame buffer size through bootargs, either change the kernel frame buffer driver code to allocate more memory/buffers or reduce your resolution by half using fbset.

Observing low performance with Qt+X11 apps for ARGB

Disable the composite extension as this is enabled by default & would come into effect with ARGB. This is more required for desktop kind of effects & has performance penalty on 3D graphics upto sometimes 50%. To gain perfoormance, add below lines in xorg.conf & restart X.

Section "Extensions"

   Option              "Composite"     "Disable"

EndSection

Observing high CPU load and no GPU load while running glxgears

GLX acceleration using SGX is not supported. So GLX based applications will fall back to software rendering. For eg you will see the messages like below when bringing up the Xorg driver -

"(EE) AIGLX error: dlopen of /usr/local/XSGX/lib/dri/pvr_dri.so failed
(/usr/local/XSGX/lib/dri/pvr_dri.so: cannot open shared object file: No
such file　or directory)"

Please ignore the above error as this is the library for accelerating full OpenGL (as in desktop version) & has no affect on the acceleration of the embedded APIs (OGLES, OGLES2, OVG).

This can also be confirmed with glxinfo as shown below and also with below screen snapshot showing high CPU loading and no activity on PVRTune.

root@arago:/opt/gfxsdkdemos/ogles2# /usr/local/XSGX/bin/glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: Software Rasterizer

That is why one shall see a high CPU loading and no GPU loading when running glxgears.

However other apps/demos are accelerated using SGX PVR DRI driver. This can be confirmed with below screen snapshot showing SGX loading with PVRTune and normal CPU loading.

Also when one runs apps with DRI acceleration, one will see logs like below-

root@arago:/opt/gfxsdkdemos/ogles2# ./OGLES2ChameleonMan  -posx=0 -posy=0  -width=1920 -height=1080
PVRShell: EGL 1.4 initialized
(II) pvr(0): [dri] PVRDRI2CreateBuffer:  Drawable 0x35c9a8 - Creating buffer (at t 1, 1920 x 1080, f 1) at 0x35d0b0
(EE) pvr(0): [dri] PVRDRI2CreateFlipChain: Created flipchain 3
(II) pvr(0): [dri] PVRDRI2CreateBuffer:  Drawable 0x35c9a8 - Creating buffer (at t 0, 1920 x 1080, f 1) at 0x35d708

The above logs clearly indicate the use of PVR DRI2 driver.

Posting to E2E forum

For suggestions or recommendations or bug reports, post details of your application as below to the E2E forums (http://e2e.ti.com/), with below information:

• Output of gfx environment baseline script available below, run on the target:

https://gforge.ti.com/gf/download/docmanfileversion/203/3715/gfx_check.sh

• Debug mode driver dump of SGX driver

This is described in previous sections

• Details of UI application, as shown in below sheet.

https://gforge.ti.com/gf/download/docmanfileversion/220/3798/UI_graphics_reqs_sheet_v1.xls

These 3 outputs will help in debugging common issues.

Links

OMAP3 Graphics SDK

http://processors.wiki.ti.com/index.php/OMAP35x_Graphics_SDK_Getting_Started_Guide

Xgxperf

http://processors.wiki.ti.com/index.php/Xgxperf

Upgrading graphics SDK in existing EZSDK setup

For users who are on on the EZSDK 5.00.00.56 release and would like to update to the latest graphics SDK release 04.03.00.02 in their current EZSDK setup/installation, please go through the instructions provided in below link for more details

http://processors.wiki.ti.com/index.php/Upgrading_Graphics_SDK_in_EZSDK