I'm working with TS-4900, an embedded 'Computer on Module' plugged into a baseboard, running Yocto Linux. It uses U-Boot to start, and supposedly basing on the model of the baseboard it chooses the right dtb file to start, and possibly if it fails to locate the right one it falls back to a 'generic' one for my module.

But how/where does it determine the right one? How can I tell which .dtb was used, or set which one should be used?

Below are the boot messages of U-Boot.

U-Boot 2014.10-g3ac6ec3 (Jan 29 2015 - 17:20:15)

CPU:   Freescale i.MX6SOLO rev1.1 at 792 MHz
Reset cause: POR
Board: TS-4900
Revision: C
       Watchdog enabled
I2C:   ready
DRAM:  1 GiB
SF: Detected N25Q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   using phy at 7
Press Ctrl+C to abort autoboot in 1 second(s)
(Re)start USB...
USB0:   Port not available.
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
No storage devices, perhaps not 'usb start'ed..?
Booting from the eMMC ...
** File not found /boot/boot.ub **
** File not found /boot/imx6dl-ts4900-13.dtb **
Booting default device tree
42507 bytes read in 196 ms (210.9 KiB/s)
118642 bytes read in 172 ms (672.9 KiB/s)
ICE40 FPGA reloaded successfully
4609784 bytes read in 337 ms (13 MiB/s)
## Booting kernel from Legacy Image at 12000000 ...
   Image Name:   Linux-3.10.17-1.0.0-technologic+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4609720 Bytes = 4.4 MiB
   Load Address: 10008000
   Entry Point:  10008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 18000000
   Booting using the fdt blob at 0x18000000
EHCI failed to shut down host controller.
   Loading Kernel Image ... OK
   Using Device Tree in place at 18000000, end 1800d60a

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0

(Kernel startup commences...)

I'm way late on this, but I implemented this script and I'll address this for anyone who finds this using an internet search engine.

This computer on module can be put on almost any off the shelf TS or custom baseboard, and we wanted it to automatically work without users having to adjust the device tree used. We have an 8-input shift register on any given carrier board with a unique id for the baseboard. On the TS-8550, this is 0x13. http://wiki.embeddedarm.com/wiki/TS-4900#Baseboard_ID

So in U-Boot the bbdetect command we added reads the GPIO connected to this shift register and sets a $baseboardid environment variable. U-Boot will first attempt to load a baseboard specific device tree at /boot/imx6${cpu}-ts4900-${baseboardid}.dtb. If it fails to find one, it will use the fallback device tree at /boot/imx6${cpu}-ts4900.dtb. This latter file has sane defaults that will work on any carrier board. The TS-8550 doesn't need a baseboard specific carrier board so it falls back to the standard device tree and continues to boot.

To answer your original question,

cat /proc/device-tree/model

All of our device trees will have a slightly different model in the device tree.
For example, the safe fallback is:

  • "Technologic Systems i.MX6 Quad TS-4900 (Default Device Tree)"

Or the TS-TPC-8390 carrier board with a specific device tree:

  • "Technologic Systems i.MX6 Quad TS-4900 (TS-TPC-8390)"

When U-Boot executes the boot command, it provides a memory address for the kernel and a memory address for the device tree blob. Therefore, prior to this command, it must load these files into memory. Based on the messages you provided we see that two files failed to be loaded from the eMMC/SD card:


Its possible that either these files simply weren't present, their path is wrong or the incorrect device:partition was given to the U-Boot load command. In any case, the command fails. At this point, it appears that the bootloader tries to load a "default" device tree - possibly stored on the same medium as the bootloader itself.

To find out exactly what is happening, you'll want to halt the boot process at the bootloader and access the U-Boot command prompt. From here, you may enter:


This will print out the U-boot environment variables. Many of these variables reference other variables. Some of these variables are often executed like scripts, so you may see boot scripts, kernel & fdt load scripts, etc. To figure out the boot sequence, look for a variable called bootcmd (or something similar). This is usually what is ultimately run at boot time. You'll need to trace the boot sequence out from this point through multiple variables, but you should see where load commands are used to load the FDT into memory. If you'd like to post the output of printenv, we can identify the exact logic used here.

  • 1
    Thanks. bootcmd being the one env variable that contains the initial startup script was what I needed. – SF. Mar 29 '15 at 7:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.