Yocto Custom DT on Aquila AM69

Technical Support
1

I am having trouble applying a custom DT to my image. The DT is getting included in the image bootfs, but the dev board DT is still being loaded. I have followed the instructions for customizing an image with a custom device tree, but I am still having trouble. I am building my image using Yocto.

2

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 your custom device tree issue on the Aquila AM69. Based on the Toradex documentation, there are specific steps for both adding the device tree to the kernel build and configuring U-Boot to load it.

Kernel Configuration

First, ensure your custom device tree is properly added to the kernel build. You need to add your device tree file to the KERNEL_DEVICETREE variable in a machine-specific configuration file (1):

KERNEL_DEVICETREE:append = " ti/my-custom-devicetree-file.dtb"

(1)

For the Aquila AM69, create a machine configuration file like aquila-am69-extra.conf and include it in your layer’s conf/layer.conf file (1):

include conf/machine/aquila-am69-extra.conf

(1)

U-Boot Configuration

The critical step that’s often missed is configuring U-Boot to actually load your custom device tree. You need to create a U-Boot bbappend file (1).

For TI-based SoMs like the Aquila AM69, create recipes-bsp/u-boot/u-boot-toradex-ti%.bbappend (1):

do_configure:append() {
    # Remove existing fdtfile, if there is one
    sed -i '/"fdtfile=.*\\0" \\/d' ${S}/include/configs/j784s4_evm.h
    # Add new fdtfile
    sed -i 's/\("fdt_board=.*\\0" \\\)/\0\n "fdtfile=my-custom-devicetree-file.dtb\\0" \\/' ${S}/include/configs/j784s4_evm.h
}

(1)

Verification Steps

To verify your custom device tree is being loaded:

  1. Check the built image: Verify your .dtb file exists in the boot partition
  2. U-Boot environment: In U-Boot console, check the fdt_file environment variable matches your custom device tree name (2)
  3. Boot logs: Check if your custom device tree modifications are taking effect during boot

Common Issues

  • File naming: Ensure your device tree file name matches exactly between the kernel build and U-Boot configuration
  • Path structure: For TI-based modules, device trees typically go in the ti/ subdirectory
  • Build order: Make sure both kernel and U-Boot changes are included in your build

If you’re still having issues, could you share:

  • Your exact device tree file name
  • The contents of your machine configuration file
  • Your U-Boot bbappend configuration

This will help identify where the configuration might not be matching up.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

image
image1081×131 14.9 KB

image
image1059×340 15.8 KB

4

Hi Alex,

Thanks for the reply. I was able to load my DT this morning by changing fdtfile in the u-boot shell. However, I’m new to u-boot and would like to better understand how to do this in a more production-ready manner.

I did some more digging and found that the fdt_board variable is getting set here. This in turn is used to setup the u-boot preconfig variable here.

My custom DT file already follows the convention of k3-am69-aquila-<my version>.dtb, so it looks like all I need to do is add a patch to change fdt_board=dev to fdt_board=<my version>. Is this correct, or is there a better way to do this?

5

U-Boot on Toradex modules dynamically builds the fdtfile variable using two pieces of information:

  • $soc : The System on Chip (SoC) family (e.g., k3-am69 ). This is typically set automatically by U-Boot.
  • $fdt_board : A board variant identifier (e.g., dev , your-version ).

The final device tree filename is constructed as soc-fdt_board.dtb . While you can directly modify fdtfile , changing fdt_board(and leaving fdtfile unset) is the cleaner approach as it follows U-Boot’s intended logic.

6

Hi @tjohnson

Any further questions on this topic or can we close this “ticket”?

Did you find a way forward here?

Best regards,

7

@Haniel.tx Yes, we can close this ticket. Thanks!