TDA4VM: SDK 9.0 patch for eDP to HDMI bug

Hi Fred,

Unfortunately, it is still not fixed, we are still debugging this issue. 

Btw, can you please share some info on eDP to HDMI convertor that you are using? Also can you please confirm that this was consistently working fine for SDK8.6? 

Regards,

Brijesh

Hi Brijesh,

I don't have the model at hand, I will udpate when I do. But I can tell you that we've used more than one model and the issue happens on all.

We didn't have any issue with SDK 8.6.

Here's one of the models we're using:

Thanks FredC_LT, will check with team.

Regards,

Brijesh

Hi FredC_LT,

Just wanted to update you that this is not yet resolved and we are still debugging this issue. Suspecting some issue in configuring external IO expander.

Regards,

Brijesh

Hi FredC_LT,

Can you please try with the change that i suggested on below link, especially change #2 ?

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1274629/j721s2xsomxevm-tda4al-not-display-by-dp-port/4839618#4839618

Regards,

Brijesh

Hi Brijesh,

The patch you're suggesting is for J721S2, but we don't have an issue with that board. Only J721E. Does that patch apply to the J721E SDK?

EDIT: I don't think this patch can be applied as-is to j721e. Please let me know which file to modify.

Could you also provide instructions on how to rebuild the .dtso, and where is the newly built .dtbo located, please?

Hi Fred,

The modifications are to the J721S2 overlay files, which will not directly fix. Brijesh probably meant equivalent changes on J721E.

Do you have references of what dtb + overlays you are loading between J721E 8.6 SDK and 9.0 SDK?

regards

Suman

Hi Suman,

I don't have a TDA4VM on SDK 9.0 accessible right now and I'm not in the lab to swap SD cards. I don't think we change what's used from the original prebuilt image.

For SDK 8.6, here's what's in /run/media/mmcblk1p1/uEnv.txt

name_overlays=k3-j721e-vision-apps.dtbo k3-j721e-common-proc-board-mcp79410.dtbo k3-j721e-cpb-d3-serdes.dtbo k3-j721e-cpb-d3-serdes-conti-fsc230-porta.dtbo

Hi FredC_LT,

Can you please try updating your dtb file as suggested in the above link? Essentially, please make this regulator to be always on. 

Regards,

Brijesh

Hi Brijesh,

The regulator "dp0_pwr_3v3: fixedregulator-dp0-prw" only exists for k3-j721s2-common-proc-board, which is not used in the J721E's prebuilt image. Please provide the equivalent instructions for j721e.

Hi Suman,

Following the discussion this morning, I have tried the following

Try SDK 8.6 .dtbo's on SDK 9.0

1. Switch to sdk 8.6
2. Copy /boot/k3-j721e-vision-apps.dtbo locally
3. Switch to sdk 9.0
4. Copy k3-j721e-vision-apps.dtbo to /boot/dtb/ti/k3-j721e-vision-apps.dtbo
5. Reboot
6. Test

This hasn't fixed the issue, there is still no display.

Try SDK 8.6 firmware on SDK 9.0

1. Switch to sdk 8.6
2. Copy /lib/firmware/vision_apps_evm/vx_app_rtos_linux_mcu2_*.out locally
3. Switch to sdk 9.0
4. Copy vx_app_rtos_linux_mcu2_*.out to /lib/firmware/vision_apps_evm
5. Reboot
6. Test

This just does not work as there have been OpenVX API changes between both SDKs. I just get a bunch of:

612.188947 s: VX_ZONE_ERROR:[ownContextSendCmd:822] Command ack message returned failure cmd_status: -7
612.189109 s: VX_ZONE_ERROR:[ownContextSendCmd:862] tivxEventWait() failed.
612.189157 s: VX_ZONE_ERROR:[ownNodeKernelInit:527] Target kernel, TIVX_CMD_NODE_CREATE failed for node DisplayNode
612.189197 s: VX_ZONE_ERROR:[ownNodeKernelInit:528] Please be sure the target callbacks have been registered for this core
612.189236 s: VX_ZONE_ERROR:[ownNodeKernelInit:529] If the target callbacks have been registered, please ensure no errors are occurring within the create callback of this kernel
612.189278 s: VX_ZONE_ERROR:[ownGraphNodeKernelInit:583] kernel init for node 1, kernel com.ti.display ... failed !!!
612.189323 s: VX_ZONE_ERROR:[vxVerifyGraph:2055] Node kernel init failed
612.189362 s: VX_ZONE_ERROR:[vxVerifyGraph:2109] Graph verify failed

Hi Fred,

Thanks for the experiments, and the update.

I am looking through the device-tree changes, will update you in an hour or so.

regards

Suman

Hi Fred,

I looked through the schematics. While the J721S2 SoM enables two display ports, with the second one supporting a DP Bridge device. The J721E EVM is only supporting one Display Port.

The changes suggested in the other thread are related to using the Linux-side Display driver rather than the R5F-side display driver. I don't think you are trying to use the A72-side Display driver, and wanting to use the stock display from R5F side. As such, I don't have any equivalent changes on the Linux device-tree.

I have also reviewed the vision-apps related device-tree changes, and I do not see any significant deltas. Are you modifying any of these nodes within the three non-TI dtb overlays - k3-j721e-common-proc-board-mcp79410.dtbo, k3-j721e-cpb-d3-serdes.dtbo, k3-j721e-cpb-d3-serdes-conti-fsc230-porta.dtbo

One other experiment you can try is to use the 8.6 sysfw.itb and alongside your 9.0 SDK components.

regards

Suman

Hi Fred,

Please also try rebuilding the VisionApps firmwares without EthFW enabled.

You can do this by setting BUILD_ENABLE_ETHFW to no in the <RTOS_SDK>/sdk_builder/vision_apps_build_flags.mak file and rebuilding the SDK.

regards

Suman

Hi Suman, thanks for taking the time to look into this.

Did you try to reproduce on your side with J721E? That could also be telling if it's our setup or not.

Suman Anna said:

I don't think you are trying to use the A72-side Display driver, and wanting to use the stock display from R5F side.

You are correct, we are using the display node on the R5F.

Suman Anna said:

Are you modifying any of these nodes within the three non-TI dtb overlays - k3-j721e-common-proc-board-mcp79410.dtbo, k3-j721e-cpb-d3-serdes.dtbo, k3-j721e-cpb-d3-serdes-conti-fsc230-porta.dtbo

I will ask the team that developed them, but I don't think they're relevant as they were not part of the SDK 9.0 image that I was using.

Suman Anna said:

One other experiment you can try is to use the 8.6 sysfw.itb and alongside your 9.0 SDK components.

Where is that located?

Suman Anna said:

Please also try rebuilding the VisionApps firmwares without EthFW enabled.

That's already the case. Here are the modifications we do for that:

• vision_apps/build_flags.mk

--- a/build_flags.mak
+++ b/build_flags.mak
@@ -3,3 +3,7 @@ PSDK_BUILDER_PATH ?= $(PSDK_PATH)/sdk_builder
 
 # Inherit common build flags from root repo in SDK
 include $(PSDK_BUILDER_PATH)/vision_apps_build_flags.mak
+
+BUILD_MCU_BOARD_DEPENDENCIES := no
+BUILD_ENABLE_ETHFW := no

• vision_apps/platform/j721e/rtos/common/app_cfg_mcu2_0.h

--- a/platform/j721e/rtos/common/app_cfg_mcu2_0.h
+++ b/platform/j721e/rtos/common/app_cfg_mcu2_0.h
@@ -103,13 +103,13 @@
 
     #undef ENABLE_CSI2RX
     #undef ENABLE_CSI2TX
-    #undef ENABLE_DSS_SINGLE
+    #define ENABLE_DSS_SINGLE
     #undef ENABLE_DSS_DUAL
-    #undef ENABLE_DSS_EDP
+    #define ENABLE_DSS_EDP
     #undef ENABLE_DSS_HDMI
     #undef ENABLE_DSS_DSI
-    #undef ENABLE_I2C
-    #undef ENABLE_BOARD
+    #define ENABLE_I2C
+    #define ENABLE_BOARD
 
 #endif

• vision_apps/platform/j721e/rtos/common/app_init.c

--- a/platform/j721e/rtos/common/app_init.c
+++ b/platform/j721e/rtos/common/app_init.c
@@ -81,7 +81,7 @@
 #include <utils/hwa/include/app_hwa.h>
 #endif
 
-#if defined(ENABLE_I2C) && defined(ENABLE_CSI2RX)
+#if defined(ENABLE_I2C) || defined(ENABLE_CSI2RX)
 #include <utils/sensors/include/app_sensors.h>
 #include <utils/iss/include/app_iss.h>
 #endif

Hi Fred,

FredC_LT said:

Did you try to reproduce on your side with J721E? That could also be telling if it's our setup or not.

I haven't tried it, but this is already listed as a Known Issue in our release.

FredC_LT said:

Where is that located?

You should be able to find the equivalent file in the prebuilt-images folder or the boot tarball from the 8.6 SDK.

regards

Suman

Hi Suman,

I just tried swapping the 9.0 sysfw.itb (/run/media/BOOT-mmcblk1p1/sysfw.itb) with the one from 8.6 (/run/media/mmcblk0p1/sysfw.itb), but that didn't fix it.

The test was done with a network streamer. I'll test again with a display connected instead next week. But I don't have much hope.

Hi FredC LT,

Can you please try two more changes?

1, Please apply attached patch on uboot folder board-support\ti-u-boot-2023.04+gitAUTOINC+71b8c840ca-g71b8c840ca, rebuild uboot and copy tiboot3.bin, u-boot.img and tispl.bin into SD card 

/cfs-file/__key/communityserver-discussions-components-files/791/j721e_5F00_uboot_5F00_enable_5F00_dp_5F00_pwr.patch

2, Please apply attached patch on Linux folder board-support\ti-linux-kernel-6.1.46+gitAUTOINC+5892b80d6b-g5892b80d6b, regenerate Linux dtbs and copy coommon-proc-board dtb file to SD card 

/cfs-file/__key/communityserver-discussions-components-files/791/j721e_5F00_Linux_5F00_enable_5F00_dp_5F00_pwr.patch

Can you please try with the attached changes? 

Regards,

Brijesh

Hi Brijesh, I will try it.

Could you please just point me to instructions on

• how to rebuild uboot
• how to regenerate linux dtbs

Hi Fred,

The Linux SDK top-level Makefile should have ready-made build targets for building U-Boot and Linux dtbs.

Please follow the setup instructions and adjust any variables as needed for your installation. Refert to the Linux SDK 1.3. Simplified SDK Build Using Top-Level Makefile section for details.

$ cd <ti-processor-sdk-linux-adas-j721e-evm-09_00_01_03>

$ make u-boot

$ make linux-dtbs

regards

Suman

Hi,

I tried applying the patches, but the board doesn't boot now. I'll go to the lab tomorrow to have access to the serial port.

There were 3 different k3-j721e-common-proc-board.dtb in the sdk directory after building, I don't know if I used the right one.

Here are my steps, just to validate and document:

1. Apply patch

I did not have the same paths as you mentioned. Here's what I used instead:

board-support\ti-u-boot-2023.04+gitAUTOINC+71b8c840ca-g71b8c840ca/arch/arm/dts/k3-j721e-common-proc-board.dts

 -> board-support/u-boot-2023.04+gitAUTOINC+756ba776d4-g756ba776d4/arch/arm/dts/k3-j721e-common-proc-board.dts

board-support\ti-linux-kernel-6.1.46+gitAUTOINC+5892b80d6b-g5892b80d6b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts

-> board-support/linux-6.1.33+gitAUTOINC+8f7f371be2-g8f7f371be2/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts

2. Recompile

make u-boot_clean -j

make u-boot -j

make linux-dtbs

2. Upload

And then, I scp'ed the following files to the board

cd board-support/u-boot-2023.04+gitAUTOINC+756ba776d4-g756ba776d4/build/

scp a72/tispl.bin root@<ip>:/run/media/BOOT-mmcblk1p1

scp a72/u-boot.img root@<ip>:/run/media/BOOT-mmcblk1p1

scp r5/tiboot3.bin root@<ip>:/run/media/BOOT-mmcblk1p1

cd ../../..

scp ./board-support/u-boot-2023.04+gitAUTOINC+756ba776d4-g756ba776d4/build/a72/arch/arm/dts/k3-j721e-common-proc-board.dtb root@<ip>:/boot/dtb/ti

Hi Suman, just confirming that using sysfw.itb from SDK 8.6 on 9.0 doesn't fix the issue.

Hi Brijesh,

I'm not able to make it work.

If I upload board-support/linux-6.1.33+gitAUTOINC+8f7f371be2-g8f7f371be2/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts, it breaks the ethernet and hangs in u-boot

If I upload instead ./board-support/linux-6.1.33+gitAUTOINC+8f7f371be2-g8f7f371be2/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dtb, then the device boots, but the R5F does initializes the VPAC, i.e. instead of seeing these logs when sourcing /opt/vision_apps/vision_apps_init.sh:

[MCU2_0]   1491.117719 s:  VX_ZONE_INIT:Enabled
[MCU2_0]   1491.117748 s:  VX_ZONE_ERROR:Enabled
[MCU2_0]   1491.117772 s:  VX_ZONE_WARNING:Enabled
[MCU2_0]   1491.119232 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target MCU2-0 
[MCU2_0]   1491.119440 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target VPAC_NF 
[MCU2_0]   1491.119635 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target VPAC_LDC1 
[MCU2_0]   1491.119828 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target VPAC_MSC1 
[MCU2_0]   1491.120047 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target VPAC_MSC2 
[MCU2_0]   1491.120340 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target VPAC_VISS1 
[MCU2_0]   1491.120580 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target CAPTURE1 
[MCU2_0]   1491.120806 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target CAPTURE2 
[MCU2_0]   1491.121053 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target DISPLAY1 
[MCU2_0]   1491.121300 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target DISPLAY2 
[MCU2_0]   1491.121498 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target CSITX 
[MCU2_0]   1491.121730 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target CAPTURE3 
[MCU2_0]   1491.121983 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target CAPTURE4 
[MCU2_0]   1491.122229 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target CAPTURE5 
[MCU2_0]   1491.122466 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target CAPTURE6 
[MCU2_0]   1491.122706 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target CAPTURE7 
[MCU2_0]   1491.122953 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target CAPTURE8 
[MCU2_0]   1491.123172 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target DSS_M2M1 
[MCU2_0]   1491.123376 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target DSS_M2M2 
[MCU2_0]   1491.123582 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target DSS_M2M3 
[MCU2_0]   1491.123787 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:66] Added target DSS_M2M4 
[MCU2_0]   1491.123843 s:  VX_ZONE_INIT:[tivxInitLocal:130] Initialization Done !!!

I see

[MCU2_0]   2051.131601 s: DSS: Init ... !!!
[MCU2_0]   2051.131627 s: DSS: Display type is eDP !!!
[MCU2_0]   2051.131650 s: DSS: M2M Path is enabled !!!
[MCU2_0]   2051.131672 s: DSS: SoC init ... !!!
[MCU2_0]   2051.131690 s: SCICLIENT: Sciclient_pmSetModuleState module=152 state=2
[MCU2_0]   2051.131931 s: SCICLIENT: Sciclient_pmSetModuleState success
[MCU2_0]   2051.131964 s: SCICLIENT: Sciclient_pmSetModuleState module=297 state=2
[MCU2_0]   2051.132485 s: SCICLIENT: Sciclient_pmSetModuleState success
[MCU2_0]   2051.132524 s: SCICLIENT: Sciclient_pmSetModuleState module=151 state=2
[MCU2_0]   2051.133072 s: SCICLIENT: Sciclient_pmSetModuleState success
[MCU2_0]   2051.133106 s: SCICLIENT: Sciclient_pmSetModuleClkParent module=152 clk=9 parent=11
[MCU2_0]   2051.133772 s: SCICLIENT: Sciclient_pmSetModuleClkParent success
[MCU2_0]   2051.133807 s: SCICLIENT: Sciclient_pmSetModuleClkParent module=152 clk=13 parent=18
[MCU2_0]   2051.134396 s: SCICLIENT: Sciclient_pmSetModuleClkParent success
[MCU2_0]   2051.134431 s: SCICLIENT: Sciclient_pmSetModuleClkParent module=152 clk=1 parent=2
[MCU2_0]   2051.134962 s: SCICLIENT: Sciclient_pmSetModuleClkParent success
[MCU2_0]   2051.134996 s: SCICLIENT: Sciclient_pmSetModuleClkFreq module=152 clk=1 freq=148500000
[MCU2_0]   2051.136587 s: SCICLIENT: Sciclient_pmSetModuleClkFreq success
[MCU2_0]   2051.136622 s: SCICLIENT: Sciclient_pmModuleClkRequest module=152 clk=1 state=2 flag=0
[MCU2_0]   2051.137323 s: SCICLIENT: Sciclient_pmModuleClkRequest success
[MCU2_0]   2051.137357 s: DSS: SoC init ... Done !!!
[MCU2_0]   2051.137384 s: DSS: Board init ... !!!
[MCU2_0]   2051.137404 s: DSS: Turning on DP_PWR pin for eDP adapters ... !!!
[MCU2_0]   2051.183378 s: DSS: Turning on DP_PWR pin for eDP adapters ... Done!!!
[MCU2_0]   2051.183443 s: DSS: Board init ... Done !!!

I also tried adding ti/k3-j721e-common-proc-board.dtb to the name_overlays of /run/media/BOOT-mmcblk1p1/uEnv.txt, but that did not help.

Please validate that I am uploading the right patched files and that there is no missing manipulation from your instructions.

Hi FredC LT,

ok, i thought hogging GPIO in the Linux/uboot dts file would help, but it seems it did not. Let me check on it. 

Regards,

Brijesh

Hi Brijesh, I will try tomorrow.

Thank you

Sure, i will move the status of this ticket to waiting.  Thanks

Hi Brijesh,

I'm really happy to confirm that this has fixed the issue. I'll go ahead and apply the patch to our build image. Two follow-up questions:

1. Should I apply the patch to the TDA4VE SDK as well?
2. Will this patch be in SDK 9.2?

Thanks a lot,

Fred

Is it really necessary to apply to TDA4VE? It's been working fine for us all along.

Hi FredC LT,

I think it is better to keep the same driver.

Regards,

Brijesh