• Not Answered

OMAP3530 ES2.1 Graphics SDK 4_03_00_01 problem

Hello,

we are having problems with latest graphics driver release, the gles programs hang shortly after startup. 4.00.00.01 and earlier releases don't have this problem. Tested on arago 2.6.37 and our custom 2.6.27 kernels with exactly same results.Does the driver still support OMAP3530?

Here is gfx_check output:

WSEGL settings
[default]
WindowSystem=libpvrPVR2D_FRONTWSEGL.so
------
ARM CPU information
Processor       : ARMv7 Processor rev 2 (v7l)
BogoMIPS        : 498.87
Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x1
CPU part        : 0xc08
CPU revision    : 2

Hardware        : Pandora Handheld Console
Revision        : 0020
Serial          : 0000000000000000
------
SGX driver information
Version 1.6.16.3977 (release) /home/notaz/stuff/sgx_4_03/GFX_Linux_KM
System Version String: SGX revision = 1.0.3
------
Framebuffer settings

mode "800x480"
    geometry 800 480 800 480 16
    timings 0 0 0 0 0 0 0
    rgba 5/11,6/5,5/0,0/0
endmode

Frame buffer device information:
    Name        : omapfb
    Address     : 0x8f800000
    Size        : 3072000
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 1600
    Accelerator : No
------
Rotation settings
0
------
Kernel Module information
Module                  Size  Used by
omaplfb                 8929  0
bufferclass_ti          5200  0
pvrsrvkm              163187  2 omaplfb,bufferclass_ti
------
Boot settings
debug root=/dev/mmcblk0p2 rw rootdelay=2 console=ttyO2,115200n8 vram=6272K omapfb.vram=0:3000K
------
Linux Kernel version
Linux omap3-pandora 2.6.37-rc7-25612-g08e6a91-dirty #5 Fri Feb 25 00:09:45 EET 2011 armv7l GNU/Linux

27 Replies

  • In reply to Prathap Srinivas:

    Prathap Srinivas

    Its not clear from above sentence whether this experience is from earlier release(04.03.00.01) or latest release?

    Have you tried the scp tests with the latest release 04.03.00.02 ? Do you still see any problem with this scp test using latest release(04.03.00.02)?

    I updated to 04.03.00.02 as soon as it was released, so yes it was with 04.03.00.02. As said this is very rare and I'm still looking for reliable way to reproduce this (simply repeating scp test does not trigger it).

    Prathap Srinivas

    As already mentioned, the skybox and killing the demos abruptly with ctrl+c are known issues.  It would be helpful if you can provide use case or any other demo or application that can be used to  reproduce issue in a null window environment.

    Will do as soon as I find what's causing it.

  • In reply to Grazvydas Ignotas:

    Here is a relatively small X program that causes endless hardware recovery loop:

    http://panic.cs-bristol.org.uk/~jules/rtt-crash.tar.gz

    We also have a large program that suffers similar issue on null window system but we couldn't make a testcase out of it yet. It's an ES 2.0 app so it could be related to skybox demo issue you already know about. It works correctly under 4.00.00.01 driver.

  • In reply to Grazvydas Ignotas:

    Hi,

    I'm the author of the small test program in the previous post, http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/95950/359479.aspx#359479. I'm very interested to know if there's been any progress on this issue, in particular whether TI engineers have been able to reproduce the kernel crash/endless hardware recovery loop behaviour?

    Thanks,

    Julian

  • In reply to Julian Brown:

    Hi Julian,

    We are not seeing any kernel crash or endless SGX hardware recovery messages. We could compile and run the test program on OMAP35x. Details below-

    In release mode it runs fine with the following logs on the console -

    root@omap3evm:/usr/local/bin# ./rtt-crash
    GL extensions provided: GL_OES_rgb8_rgba8 GL_OES_depth24 GL_OES_vertex_half_floa
    t GL_OES_texture_float GL_OES_texture_half_float GL_OES_element_index_uint GL_OE
    S_mapbuffer GL_OES_fragment_precision_high GL_OES_compressed_ETC1_RGB8_texture G
    L_OES_EGL_image GL_OES_required_internalformat GL_OES_depth_texture GL_OES_get_p
    rogram_binary GL_OES_packed_depth_stencil GL_OES_standard_derivatives GL_OES_ver
    tex_array_object GL_OES_egl_sync GL_EXT_multi_draw_arrays GL_EXT_texture_format_
    BGRA8888 GL_EXT_discard_framebuffer GL_EXT_shader_texture_lod GL_IMG_shader_bina
    ry GL_IMG_texture_compression_pvrtc GL_IMG_texture_stream2 GL_IMG_texture_npot G
    L_IMG_texture_format_BGRA8888 GL_IMG_read_format GL_IMG_program_binary GL_IMG_mu
    ltisampled_render_to_texture
    fps: 73.700546
    fps: 52.006920
    fps: 47.472885
    fps: 45.503529
    fps: 44.371025
    fps: 43.652641
    fps: 43.154076
    fps: 42.792313
    fps: 42.509350
    fps: 42.291660
    fps: 42.109249
    fps: 41.961617
    fps: 41.841198
    fps: 41.730675
    fps: 41.639381

    PVR:(Warning): Kicking render due to frag buffer space [702, /buffers.c]
    fps: 0.000005
    In debug mode, we have warnings getting printed from SGX driver and frame rate is very low but still no kernel hang or crash observed.

    Setup details -

    root@omap3evm:/usr/local/bin# cat /proc/pvr/version
    Version 1.6.16.3977 (debug) omap3430_linux
    System Version String: SGX revision = 1.2.1

    Thanks,

    Prathap.

     

  • In reply to Prathap Srinivas:

    Hi Prathap,

    Thanks very much for the reply, and for trying out my test case! We might now have established that the problem is specific to the 1.0.3 SGX revision. Do you by any chance have hardware available with the older SGX revision that you could try with the test case? What kernel version are you using for your testing?

    What is the meaning and cause of the warning "Kicking render due to frag buffer space"?

    Thanks,

    Julian

  • In reply to Julian Brown:

    Julian,

    I will check out if i can get access to the hardware with older SGX revision. I am using kernel 2.6.32.

    Also the warning is seen only in debug mode and hence as of now we can conisder this of low priority.

    I would be interested to know if the application crashes on 1.0.3 are seen in release mode? 

    Also would be interested to know if the application crashes are seen in null window environment like using front buffer mode and not in X environment. This would help us to rule out any X specific issues(if any).

    Thanks,

    Prathap.

  • In reply to Prathap Srinivas:

    Yes, I see the crashes in release mode. I will try to get my test running in framebuffer mode, though I might not have time to make those changes for a couple of days.

    Thanks very much for looking into this!

    Julian

  • In reply to Julian Brown:

    I've now made modifications to the test case to run without X. Please download the new version of the test from:

    http://panic.cs-bristol.org.uk/~jules/rtt-crash-nox.tar.gz

    I'm still seeing the SGX  hardware recovery triggered/kernel crash behaviour with this version, eliminating X from the equation. Again, this is running with release-mode drivers.

    This is the output from dmesg after the crash occurs (the system becomes unresponsive very soon after this appears):

    [  243.243804] PVR_K: HWRecoveryResetSGX: SGX Hardware Recovery triggered

    [  243.243865] PVR_K: SGX debug (1.6.16.3977)

    [  243.243896] PVR_K: (P0) EUR_CR_EVENT_STATUS:     00000000

    [  243.243927] PVR_K: (P0) EUR_CR_EVENT_STATUS2:    00000000

    [  243.243957] PVR_K: (P0) EUR_CR_BIF_CTRL:         00000000

    [  243.243957] PVR_K: (P0) EUR_CR_BIF_INT_STAT:     00000000

    [  243.243988] PVR_K: (P0) EUR_CR_BIF_FAULT:        00000000

    [  243.244018] PVR_K: (P0) EUR_CR_BIF_MEM_REQ_STAT: 00000000

    [  243.244018] PVR_K: (P0) EUR_CR_CLKGATECTL:       00212120

    [  243.244049] PVR_K: (P0) EUR_CR_PDS_PC_BASE:      00000000

    [  243.244079] PVR_K: Flip Command Complete Data 0 for display device 1:

    [  243.244110] PVR_K:   SRC 0: (Not in use)

    [  243.244110] PVR_K:   SRC 1: (Not in use)

    [  243.244140] PVR_K: SGX Host control:

    [  243.244171] PVR_K:   (HC-0) 0x00000001 0x00000000 0x00000000 0x00000000

    [  243.244201] PVR_K:   (HC-10) 0x00000001 0x0000000A 0x0001B04A 0x00000002

    [  243.244201] PVR_K:   (HC-20) 0x00000000 0x00000001 0x00000000 0x00000EA6

    [  243.244232] PVR_K:   (HC-30) 0x00007AF6 0xFC9DFFFC 0x00000000 0x00000000

    [  243.244262] PVR_K: SGX TA/3D control:

    [  243.244293] PVR_K:   (T3C-0) 0x0F003000 0x0F003120 0x0F002000 0x0F09A500

    [  243.244323] PVR_K:   (T3C-10) 0x00000001 0x00000002 0x00000001 0x0F007F40

    [  243.244323] PVR_K:   (T3C-20) 0x00000000 0x00000000 0x00000000 0x00000000

    [  243.244354] PVR_K:   (T3C-30) 0x00000000 0x00000000 0x00000000 0x00000000

    [  243.244384] PVR_K:   (T3C-40) 0x00000000 0x00000000 0x00000000 0x00000000

    [  243.244415] PVR_K:   (T3C-50) 0x0F007F40 0x00000000 0x00000000 0x0F007F40

    [  243.244445] PVR_K:   (T3C-60) 0x00000000 0x00000000 0x0F007F40 0x00000000

    [  243.244476] PVR_K:   (T3C-70) 0x00000000 0x0F007F40 0x00000000 0x00000000

    [  243.244506] PVR_K:   (T3C-80) 0x00000000 0x00000000 0x0F000000 0x8B47C000

    [  243.244537] PVR_K:   (T3C-90) 0x0F08A640 0x00000000 0x0F088200 0x0F007F40

    [  243.244537] PVR_K:   (T3C-A0) 0x00000000 0x0F088060 0x00000000 0x00000000

    [  243.244567] PVR_K:   (T3C-B0) 0x00000003 0x00000001 0x00000000 0x00000001

    [  243.244598] PVR_K:   (T3C-C0) 0x00000000 0x00000000 0x00000000 0x00000000

    [  243.244628] PVR_K:   (T3C-D0) 0x00000000 0x00000000 0x00000000 0x00000EBC

    [  243.244659] PVR_K:   (T3C-E0) 0x00000EBA 0x0F000000 0x80008000 0x80048000

    [  243.244689] PVR_K:   (T3C-F0) 0x0F004000 0x0F007C20 0x0F002020 0x00000000

    [  243.244720] PVR_K:   (T3C-100) 0x00000000 0x00000000 0x00000000 0x00000000

    [  243.244720] PVR_K: SGX Kernel CCB WO:0x3E RO:0x3C

    [  243.431427] PVR_K: HWRecoveryResetSGX: SGX Hardware Recovery triggered

    [  243.431457] PVR_K: SGX debug (1.6.16.3977)

    [  243.431488] PVR_K: (P0) EUR_CR_EVENT_STATUS:     20000000

    [  243.431518] PVR_K: (P0) EUR_CR_EVENT_STATUS2:    00000000

    [  243.431549] PVR_K: (P0) EUR_CR_BIF_CTRL:         00000000

    [  243.431549] PVR_K: (P0) EUR_CR_BIF_INT_STAT:     00000000

    [  243.431579] PVR_K: (P0) EUR_CR_BIF_FAULT:        00000000

    [  243.431610] PVR_K: (P0) EUR_CR_BIF_MEM_REQ_STAT: 00000000

    [  243.431640] PVR_K: (P0) EUR_CR_CLKGATECTL:       00212120

    [  243.431640] PVR_K: (P0) EUR_CR_PDS_PC_BASE:      00000000

    [  243.431671] PVR_K: Flip Command Complete Data 0 for display device 1:

    [  243.431701] PVR_K:   SRC 0: (Not in use)

    [  243.431701] PVR_K:   SRC 1: (Not in use)

    [  243.431732] PVR_K: SGX Host control:

    [  243.431762] PVR_K:   (HC-0) 0x00000001 0x0000001C 0x00000000 0x00000000

    [  243.431793] PVR_K:   (HC-10) 0x00000002 0x0000000A 0x0001B04A 0x00000002

    [  243.431793] PVR_K:   (HC-20) 0x00000000 0x00000001 0x00000000 0x00000EA6

    [  243.431823] PVR_K:   (HC-30) 0x00007AF7 0xFCA0DC5C 0x00000000 0x00000000

    [  243.431854] PVR_K: SGX TA/3D control:

    [  243.431884] PVR_K:   (T3C-0) 0x0F003000 0x0F003120 0x0F002000 0x00000000

    [  243.431915] PVR_K:   (T3C-10) 0x00000001 0x00000002 0x00000001 0x0F007F40

    [  243.431915] PVR_K:   (T3C-20) 0x00000000 0x00000000 0x00000000 0x00000000

    [  243.431945] PVR_K:   (T3C-30) 0x00000003 0x00000000 0x00000000 0x00000000

    [  243.431976] PVR_K:   (T3C-40) 0x00000000 0x00000000 0x00000000 0x00000000

    [  243.432006] PVR_K:   (T3C-50) 0x0F007F40 0x00000000 0x00000000 0x0F007F40

    [  243.432037] PVR_K:   (T3C-60) 0x00000000 0x00000000 0x0F007F40 0x00000000

    [  243.432067] PVR_K:   (T3C-70) 0x00000000 0x0F007F40 0x00000000 0x00000000

    [  243.432098] PVR_K:   (T3C-80) 0x00000000 0x00000000 0x0F000000 0x8B47C000

    [  243.432128] PVR_K:   (T3C-90) 0x00000000 0x00000000 0x00000000 0x00000000

    [  243.432128] PVR_K:   (T3C-A0) 0x00000000 0x00000000 0x00000000 0x00000000

    [  243.432159] PVR_K:   (T3C-B0) 0x00000003 0x00000001 0x00000000 0x00000001

    [  243.432189] PVR_K:   (T3C-C0) 0x00000000 0x00000000 0x00000000 0x00000000

    [  243.432220] PVR_K:   (T3C-D0) 0x00000000 0x00000000 0x00000000 0x00000EBC

    [  243.432250] PVR_K:   (T3C-E0) 0x00000EBA 0x0F000000 0x80008000 0x80048000

    [  243.432281] PVR_K:   (T3C-F0) 0x0F004000 0x0F007C20 0x0F002020 0x00000000

    [  243.432312] PVR_K:   (T3C-100) 0x00000000 0x00000000 0x00000000 0x00000000

    [  243.432312] PVR_K: SGX Kernel CCB WO:0x3F RO:0x3F

    Thanks,
    Julian

  • In reply to Julian Brown:

    Hi Prathap,

    Has there been any progress on this issue? I'm still interested in seeing it resolved. Will there be a new release of the TI Graphics SDK for OMAP3530 chips at some point? Is there anything else I can do to help?

    Thanks,

    Julian

  • In reply to Julian Brown:

    Julian,

    The new releases planned will not be supporting the older SGX cores and hence for these you can continue to use older Graphics SDK releases that is working for you . Otherwise we suggest you to move to 37xx.

    Thanks,

    Prathap.