Hello Toradex Team,
I have successfully built a Yocto image for the Verdin AM62 and tested it using the Mallow Carrier Board. Now, I’m moving toward a custom carrier board that is based on Mallow but with several unused peripherals removed, such as:
- CAN interface
- DSI display
- CTRL (debug) headers
- Possibly others not needed in our design
I would like to know the recommended approach to remove these interfaces from the device tree to match our minimal custom hardware.
- Should I create a new
.dts file based on verdin-am62-mallow.dts and remove the unwanted peripherals?
- Or is it better to create a
.dtsi overlay and disable nodes using status = "disabled";?
- Are there specific files under
arch/arm64/boot/dts/ti/ that I should duplicate and modify?
Any guidance on the best practices for this kind of DT customization for Verdin AM62 would be appreciated.
Thanks in advance,
Uday
Hi, I’m the Toradex AI Assistant.
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer? 
Hello Uday,
Thank you for your detailed question! For customizing device trees on the Verdin AM62, especially when moving to a custom carrier board with unused peripherals, here are the best practices:
1. Use Device Tree Overlays (Recommended Approach)
- The preferred and maintainable way to disable unused peripherals (like CAN, DSI, debug headers, etc.) is to create a Device Tree Overlay that sets the unwanted nodes to
status = "disabled";.
- This method avoids modifying the main board
.dts files, ensuring your changes are modular and easier to maintain—especially when updating to new BSP versions.
(Read more on overlays and their benefits)
Sample Overlay Structure:
/dts-v1/;
/plugin/;
/ {
fragment@0 {
target-path = "/";
__overlay__ {
&can_node {
status = "disabled";
};
&dsi_node {
status = "disabled";
};
/* Repeat for other interfaces */
};
};
};
Replace &can_node, &dsi_node, etc., with the actual node names you need to disable.
2. Avoid Duplicating Complete .dts or .dtsi Files
- It is not required (nor recommended) to create a new
.dts based solely on verdin-am62-mallow.dts and remove peripherals there.
- Directly duplicating or editing upstream device trees can make future maintenance and upgrades more difficult.
- Instead, your custom overlay should be added to the build (either with Yocto or via Torizon).
3. Maintainability
- Device Tree Overlays make it easy to enable/disable features as your hardware evolves.
- Pre-built overlays also exist for many peripherals for quick reference (see overlays and examples).
4. Special Considerations
- Some interface disablement may have power/control dependencies—ensure related nodes and supplies are handled to avoid issues.
- Overlays work well for both Yocto and Torizon-based builds; you can apply your overlay at boot or via the build system.
Summary:
- Create a Device Tree Overlay that disables (via
status = "disabled") any peripheral not needed.
- Do not duplicate and directly modify the main device tree files—use overlays for modularity and easier maintenance.
- Always check related dependencies when disabling nodes, especially for display and power-critical peripherals.
Useful Resources:
Let me know if you’d like an example overlay for a specific interface, or if you need guidance on integrating overlays with Yocto or Torizon.
Best regards,
Toradex AI Assistant.
Hey, @Uday10122,
Choosing between device trees and device tree overlays depends highly on the way you designed your custom board. You said your carrier board is based on the Mallow, have you followed our Reference Design?
If you did follow our reference design and simply removed peripherals, it may be a good approach to use the verdin-am62-mallow.dts device tree and add a custom overlay disabling the unused interfaces.
If your board differs in some significant way from our reference design, the recommended approach is to write your own device tree. If you have questions about writing the .dts file, check out our Overview on Device Trees. One thing to note is that if you build your own device tree, you should be aware of the hierarchical structure of the .dts files. Since you are using a Verdin AM62 SoM, your custom device tree should include at least the k3-am625.dtsi and k3-am62-verdin.dtsi. You can check the hierarchical structure of our device tree files here.
Lastly, I just wanted to point out a possible point of confusion. You asked about creating a .dtsi overlay, but .dtsi files are not device tree overlays. They are include files that will be simply added to the .dts files at compile time to create a .dtb binary. Device tree overlay files are .dtb files that are compiled separately into .dtbo files and applied at runtime to your system.
Let me know if you have any further questions.
Best regards,
Hi @leonardo.costa.tx
This helps me to disable those unused peripherals lets say i am not using SD card i have to use those pins as GPIO’s
how can i add that in my overlay any template code for that
here is images for reference
file : k3-am62-verdin.dtsi
&main_pmx0 {
/* Verdin PWM_1 */
pinctrl_epwm0_a: main-epwm0a-default-pins {
pinctrl-single,pins = <
AM62X_IOPAD(0x01b4, PIN_OUTPUT, 2) /* (A13) SPI0_CS0.EHRPWM0_A */ /* SODIMM 15 */
>;
};
/* Verdin SD_1 */
pinctrl_sdhci1: main-mmc1-default-pins {
pinctrl-single,pins = <
AM62X_IOPAD(0x23c, PIN_INPUT, 0) /* (A21) MMC1_CMD */ /* SODIMM 74 */
AM62X_IOPAD(0x234, PIN_INPUT, 0) /* (B22) MMC1_CLK */ /* SODIMM 78 */
AM62X_IOPAD(0x230, PIN_INPUT, 0) /* (A22) MMC1_DAT0 */ /* SODIMM 80 */
AM62X_IOPAD(0x22c, PIN_INPUT, 0) /* (B21) MMC1_DAT1 */ /* SODIMM 82 */
AM62X_IOPAD(0x228, PIN_INPUT, 0) /* (C21) MMC1_DAT2 */ /* SODIMM 70 */
AM62X_IOPAD(0x224, PIN_INPUT, 0) /* (D22) MMC1_DAT3 */ /* SODIMM 72 */
>;
};
};
comes under main_pmx0
help me with template code and also i have to access those pins to user space so how can i do that
Best regards
Uday
