Hello,
I am integrating a Riverdi RVT70HSDFWCA0 V1.0A display with:
After correcting the base device tree to:
imx8mm-verdin-wifi-mallow.dtb
the display stack initializes correctly and DRM creates:
-
LVDS-1 connected
-
LVDS-1 enabled
-
fb0 framebuffer
The display however remains black.
The following errors are reported:
sn65dsi83 1-002c: failed to lock PLL, ret=-6
ilitek_ts 1-0041: protocol init failed: -6
The hardware appears to be detected correctly:
We are currently using the Riverdi overlay:
verdin-imx8mm_panel-cap-touch-7inch-dsi_overlay.dtbo
based on RVT70HSLNWCA0.
Could you advise whether:
-
There is a known compatibility issue between RVT70HSDFWCA0 and the published overlay.
-
The SN65DSI83 PLL lock failure is typically caused by incorrect display timings or missing regulator definitions.
-
Additional debug steps are recommended on Verdin iMX8M Mini.
Thank you for your help.
Best regards,
Daniele Gazzola
CellDynamics
Hi, I’m the Toradex AI Assistant.
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
I can help you troubleshoot the SN65DSI83 PLL lock failure with your Riverdi display. To provide the most accurate guidance, could you first confirm which exact version of Torizon OS you’re running on your Verdin iMX8M Mini?
You can get this information by running the tdx-info command on your device. For more details about this command, see: Getting Device Information with Tdx-Info | Toradex Developer Center
Initial Analysis
Based on your description, there are several potential issues with the display configuration. The Riverdi RVT70HSDFWCA0 V1.0A may have different timing requirements than the RVT70HSLNWCA0 that the current overlay is based on (1).
Common Causes of SN65DSI83 PLL Lock Failure
The SN65DSI83 PLL lock failure typically indicates timing or configuration mismatches. According to the device tree overlay documentation, you may need to create a custom overlay with the correct specifications for your specific display (2).
Recommended Troubleshooting Steps
-
Verify Display Specifications: Compare the timing parameters between RVT70HSDFWCA0 and RVT70HSLNWCA0 in the Riverdi documentation
-
Check Device Tree Configuration: The overlay may need modifications for your specific display variant. You can create a custom device tree overlay following the guidance in our documentation (2)
-
Validate I2C Communication: Since both the SN65DSI83 and Ilitek controller show communication errors, verify the I2C bus configuration in your device tree
Once you provide the exact Torizon OS version, I can give you more specific guidance on creating a custom overlay for the RVT70HSDFWCA0 and debugging the PLL lock issue.
Best regards, Toradex AI Assistant.
Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Hi,
Here is the requested system information.
Software summary:
Hardware:
The display connected is:
RVT70HSDFWCA0 V1.0A
Initially the system was incorrectly using the Verdin Development Board DTB, but this has now been corrected.
Current configuration:
fdtfile=imx8mm-verdin-wifi-mallow.dtb
Loaded overlays:
fdt_overlays=verdin-imx8mm_panel-cap-touch-7inch-dsi_overlay.dtbo verdin-imx8mm_spidev_overlay.dtbo
The 7-inch overlay was built from the Riverdi DTS repository and is based on:
display-rvt70hslnwca0_overlay.dtsi
Observed behavior:
-
SN65DSI83 detected at I2C address 0x2c
-
Ilitek ILI2132 detected at I2C address 0x41
-
DRM creates card1-LVDS-1
-
card1-LVDS-1 reports “connected”
-
card1-LVDS-1 reports “enabled”
-
framebuffer is created
-
backlight is present and brightness can be controlled
-
display remains completely black
Kernel messages:
sn65dsi83 1-002c: supply vcc not found, using dummy regulator
sn65dsi83 1-002c: failed to lock PLL, ret=-6
ilitek_ts 1-0041: protocol init failed: -6
Additional diagnostics:
-
I2C device 0x2c is bound to the sn65dsi83 driver
-
I2C device 0x41 is detected but ilitek_ts fails protocol initialization
-
GPIO enable line for the display bridge is asserted high
Could you please confirm whether RVT70HSDFWCA0 V1.0A requires a different overlay or timing configuration than RVT70HSLNWCA0?
Any guidance regarding the SN65DSI83 PLL lock failure would be greatly appreciated.
Best regards,
Daniele Gazzola
CellDynamics
Thank you for the detailed system information. Based on your setup with TDX Wayland 6.8.8 on Verdin iMX8M Mini with Mallow carrier board, I can help you troubleshoot the SN65DSI83 PLL lock failure.
Root Cause Analysis
The SN65DSI83 PLL lock failure (ret=-6) indicates a timing configuration mismatch between your RVT70HSDFWCA0 V1.0A display and the overlay based on RVT70HSLNWCA0 (1). The “supply vcc not found, using dummy regulator” warning suggests the device tree may also be missing proper power supply definitions.
Display Variant Differences
The RVT70HSDFWCA0 V1.0A likely has different timing parameters than the RVT70HSLNWCA0 that your current overlay is based on. You’ll need to create a custom device tree overlay with the correct specifications for your specific display variant (1).
Creating a Custom Overlay
Following the device tree overlay writing process, you need to (1):
- Define the target hardware - Your overlay should specify compatibility with “toradex,verdin-imx8mm”
- Create proper pin groups - Configure the DSI and I2C pins correctly for the Mallow carrier board
- Enable the display controller - Assign the pin groups to the appropriate device nodes
- Resolve conflicts - Ensure no other peripherals conflict with your display configuration
Recommended Steps
-
Obtain RVT70HSDFWCA0 V1.0A specifications from Riverdi documentation, particularly:
- Horizontal and vertical timing parameters
- Clock frequencies
- Power supply requirements
-
Create a custom overlay based on the timing differences. The overlay structure should follow this pattern from the documentation (1):
&main_pmx0 {
pinctrl_display_gpio: display_gpio_grp {
pinctrl-single,pins = <
/* Configure display-specific GPIO pins */
>;
};
};
-
Add proper regulator definitions to resolve the “supply vcc not found” warning
-
Build and deploy the overlay using TorizonCore Builder following the steps outlined in the device tree overlay documentation (2)
Testing the Custom Overlay
After deploying your custom overlay, verify that (2):
- The overlay is successfully applied by checking
/proc/device-tree/chosen/overlays
- The SN65DSI83 PLL locks without errors
- The Ilitek touch controller initializes properly
The key is ensuring your custom overlay matches the exact timing requirements of the RVT70HSDFWCA0 V1.0A variant rather than using the RVT70HSLNWCA0 configuration.
Best regards, Toradex AI Assistant.
Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Thank you.
I understand. We will contact Riverdi to confirm the exact overlay/timing configuration for RVT70HSDFWCA0 V1.0A.
For reference, we already have the datasheet for RVT70HSDFWCA0. It specifies:
The timing table in the datasheet reports:
-
DCLK frequency: min 40.8 MHz, typ 51.2 MHz, max 67.2 MHz
-
Horizontal display area: 1024
-
HSYNC period: min 1114, typ 1344, max 1400
-
Horizontal blanking: min 90, typ 320, max 376
-
Vertical display area: 600
-
VSYNC period: min 610, typ 635, max 800
-
Vertical blanking: min 10, typ 85, max 200
The Riverdi overlay we used for RVT70HSLNWCA0 seems to already use similar values, but the SN65DSI83 still fails to lock PLL.
Do you recommend modifying only the panel timing section, or should we also define a proper vcc regulator for sn65dsi83 in the overlay?
Best regards,
Daniele
sn65dsi83 1-002c: failed to lock PLL, ret=-6
ilitek_ts 1-0041: protocol init failed: -6
In Linux, error -6 is -ENXIO, meaning “No such device or address.” That is different from a normal PLL lock timeout, which would typically be reported as a timeout error. In the SN65DSI83 driver, the PLL message is printed after the driver polls the bridge register over I2C, so ret=-6 strongly suggests that the bridge stopped responding on I2C during initialization rather than simply failing to lock because of an incorrect timing.
Because the touch controller also reports -6 on the same I2C bus, I would first suspect a common hardware I2C related issue affecting the display module, such as:
- Missing or unstable 5 V module power
- Missing VREF
- Incorrect FFC orientation or connector contact
- I2C signal-level or pull-up issue
Please try using i2c-tools , with the related display overlay disabled, to check whether the SN65DSI83 bridge and Ilitek touch controller acknowledge their expected I2C addresses.
Before testing, please make sure that the display module is powered, VREF is present, and the required reset or PWR_DN signals are in the correct state.
To avoid scanning the entire I2C bus, you can probe only the expected addresses:
i2cdetect -y <bus> 0x2c 0x2c
i2cdetect -y <bus> 0x41 0x41
Please provide details on exactly how your display is connected to the Mallow carrier board, including the relevant schematic snippets.