Search code examples
embeddedembedded-linuxu-boot

In embedded programming, when using uboot which dts files should i modify?

I need more references besides the uboot documentation. Is there anything that i can read to futher my understanding?

I am confused on what dts files my build is using when using uboot. Do I modify all the relevant dts files, for both kernel/ and uboot/ directories.

Or do i set it in a specific file? Can i tell which dts I used once I am booted into linux?

for example I am using an imx8mq-evk board, but there are many dts files to choose from.

enter image description here

Solution

  • Well, there's many parts to your question. Lets start by looking at configs/imx8mq_evk_defconfig in U-Boot and in there we can see:

    CONFIG_DEFAULT_DEVICE_TREE="imx8mq-evk"

    So in this case, arch/arm/dts/imx8mq-evk.dts is the main dts and will #include all of the dtsi files it needs. With one exception. The file arch/arm/dts/imx8mq-evk-u-boot.dtsi will also automatically be included.

    What files should you modify for U-Boot? ONLY arch/arm/dts/imx8mq-evk-u-boot.dtsi is to be modified directly and all other files are a direct copy from the Linux kernel sources. As an aside, yes, there are counter examples, but they are not following best practices.

    What device tree will be passed to the kernel? Well, that depends a bit on you. Assuming you're using bootefi (and either an additional loader such as GRUB or systemd-boot, or just booting the Image file from the kernel build directly), if you don't pass in the address in memory of a device tree, the one U-Boot is using will be passed. Otherwise you would load a dtb file from some other source, typically to the address in memory that $fdt_addr_r points to, and then pass that as the second parameter to bootefi. If you are booting with booti instead, the device tree you have loaded in memory is the third argument passed, and again typically $fdt_addr_r.

    Now, you noted there's many dtb files, which is true, but there's no automatic logic for this platform to determine which peripherals are to be used, which is where all of the other variants come from, the additional IO you have configured on the EVK for your specific needs.