J784S4XEVM: Compatibility Check and Driver Support Request – TI J784S4 EVM with Lilliput TK1330-NP/C/T Touch Display

Hi,

Please expect a delay in response due to U.S holidays.

Regards,

kb

Hi Chethan,

If using the EVM, you would need an active (as opposed to passive) HDMI to DP adapter to use a HDMI monitor. But display-wise, no special driver is usually needed. 

For touch, you may need to enable some additional drivers, but if there is a Linux kernel driver available for your specific monitor, it should be straight forward to enable on TI platform since TI Linux is based off of the standard upstream Linux kernel.

But in any case, we have used the GeChic On-Lap 1303 13.3" for demos in the past within TI. It has HDMI, VGA, and mini DisplayPort capabilities, and touch through USB.

Regards,

Takuma

Hi Takuma,

Hi Chethan,

Chethan Reddy Chinthaparthi said:

• Could you please suggest any 13.3" touch display with native DisplayPort (DP) input that is known to work well with the TI EVM, as an alternative to HDMI-based displays?
• We noticed that the GeChic On-Lap 1303 13.3" display appears to be unavailable on the official website and may have been discontinued. Do you have any recommended replacement models that TI has evaluated or used successfully?

We have obtained and used the GeChic display recently (in the last year). Otherwise, we have used a Viewsonic TD1655.

Chethan Reddy Chinthaparthi said:

We currently have a CableCreation Active DisplayPort-to-HDMI (4K@60Hz) adapter. However, when connecting the TDA4VH EVM to an HDMI monitor through this adapter, the display is not detected. Both DP outputs on the TDA4VH are currently configured for FHD (1080p) resolution. Could this configuration be contributing to the detection issue, or are there any known compatibility requirements for DP-to-HDMI adapters on the EVM?

May be a different issue. If using the default Linux image, the uEnv.txt in boot partition may have a name_overlays variable that sets the devicetree overlays to disable the display from Linux. This was put to allow integration with RTOS drivers for running the vision apps demo that uses the RTOS display drivers as opposed to Linux display driver.

So I suggest first checking the uEnv.txt file in boot partition.

Chethan Reddy Chinthaparthi said:

For touch functionality, we understand that the touch interface is expected to be connected via USB. The TDA4VH EVM provides only a single USB-C port, which is already being used for another purpose. Would using a USB hub be a supported approach to connect both devices while maintaining full functionality? Are there any bandwidth, power, or driver-related limitations we should be aware of when using a USB hub for this setup?

When we were using the touchscreens mentioned in my previous responses, we did not see any bandwidth, power, or driver related limitation. We have also tried using USB hubs to increase USB count, and have not met issues.

However, as a disclaimer, touchscreen and USB hub is usually used for demonstration purposes only, so not something that we test vigorously for production within SDK. So we don't have exact performance measurements for using USB hub. We just have the data that they were functional for our use cases (such as connecting keyboard/mouse, camera, touchscreen input, etc).

Regards,

Takuma

Hi Takuma,

Hi Chethan,

Understood. Then RTOS display driver should be in use. The RTOS display driver has a fixed, hardcoded display timing parameter, so it could be that the timing parameters are incompatible with the HDMI monitor (even on monitors that have both DP and HDMI input, the two interfaces may have different default resolutions depending on the monitor). 

If Linux driver is used, sometimes the monitors may work as Linux driver uses the display's EDID to try to adjust the display timing parameters. As an experiment, you could test removing the k3-j784s4-vision-apps.dtbo overlay - this will make the vision apps demo not work, but enable the Linux display driver and wayland/weston compositor to come up on the display automatically at boot time. Assuming there are no errors and display is detected by Linux driver.

Regards,

Takuma

Hi Takuma,

Hi Chethan,

Thanks for trying out the experiments. Looks like issue is specific to RTOS driver. We have seen something similar in the past in this following E2E:  RE: TDA4VM: SDK 9.0 patch for eDP to HDMI bug 

As the next step for troubleshooting, in <PSDK_RTOS>/sdk_builder/vision_apps_build_flags.mak, can you add BUILD_ENABLE_ETHFW=no, then rebuild and redeploy the MCU2_0 firmware, similar to the thread I linked?

Regards,

Takuma

Hi Takuma,

In <PSDK_RTOS>/sdk_builder/vision_apps_build_flags.mak, I added the following highlighted line:

BUILD_PTK?=yes
BUILD_ENABLE_ETHFW?=yes

# ETHFW is not supported on the below platforms
ifneq (,$(filter $(SOC),j721s2 am62a j722s j742s2))
BUILD_ENABLE_ETHFW=no
endif

ifeq ($(RTOS),SAFERTOS)
ifeq ($(SOC),$(filter $(SOC), j784s4 j742s2))
BUILD_ENABLE_ETHFW=no
endif
endif

ifeq ($(BUILD_EDGEAI),yes)
BUILD_ENABLE_ETHFW=no
endif

# Need to export this variable so that the following xdc .cfg file can pick this up from the env:
# ${PSDK_PATH}/vision_apps/platform/$(SOC)/rtos/mcu2_0/mcu2_0.cfg
export BUILD_ENABLE_ETHFW

ifeq ($(BUILD_ENABLE_ETHFW),yes)
# Enable iperf server (TCP only) by default
ETHFW_IPERF_SERVER_SUPPORT?=yes
# gPTP stack support - currently supported in FreeRTOS build only
ifeq ($(RTOS),FREERTOS)
ETHFW_GPTP_SUPPORT?=yes
BUILD_ENABLE_ETHFW=no
endif

cd sdk_builder
./make_sdk.sh

make[4]: Circular all <- all dependency dropped.
make[4]: Circular all <- all dependency dropped.
SOC=j784s4
TARGET_CPU=A72
SOC=j784s4
TARGET_CPU=A72
SOC=j784s4
TARGET_CPU=A72
SOC=j784s4
TARGET_CPU=A72
SOC=j784s4
TARGET_CPU=A72
SOC=j784s4
TARGET_CPU=A72

 undefined                first referenced                                                                                                                                                         
  symbol                      in file                                                                                                                                                              
 ---------                ----------------                                                                                                                                                         
 appEthFwEarlyInit        ~/ti-processor-sdk-rtos-j784s4-evm-11_01_00_04/vision_apps/out/J784S4/R5F/FREERTOS/release/module/platform.j784s4.rtos.mcu2_0+linux/main.obj
 appEthFwInit             ~/ti-processor-sdk-rtos-j784s4-evm-11_01_00_04/vision_apps/out/J784S4/R5F/FREERTOS/release/app_rtos_common_mcu2_0.lib<app_init.obj>         
 appEthFwRemoteServerInit ~/ti-processor-sdk-rtos-j784s4-evm-11_01_00_04/vision_apps/out/J784S4/R5F/FREERTOS/release/app_rtos_common_mcu2_0.lib<app_init.obj>         

error: unresolved symbols remain
error: errors encountered during linking;
   "~/ti-processor-sdk-rtos-j784s4-evm-11_01_00_04
   /vision_apps/out/J784S4/R5F/FREERTOS/release/vx_app_rtos_linux_mcu2_0.out"
   not built
tiarmclang: error: tiarmlnk command failed with exit code 1 (use -v to see invocation)
make[2]: *** [~/ti-processor-sdk-rtos-j784s4-evm-11_01_00_04/sdk_builder/concerto/finale.mak:218: ~/ti-processor-sdk-rtos-j784s4-evm-11_01_00_04/vision_apps/out/J784S4/R5F/FREERTOS/release/vx_app_rtos_linux_mcu2_0.out] Error 1
make[1]: *** [makerules/makefile_vision_apps.mak:54: vision_apps] Error 2
make: *** [Makefile:64: sdk] Error 2

Additionally, we tried to 

Run vision_apps/TIOVX CSI2RX+ISP capture on remote cores while also getting Weston/Wayland working via Linux tidss DRM (not TIOVX's display node).

Changes made so far:

Decompiled stock k3-j784s4-vision-apps.dtbo, edited fragments 42/43/44 (dss, mhdp, serdes_wiz4) from disabled→okay, left 45/46/47 (ti_csi2rx0/1/2) disabled to preserve remote-core camera ownership. Recompiled, deployed to /boot/dtb/ti/k3-j784s4-vision-apps-fixed.dtbo, updated uEnv.txt name_overlays=.

This got dss/mhdp live in DT but tidss still wouldn't bind (modetest showed only pvrsrvkm). Traced via /sys/kernel/debug/devices_deferred: connector-dp0/dp1 were stuck on regulator-dp0/dp1-prw, stuck on "can't get GPIO."
Found the GPIO expander (TCA6408) feeding those regulators lives on i2c@2040000, which was disabled at the base board DTB level. Added a new fragment@48 to the overlay to force i2c@2040000 → okay. Recompiled, redeployed, rebooted. (Verification of this fix — devices_deferred clean, modetest -M tidss showing a real device — was the last checkpoint on the display side; not yet re-confirmed with fresh output.)

Then moved to camera track — new problem:

Enumerating sensors failed + REMOTE_SERVICE: Unable to find handler for service [com.ti.image_sensor].

APP: Init ... !!!
44.689812 s: MEM: Init ... !!!
44.689876 s: MEM: Initialized DMA HEAP (fd=5) !!!
44.690034 s: MEM: Init ... Done !!!
44.690051 s: IPC: Init ... !!!
44.724618 s: IPC: Init ... Done !!!
REMOTE_SERVICE: Init ... !!!
REMOTE_SERVICE: Init ... Done !!!
44.736218 s: GTC Frequency = 200 MHz
APP: Init ... Done !!!
44.738071 s: VX_ZONE_INFO: Globally Enabled VX_ZONE_ERROR
44.738086 s: VX_ZONE_INFO: Globally Enabled VX_ZONE_WARNING
44.738099 s: VX_ZONE_INFO: Globally Enabled VX_ZONE_INFO
44.741361 s: VX_ZONE_INFO: [tivxPlatformCreateTargetId:169] Added target MPU-0
44.741458 s: VX_ZONE_INFO: [tivxPlatformCreateTargetId:169] Added target MPU-1
44.741546 s: VX_ZONE_INFO: [tivxPlatformCreateTargetId:169] Added target MPU-2
44.741632 s: VX_ZONE_INFO: [tivxPlatformCreateTargetId:169] Added target MPU-3
44.741646 s: VX_ZONE_INFO: [tivxInitLocal:202] Initialization Done !!!
44.741661 s: VX_ZONE_INFO: Globally Disabled VX_ZONE_INFO
44.744319 s: ISS: Enumerating sensors ... !!!
44.744535 s: ISS: ERROR: Enumerating sensors failed !!!
appCreateImageSensor returned -1
44.744567 s: ISS: Initializing sensor [IMX390-UB953_D3], doing IM_SENSOR_CMD_PWRON ... !!!
44.744679 s: ISS: ERROR: Initializing sensor [IMX390-UB953_D3] failed !!!
44.744690 s: ISS: Initializing sensor [IMX390-UB953_D3] ... Done !!!
Error initializing sensor IMX390-UB953_D3

Hi Chethan,

For the build error, could you try adding DISABLE_RECURSE_DEPS=no environment variable when building?

As for the runtime error, this is expected. The vision apps demo expects the R5F and RTOS to have control of display driver. However, by modifying the devicetree, it enables the A72 and Linux to have control of the display driver. So, the display will work for running Linux applications, but vision apps demos that depend on the R5F running the RTOS display driver will not run.

In practice, it is feasible to have the display driver running within A72 Linux and you could create a custom application that uses A72 Linux display instead of the R5F RTOS display, but for the vision apps demo the demo assumes R5F RTOS display driver - which in your case is failing with the HDMI display.

There is a patch in the thread I shared, but as a next step after solving the build issue, my suggestion would be to try the patch.

Regards,

Takuma