• State
  • Locked Locked
  • Replies 27 replies
  • Subscribers 101 subscribers
  • Views 2435 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

TDA4VMXEVM: DisplayPort doesn't work with different displays

TDA4VM: No display output from TDA4 EVM sample apps

Debbie Jones
Prodigy 60 points
Part Number: TDA4VM

We initially tried running multiple sample vision apps (such as the Dense Optical Flow app and Image Classification app, from psdk_rtos_auto_j7_07_00_00_11) using a 1920x1200 DisplayPort monitor (Dell U2415b).  The terminal output seems to indicate that apps are working, but nothing shows up on the display.

Based on another question on the TI forum (e2e.ti.com/.../933866 we tried a 1920x1080 DisplayPort monitor (ASUS VP247QG), but still nothing shows up on the display.

Prior to copying the sample app executables and test data to the sd card, the output from the Out of Box demo (www.ti.com/.../spruis8.pdf did appear on the screen after booting the board using the Dell U2415b monitor, but now it doesn't appear with either monitor.

Please advise.

  • 0
    TI__Guru**** 449545 points

    Hi Debbie Jones,

    Do you mean the Dell monitor was working with the earlier release and is not longer working with the vision apps? 

    I did not get "Prior to copying the sample app executables and test data to the sd card, the output from the Out of Box demo did appear on the screen", do you mean it works fine when test data and/or sample apps are not copied? 

    Also can you try uncommenting below code in psdk_rtos_auto_j7_07_00_00_11\vision_apps\utils\dss\src\app_dss_j721e.c?

    #if 0
    if(prm->display_type==APP_DSS_DEFAULT_DISPLAY_TYPE_EDP)
    {
    appDssConfigureDP();
    }
    #endif

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Prodigy 60 points

    Hi Brijesh,

    The Out of Box demo did appear on the Dell monitor, before copying over the test data and sample apps, but now it doesn't.  Output from the vision apps has never appeared on the monitor.

    The same thing happens with the ASUS monitor.

    We've tried the recommended code change with both monitors, but that doesn't fix the issue.

    Copying over the vision apps seems to put the system in a no longer "out of box" state. After copying over the vision apps, none of the apps (Out of Box demo nor the vision apps) display out to the monitor. Why is this?

    Regards,

    Debbie

  • 0 in reply to Debbie Jones
    TI__Guru**** 449545 points

    Hi Debbie,

    When you say Out of Box demo, which demos are you talking about? Does it mean vision apps demo works fine? If yes, then copying just test data should not change display output.. 

    Rgds,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Prodigy 60 points

    Hi Brijesh,

    The Out of Box demo is described in TI's documentation here.

    When running the vision app demos, nothing appears on the display.

    Best regards,

    Debbie

  • 0 in reply to Debbie Jones
    TI__Guru**** 449545 points

    Hi Debbie,

    vision apps demos support fixed resolution, ie 1080p. So if the monitor does not support this resolution, then there will not be display.

    Can you use below FAQ link and try changing resolution in the vision apps?

    [FAQ] PROCESSOR-SDK-DRA8X-TDA4X: How to change display resolution in vision apps? - Processors forum...

    e2e.ti.com
    Part Number: PROCESSOR-SDK-DRA8X-TDA4X Vision apps demos uses 1920x1080 display resolution. This article explains how to change resolution and demo to use new resolutions

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Prodigy 170 points

    Hello Brijesh,

    I am a colleague of Debbie Jones.

    We are now using a couple of Asus 1080p monitors with Display Port interfaces, and have verified that they both work by using the Display Port output of the GPU on a desktop PC.  We're seeing the same issue with the prebuilt images for the TDA4 downloaded from here:

    https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/index_FDS.html

    We've also tried the PROCESSOR-SDK-RTOS-J721E 07_00_00_11 prebuilt image.

    Following the instructions to create the SD card, the board seems to boot normally, but nothing is ever displayed on the DP monitor.

    Attached is the console log with a pre-built image:

    doesnt_work1.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    U-Boot SPL 2020.01-gf9b0d030d3 (Jun 17 2020 - 15:08:08 +0000)
    SYSFW ABI: 3.0 (firmware rev 0x0014 '20.04.1-v2020.04a (Terrific Lla')
    Trying to boot from MMC2
    Loading Environment from MMC... *** Warning - No MMC card found, using default environment
    Remoteproc 2 started successfully
    ** File not found /lib/firmware/j7-mcu-r5f0_0-fw **
    Starting ATF on ARM64 core...
    NOTICE: BL31: v2.3():07.00.00.005-dirty
    NOTICE: BL31: Built : 14:33:55, Jun 17 2020
    U-Boot SPL 2020.01-gf9b0d030d3 (Jun 17 2020 - 14:34:25 +0000)
    SYSFW ABI: 3.0 (firmware rev 0x0014 '20.04.1-v2020.04a (Terrific Lla')
    Detected: J7X-BASE-CPB rev E3
    Detected: J7X-VSC8514-ETH rev E2
    Trying to boot from MMC2
    U-Boot 2020.01-gf9b0d030d3 (Jun 17 2020 - 14:34:25 +0000)
    SoC: J721E SR1.0
    Model: Texas Instruments K3 J721E SoC
    Board: J721EX-PM2-SOM rev E7
    DRAM: 4 GiB
    not found for dev hbmc-mux
    Flash: 0 Bytes
    MMC: sdhci@4f80000: 0, sdhci@4fb0000: 1
    Loading Environment from MMC... OK
    In: serial@2800000
    Out: serial@2800000
    Err: serial@2800000
    Detected: J7X-BASE-CPB rev E3
    Detected: J7X-VSC8514-ETH rev E2
    Net:
    Warning: ethernet@046000000 using MAC address from ROM
    eth0: ethernet@046000000
    Hit any key to stop autoboot: 2 ··· 1 ··· 0
    switch to partitions #0, OK
    mmc1 is current device
    SD/MMC found on device 1
    55 bytes read in 3 ms (17.6 KiB/s)
    Loaded env from uEnv.txt
    Importing environment from mmc1 ...
    4839748 bytes read in 110 ms (42 MiB/s)
    Invalid op: Trying to load/start on already running core 6
    Load Remote Processor 2 with data@addr=0x82000000 4839748 bytes: Failed!
    1513584 bytes read in 41 ms (35.2 MiB/s)
    Load Remote Processor 6 with data@addr=0x82000000 1513584 bytes: Success!
    1513584 bytes read in 41 ms (35.2 MiB/s)
    Load Remote Processor 7 with data@addr=0x82000000 1513584 bytes: Success!
    9314288 bytes read in 204 ms (43.5 MiB/s)
    Load Remote Processor 8 with data@addr=0x82000000 9314288 bytes: Success!
    16654344 bytes read in 353 ms (45 MiB/s)
    89857 bytes read in 7 ms (12.2 MiB/s)
    1719 bytes read in 7 ms (239.3 KiB/s)
    ## Flattened Device Tree blob at 88000000
    Booting using the fdt blob at 0x88000000
    Loading Device Tree to 000000008fee7000, end 000000008fffffff ... OK
    Starting kernel ...
    [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd080]
    [ 0.000000] Linux version 5.4.40-g66cf445b76 (oe-user@oe-host) (gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10))) #1 SMP PREEMPT Wed Jun 17 14:28:47 UTC 2020
    [ 0.000000] Machine model: Texas Instruments K3 J721E SoC
    [ 0.000000] earlycon: ns16550a0 at MMIO32 0x0000000002800000 (options '')
    [ 0.000000] printk: bootconsole [ns16550a0] enabled
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    We had previously built the 07_00_00 RTOS release, and we did see the output on the DP monitor, with the exact same hardware setup (same boot switches, etc.).  Here is the log for that where we do see the monitor image:

    works2.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    U-Boot SPL 2020.01-gf9b0d030d3 (Jun 17 2020 - 15:08:08 +0000)
    SYSFW ABI: 3.0 (firmware rev 0x0014 '20.04.1-v2020.04a (Terrific Lla')
    Trying to boot from MMC2
    Loading Environment from MMC... *** Warning - No MMC card found, using default environment
    Remoteproc 2 started successfully
    Starting ATF on ARM64 core...
    NOTICE: BL31: v2.3():07.00.00.005-dirty
    NOTICE: BL31: Built : 14:33:55, Jun 17 2020
    U-Boot SPL 2020.01-gf9b0d030d3 (Jun 17 2020 - 14:34:25 +0000)
    SYSFW ABI: 3.0 (firmware rev 0x0014 '20.04.1-v2020.04a (Terrific Lla')
    Detected: J7X-BASE-CPB rev E3
    Detected: J7X-VSC8514-ETH rev E2
    Trying to boot from MMC2
    U-Boot 2020.01-gf9b0d030d3 (Jun 17 2020 - 14:34:25 +0000)
    SoC: J721E SR1.0
    Model: Texas Instruments K3 J721E SoC
    Board: J721EX-PM2-SOM rev E7
    DRAM: 4 GiB
    not found for dev hbmc-mux
    Flash: 0 Bytes
    MMC: sdhci@4f80000: 0, sdhci@4fb0000: 1
    Loading Environment from MMC... OK
    In: serial@2800000
    Out: serial@2800000
    Err: serial@2800000
    Detected: J7X-BASE-CPB rev E3
    Detected: J7X-VSC8514-ETH rev E2
    Net:
    Warning: ethernet@046000000 using MAC address from ROM
    eth0: ethernet@046000000
    Hit any key to stop autoboot: 2 ··· 1 ··· 0
    switch to partitions #0, OK
    mmc1 is current device
    SD/MMC found on device 1
    0 bytes read in 0 ms
    Loaded env from uEnv.txt
    Importing environment from mmc1 ...
    16654344 bytes read in 476 ms (33.4 MiB/s)
    89857 bytes read in 5 ms (17.1 MiB/s)
    ## Flattened Device Tree blob at 88000000
    Booting using the fdt blob at 0x88000000
    Loading Device Tree to 000000008fee7000, end 000000008fffffff ... OK
    Starting kernel ...
    [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd080]
    [ 0.000000] Linux version 5.4.40-g66cf445b76 (oe-user@oe-host) (gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10))) #1 SMP PREEMPT Wed Jun 17 14:28:47 UTC 2020
    [ 0.000000] Machine model: Texas Instruments K3 J721E SoC
    [ 0.000000] earlycon: ns16550a0 at MMIO32 0x0000000002800000 (options '')
    [ 0.000000] printk: bootconsole [ns16550a0] enabled
    [ 0.000000] Reserved memory: created DMA memory pool at 0x00000000a0000000, size 1 MiB
    [ 0.000000] OF: reserved mem: initialized node r5f-dma-memory@a0000000, compatible id shared-dma-pool
    [ 0.000000] Reserved memory: created DMA memory pool at 0x00000000a0100000, size 15 MiB
    [ 0.000000] OF: reserved mem: initialized node r5f-memory@a0100000, compatible id shared-dma-pool
    [ 0.000000] Reserved memory: created DMA memory pool at 0x00000000a1000000, size 1 MiB
    [ 0.000000] OF: reserved mem: initialized node r5f-dma-memory@a1000000, compatible id shared-dma-pool
    [ 0.000000] Reserved memory: created DMA memory pool at 0x00000000a1100000, size 31 MiB
    [ 0.000000] OF: reserved mem: initialized node r5f-memory@a1100000, compatible id shared-dma-pool
    [ 0.000000] Reserved memory: created DMA memory pool at 0x00000000a3000000, size 1 MiB
    [ 0.000000] OF: reserved mem: initialized node r5f-dma-memory@a3000000, compatible id shared-dma-pool
    [ 0.000000] Reserved memory: created DMA memory pool at 0x00000000a3100000, size 15 MiB
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    There are some interesting differences between the two boot longs, including differences between what cores are loaded up by u-boot, and an error with the continuous memory allocation (CMA).

    Regards,

    James

  • 0 in reply to James Graves1
    TI__Guru**** 449545 points

    Hi James,

    In the working case (works2.txt log), it seems that you are not using vision_apps ie you have not run "make linux_fs_install_sd" command from vision apps folder. You have just created SD card by running mk-linux-card.sh script and then install_to_sd_card.sh script. This essentially means you are flashing Linux kernel, filesystem from PSDKLA release. 

    In the second non-working case, you are using vision apps binaries, so DSS is configured with the fixed 1080p output resolution.. It seems parameters are not matching with the supported resolution on the monitor. 

    Can we please do one experiment? Can we please read few registers from case-1, ie working case and use them in case-2?

    Also is it possible to read EDID information for your monitor, by connecting GPU on the desktop? This will help to identify the exact parameter supported by monitor.

    Regards,

    Brijesh

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Prodigy 170 points

    Hi Brijesh,

    Here's the EDID information:

    asus_vp247_edid.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    sudo get-edid | parse-edid
    This is read-edid version 3.0.2. Prepare for some fun.
    Attempting to use i2c interface
    No EDID on bus 0
    No EDID on bus 2
    No EDID on bus 3
    No EDID on bus 4
    No EDID on bus 5
    1 potential busses found: 1
    256-byte EDID successfully retrieved from i2c bus 1
    Looks like i2c was successful. Have a good day.
    Checksum Correct
    Section "Monitor"
    Identifier "ASUS VP247"
    ModelName "ASUS VP247"
    VendorName "AUS"
    # Monitor Manufactured week 36 of 2020
    # EDID version 1.4
    # Digital Display
    DisplaySize 520 290
    Gamma 2.20
    Option "DPMS" "true"
    Horizsync 83-83
    VertRefresh 48-75
    # Maximum pixel clock is 170MHz
    #Not giving standard mode: 1920x1080, 60Hz
    #Not giving standard mode: 1680x1050, 60Hz
    #Not giving standard mode: 1440x900, 60Hz
    #Not giving standard mode: 1280x1024, 60Hz
    #Not giving standard mode: 1280x960, 60Hz
    #Not giving standard mode: 1280x720, 60Hz
    #Not giving standard mode: 1152x864, 75Hz
    #Extension block found. Parsing...
    Modeline "Mode 16" 170.00 1920 1928 1960 2026 1080 1105 1113 1119 +hsync -vsync
    Modeline "Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
    Modeline "Mode 1" 25.200 640 656 752 800 480 490 492 525 -hsync -vsync
    Modeline "Mode 2" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync
    Modeline "Mode 3" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync
    Modeline "Mode 4" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync
    Modeline "Mode 5" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync
    Modeline "Mode 6" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync
    Modeline "Mode 7" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync
    Modeline "Mode 8" 74.250 1920 2448 2492 2640 1080 1082 1089 1125 +hsync +vsync interlace
    Modeline "Mode 9" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 +hsync +vsync interlace
    Modeline "Mode 10" 54.054 1440 1472 1596 1716 480 489 495 525 -hsync -vsync
    Modeline "Mode 11" 54.054 1440 1472 1596 1716 480 489 495 525 -hsync -vsync
    Modeline "Mode 12" 54.000 1440 1464 1592 1728 576 581 586 625 -hsync -vsync
    Modeline "Mode 13" 54.000 1440 1464 1592 1728 576 581 586 625 -hsync -vsync
    Modeline "Mode 14" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync
    Modeline "Mode 15" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
    Modeline "Mode 17" 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync
    Modeline "Mode 18" 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync
    Modeline "Mode 19" 27.00 720 732 796 864 576 581 586 625 -hsync -vsync
    Option "PreferredMode" "Mode 16"
    EndSection
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Brijesh Jadav
    Prodigy 170 points


    Hi Brijesh,

    In the working case (works2.txt log), it seems that you are not using vision_apps ie you have not run "make linux_fs_install_sd" command from vision apps folder. You have just created SD card by running mk-linux-card.sh script and then install_to_sd_card.sh script. This essentially means you are flashing Linux kernel, filesystem from PSDKLA release. 

    In the second non-working case, you are using vision apps binaries, so DSS is configured with the fixed 1080p output resolution.. It seems parameters are not matching with the supported resolution on the monitor. 

    I have just tried again to flash the prebuilt image using mk-linux-card.sh and install_to_sd_card.sh and the system did not display anything to the display port monitor.

    Can we please do one experiment? Can we please read few registers from case-1, ie working case and use them in case-2?


    Do you mean the framebuffer hardware interface registers? I'll see how to add some debugging for that.

    Thanks,

    James

  • 0 in reply to James Graves1
    TI__Guru**** 449545 points

    Hi James,

    Surprising, timing parameters for mode-0 is what we are trying to set from the vision apps. This is exactly matching with the vision apps settings.  One problem is Mode-0 and Mode-15 are exactly same. so wondering if there is any issue with this.

    Can you try forcing Mode-0 from your desktop and see if it works fine?

    Modeline "Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
    Modeline "Mode 15" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Prodigy 170 points

    Hi Brijesh,

    One problem is Mode-0 and Mode-15 are exactly same. so wondering if there is any issue with this.

    Can you try forcing Mode-0 from your desktop and see if it works fine?

    Modeline "Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
    Modeline "Mode 15" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync

    The modes are more how Linux (the desktop, in this case) keeps track of things, if the hardware is outputting the same exact timing with the same polarity of the sync signals, then it won't make a difference to the monitor. I don't think the mode number itself matters.

    Also note that we're not seeing an error message about an invalid mode, there is no output whatsoever to the monitor.  The monitor indicates that a cable has been plugged in, but there is no signal.

    So I did get a chance to look at the board a little bit more, to try to see what is going on.

    Early in the boot for the "doesn't work" case, we see this:

    ** File not found /lib/firmware/j7-mcu-r5f0_0-fw **

    And later on we see this from Linux:

    remoteproc remoteproc1: Direct firmware load for j7-mcu-r5f0_0-fw failed with error -2
    remoteproc remoteproc1: powering up 41000000.r5f
    remoteproc remoteproc1: Direct firmware load for j7-mcu-r5f0_0-fw failed with error -2
    remoteproc remoteproc1: request_firmware failed: -2

    And we don't see those error messages in the "works" case.

    Also, in the "works" case, we do see this on the Linux console:

    [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
    [drm] No driver support for vblank timestamp query.
    [drm] Initialized tidss 1.0.0 20180215 for 4a00000.dss on minor 1
    cdns-mhdp a000000.dp-bridge: [drm:cdns_mhdp_get_edid_block [cdns_mhdp]] *ERROR* get block[0] edid failed: -22
    cdns-mhdp a000000.dp-bridge: [drm:cdns_mhdp_get_modes [cdns_mhdp]] *ERROR* Failed to read EDID
    cdns-mhdp a000000.dp-bridge: [drm:mhdp_transfer [cdns_mhdp]] *ERROR* Failed to read DPCD
    cdns-mhdp a000000.dp-bridge: [drm:mhdp_transfer [cdns_mhdp]] *ERROR* Failed to read DPCD

    and later:

    tidss 4a00000.dss: fb0: tidssdrmfb frame buffer device

    But in the "doesn't work" case, we don't see any status messages from the dp-bridge or framebuffer drivers.

    And then when I look at /dev with the two cases, there is a /dev/fb0 in the "works" case, and that device does not exist in the "doesn't work" case.

    So there is nothing being displayed on the monitor, because there is no means to do so.

    I'll try to look more closely at how the initialization of the Cortex-R5F differs between the two cases, and try to figure out what's wrong.  It is my understanding that the Cortex R5F core initializes the display hardware (and cameras, if any) and makes control of them available to Linux when it has finished booting up.

    Best Regards,

    James

  • 0 in reply to James Graves1
    TI__Guru**** 449545 points

    Hi James,

    In the working case, it seems the display is controlled by the Linux and Linux has support for the EDID read and can select one of the recommended mode, so Linux sets up one of the recommended mode and it works. This may not be 1080p resolution. 

    In the non-working case, ie when you copy vision apps binaries by running make linux_fs_install_sd command, DSS is controlled by R5F. In this case, display resolution is fixed to 1080p, which i think is not working/supported with the monitor.

    From the working case, can you please read DSS timing registers to get the timing information and we can use it on R5F to display resolution? 

    In addition, can you please check if appDssConfigureDP is getting called from ti-processor-sdk-rtos-j721e-evm-07_01_00_11\vision_apps\utils\dss\src\app_dss_j721e.c file? 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    TI__Guru**** 449545 points

    Hi James,

    In case working case, can you boot Linux and read below three registers? This will help me understand what timing are being used in working case. 

    0x04A80050

    0x04A80054

    0x04A80058

    Then we can use below FAQ to change this resolution in vision apps. Hopefully then it should work even from vision apps. 

    [FAQ] PROCESSOR-SDK-DRA8X-TDA4X: How to change display resolution in vision apps? - Processors forum...

    e2e.ti.com
    Part Number: PROCESSOR-SDK-DRA8X-TDA4X Vision apps demos uses 1920x1080 display resolution. This article explains how to change resolution and demo to use new resolutions

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Prodigy 170 points

    Hello Brijesh,

    My colleague was looking for the register values for the DSS.  According to the DSS Documentation, it seems like  /sys/kernel/debug/omapdrm/ is the place to look for the register values, but this directory does not exist.  There are other debugfs folders though, so it seems that is enabled for the kernel.  We're still investigating this.

    Best Regards,

    James

  • 0 in reply to James Graves1
    TI__Guru**** 449545 points

    Hi James,

    If you have JTAG/CCS, then you could connect to mcu1_0 R5F core and can get the values of these registers. mcu1_0 will be on, even if only Linux is running.

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Prodigy 60 points

    Hi Brijesh,

    We are using the TI TDA4 dev board as is, and we are using TI software as is. Our expectation is that the demo applications will run and display out to the monitor with no modifications. We are not modifying any board setup or any software.

    As we stated early on in this post a month ago, we copied TI provided files onto an SD card per instructions provided by TI, but nothing was displayed to the monitor.

    Please confirm, advise, and provide the exact process and files, including version or release numbers of TI software and tools, that should be used in order to successfully display TI demo apps on the TDA4 dev board. For your reference, in case it is needed, the attached photos show the serial numbers and other labels on the TDA4 dev board we have.

    Best regards,

    Debbie

  • 0 in reply to Debbie Jones
    TI__Guru**** 449545 points

    Hi Debbie, James,

    Can you please follow below steps to figure out, which resolution is supported and displayed by Linux?

    1, Prepare the SD card with the out of box demos, as explained at 

    https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/psdk_rtos/docs/user_guide/out_of_box_j721e.html

    2, Open uEnv.txt file from the BOOT partition and comment out the line "name_overlays=k3-j721e-vision-apps.dtbo", save the file and exit.

    3, Now boot the board with this change. 

    4, You should see image displayed on the monitor with the recommended mode settings. 

    5, Read the display registers using omapconf utility or using CCS by connecting it to mcu r5f. Read three register 0x04A80050, 0x04A80054, 0x04A80058

    6, then we need to use these values to change display resolution in the vision apps. 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Prodigy 170 points

    Hello Brijesh,

    We ended up purchasing a Dell P2419H Display Port monitor.  After running through the instructions to prepare a micro-SD card again, installing the basic operating system, vision apps, and sample data, everything ran perfectly!

    So we can add the Asus VP247 to the "not supported" list I guess.

    We did look at the display timing for the Asus monitor when it was connected to a Linux desktop with a GPU. It was using the exactly same 1080p 60Hz timing as was hardcoded in the app_init.c file. This is the same timing as was in the EDID listing, so everything matches up there.

    As mentioned previously, there was no indication that the Asus monitor was receiving any signal at all, because there was no error message saying that the output resolution was not supported.

    We will next be taking a very close look at the exactly what happens with the Display Port initialization in the RTOS code and how that differs between the two monitors.

    We had an issue with running CCS on the attached computer, so we're going to swap that out and try to display the register values that you had requested.

    Best Regards,

    James

  • 0 in reply to James Graves1
    TI__Guru**** 449545 points

    Hi James,

    ok, that's strange. 

    Can you try one more change on the non-working monitor? 

    Can you change flag isHpdSupported flag to false in vision_apps/utils/dss/src/app_dss.c file, at around line number 130, rebuild the vision apps and see if it helps?

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Prodigy 170 points

    Hello Brijesh,

    My team members did get CCS working, and was able the display the register values while trying to run the vision demo apps with the not-supported Asus monitor:

    0x04A80050 DSS0_VP1_DSS0_VP_SIZE_SCREEN
    0x04A80050 0437077F
    0x04A80054 DSS0_VP1_DSS0_VP_TIMING_H
    0x04A80054 0930572B
    0x04A80058 DSS0_VP1_DSS0_VP_TIMING_V
    0x04A80058 02400404

    I'll ask them about changing that  isHpdSupported flag in the vision_apps/utils/dss/src/app_dss.c file.

    Best Regards,

    James

  • 0 in reply to James Graves1
    TI__Guru**** 449545 points

    Hi James,

    Could you also please share the first 20 registers from offset 0x04A80000?

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Prodigy 170 points

    Hi Brijesh,

    Here's the screenshot of the memory browser.

    BR,

    James

  • 0 in reply to James Graves1
    TI__Guru**** 449545 points

    Hi James,

    Only one difference i see in the register setting. bit5 in VP_CONTROL register should not be set. Can you try manually setting it to 0 and see if you get correct output on DP? 

    I will check how to reset it from vision apps. 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Prodigy 170 points

    Hello Brijesh,

    My coworker tried modifying the VP_CONTROL register, and this is what she reports:

    Following the same setup we are not able to set bit5 in the VP_CONTROL register to 0 when the vision apps are running. When a vision app is running, bit5 in the VP_CONTROL register automatically reverts when we try to change it. To verify that we were taking the correct approach, we modified bit6 of the same register while connected to the working monitor and saw a visible change on the display.

    It seems that when no vision apps are running bit5 of the VP_CONTROL register is set to 0. Overall, the behavior that we are seeing is that bit5 is set when the vision apps are running and is not set when no vision apps are running. Is this the expected behavior, or does this bit need to be set to 0 when the vision apps are running?

    Best Regards,

    James

  • 0 in reply to James Graves1
    TI__Guru**** 449545 points

    Hi James,

    DPI-Enables does not make any difference, i tried to disable it on the EVM, but i dont see any change in the display. So you could ignore it.

    Did you get the chance to try out setting flag isHpdSupported to false?

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Prodigy 170 points

    Brijesh Jadav said:

    DPI-Enables does not make any difference, i tried to disable it on the EVM, but i dont see any change in the display. So you could ignore it.

    Did you get the chance to try out setting flag isHpdSupported to false?

    Hello Brijesh,

    My colleague reported this:

    I toggled the setting of the flag isHpdSupported, but it did not result in the vision apps producing any output to the Asus monitor.
    One thing worth noting is that I did notice that the startup of the vision apps different based on the setting of isHpdSupported. When this flag is set to true, the vision apps will fully start up and will show on the terminal as 'running'. When this flag is set to false, as TI recommended, the vision apps do not fully start up and freeze before reaching the control menu for the app. The apps seem to freeze before reaching a point where any error messages are generated.
    I'll work with my team to pinpoint exactly where the app stops and see if that tells us anything.
    BR,
    James

  • 0 in reply to James Graves1
    TI__Guru**** 449545 points

    Hi James, Debbie,

    Any further questions/update on this thread?

    Regards,

    Brijesh