we are using AM62 in custom board with DSI display. Recently we noticed display is not working with some new modules and it seems the reason is 1.1C module compared to 1.1A. From dmesg it looks the DSI bridge fails software reset (tc358768_sw_reset) in pre_enable function which disables the bridge.
This reset is two I2C writes to the bridge’s register so possibly there is issue with I2C or maybe the bridge is not yet communicating or something.
Are there differences in module revisions relating to this bridge that could cause it? There is errata HAR-10648, though I can’t say how relevant it is. At least hopefully there won’t be needed any changes to the carrier board? (we would like to start production).
We’re using BSP 6.5 with kernel 6.1 (userspace is Debian based from TI) - there’s option to try newest toradex kernel 6.6.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello!
If you’re encountering issues with a DSI display on the Verdin AM62, here are some steps you can take to troubleshoot and resolve the problem:
Device Tree Configuration: Ensure that the DSI node is enabled in your device tree configuration. This is crucial for the display to function correctly. You can do this by setting the status to “okay” in the device tree:
Kernel Configuration: Verify that you are using the correct Linux kernel version. The Verdin AM62 supports Linux kernel version 6.6.53 with the toradex_defconfig. This ensures compatibility with your hardware. Learn more about building the Linux kernel.
MIPI DSI Interface: Check the configuration of the MIPI DSI interface, which includes differential pairs for clock and data signals, as well as I2C control signals. Proper configuration is essential for the display to operate correctly. Reference for signal routing and termination.
Troubleshooting the tc358768 Bridge:
Ensure there are no conflicting display overlays enabled in /boot/overlays.txt.
Enable debug prints in your display driver to trace initialization steps. This can help identify where the process might be failing.
Use ftrace for detailed diagnostics of driver loading behavior, which can provide insights into any issues during the driver initialization. Further troubleshooting tips.
If the issues persist after these steps, double-check that your DSI configuration aligns with the reference design specifications for signal routing and termination.
I hope this helps resolve your display issues. If you have any more questions, feel free to ask!
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
HAR-10648 should not affect different versions of software differently.
If the DSI bridge works with one version of software, your SoM is likely not affected.
BSP 6.5.0 is quite early for the Verdin AM62.
The problems with V1.1C are likely related to the older BSP.
I strongly recommend that you update to BSP 6.8.1 or BSP 7.1.0.
In BSP 7 we moved to the Linux Kernel 6.6.
If you still run into issues then, please let me know.
If yes, could you test these modules with the Reference Multimedia Image to see if you can get a video output out of the HDMI port?
Please note that if you are using the Yavia Board, HDMI2 should be used.
The HDMI output is converted from DSI, so if there is a problem with the DSI output it will also not work.
I’ve tried Dahlia with Toradex DSI to HDMI adapter with Reference Multimedia image. I’m getting the same error, software reset of DSI bridge fails. Additionally there is i2c timeout in dmesg:
omap_i2c 20020000.i2c: controller timed out
Noted, there may be a problem with your module then.
Do you see any output via the DSI to HDMI adapter when loading the Toradex Easy Installer?
Can you confirm the version of the Dahlia Carrier Board used to test?
If there is no output via the DSI to HDMI adapter and the Dahlia Carrier Board is at least V1.1, please submit an RMA for the modules in the following page: Return Material Authorization (RMA)
I’ve managed to try another 1.1C module and it works without issue. It seems those two are just damaged. I assumed something systemic since there were two of them. I missed there were already several C modules in our company working fine. Sorry for the confusion and thanks for the time.
I checked our test logs for your modules and this was not present there, the i2c controller initialized without issues.
This I2C is exposed externally, so it is possible that something outside the board caused the problem.
Please double-check if the I2C for the DSI interface on your display and custom board are 1.8V interfaces, as the Verdin I2C signals are 1.8V and not 3.3V-tolerant.
That is understood.
The problem could be due to damage if the I2C signals on these modules were supplied with 3.3V at some other point in the past.
It could also have other causes, but with two modules with the same problem it is worth double-checking.
