Skip to main content

Modifying the Device Tree for Tachyon

The Device Tree is essentially a hardware description file that informs the Linux kernel (and bootloader) about the hardware components, their addresses, and how they are connected. For Tachyon, many of the currently non-working features can be enabled or fixed by updating the Device Tree Source (DTS) to match the actual hardware wiring. If you want to enable a peripheral or adjust a hardware parameter, editing the DTS is often required.

Where is the Device Tree?​

On Tachyon’s Ubuntu 24.04 build, the primary Device Tree is provided by U-Boot (which loads a compiled DTB during boot). The file is:

  • dts/upstream/src/arm64/qcom/qcm6490-tachyon.dts

Editing the Device Tree Source​

  1. Open the DTS file: Use a text editor to open the Tachyon board DTS. You’ll see a hierarchical structure of nodes representing devices. For instance:

    • Clocks, regulators, pinctrl settings.
    • Serial ports (serial@ nodes).
    • I2C buses with attached devices (like perhaps a fuel gauge or the SYSCON microcontroller interface).
    • GPIO controllers (e.g., the SoC’s TLMM for onboard pins, or an I/O expander chip if one exists).
    • USB, PCIe, etc., with their status (often status = "okay" to enable, or "disabled" to disable).
    • Display and camera connectors (might be present but disabled).
    • LEDs (an LED might be defined as a GPIO-controlled device).

  2. Make the desired changes: Some common modifications:

    • Enable a device: Many nodes might be present but marked status = "disabled";. To enable, change it to "okay". For example, if there is a gpio node or i2c1 bus that’s disabled, enabling it might allow the kernel to load a driver.
    • Add a new node: If a piece of hardware is missing in the DTS, you can add it. For instance, if Tachyon has a specific IMU sensor not listed, add an I2C device node under the appropriate bus with its compatible string and interrupt line.
    • Adjust properties: Update addresses, GPIO assignments, etc., if they are incorrect. For example, if the activity LED is connected to GPIO X but the DTS currently points to a wrong GPIO, fix the number and the controller.
    • Pin configuration: You might need to configure pin multiplexing for certain features (like turning on UART or SPI on certain pins). This is usually done with pinmux settings in the DTS. Tachyon’s DTS may include a pin control section; ensure the pins for the feature you want are properly configured and that the corresponding device node references that pin config.

  3. Example – Enabling GPIO/I2C expander: Suppose Tachyon uses a PCA9536 I/O expander for extra GPIO pins on the header (just hypothetical). If it’s connected to I²C, the DTS might need a node like:

    i2c2: i2c@78b6000 {  // Some I2C controller node
        status = "okay";
        io_expander: gpioexp@20 {
            compatible = "nxp,pca9536";
            reg = <0x20>;
            gpio-controller;
            #gpio-cells = <2>;
        };
    };

And perhaps also ensure pinctrl for that I2C bus is enabled. This would expose those expander GPIOs to Linux.

  1. Example – Fixing the LED: If the LED is on a certain GPIO, ensure there’s an leds section:
leds {
    compatible = "gpio-leds";
    status_led: tachyon-status {
        label = "tachyon:status";
        gpios = <&tlmm 42 GPIO_ACTIVE_HIGH>;  // &tlmm controller, line 42, active high (example)
        default-state = "off";
    };
};

And make sure GPIO 42 (example) is not used elsewhere and that it corresponds to the actual wiring.

  1. Documenting your changes: It’s helpful to document in comments or commit messages what you changed and why (e.g., “Enable SPI1 bus for external sensor on header pin X” or “Fix LED GPIO index”).

Compiling the Device Tree​

If you have the U-Boot build environment set up (from the previous “Modify U-Boot” page), simply re-run the U-Boot build after saving DTS changes:

make qcm6490_defconfig  # if not already configured
make -j$(nproc)

It will compile the DTS into a DTB as part of U-Boot. The U-Boot binary will then contain the updated DTB.

Alternatively, you can compile the device tree in isolation using the Device Tree Compiler:

apt install device-tree-compiler  # if not installed
dtc -I dts -O dtb -o qcm6490-tachyon.dtb qcm6490-tachyon.dts

Replace with actual filenames. This produces a .dtb you could potentially test by overlaying in Linux (not persistent across boot) or by instructing U-Boot to load it.

However, typically, you’ll want to integrate it into U-Boot and flash the updated U-Boot, as described before.

Testing Device Tree Changes​

After installing your new U-Boot (with updated DT):

  • Boot into Ubuntu 24.04 on Tachyon.
  • Check the effects of your changes:
  • For new devices: see if they appear. For example, if you enabled an I2C device driver, does dmesg show it probed? Does ls /dev show a new device (like /dev/i2c-... or a new gpiochip for an expander)?
  • For GPIO/LED: does /sys/class/leds/ now contain “tachyon:status”? Can you control it by writing to the brightness file?
  • For interfaces like SPI/UART: can you open the device or see it with ls -l /dev (e.g., /dev/spidev* or /dev/ttyXYZ).
  • If enabling display or camera, you might see different behavior (though those often require driver code too).
  • If something crashes or doesn’t behave right, you might need to revise the DTS. Check dmesg for errors. The kernel will often log warnings if a device tree node is malformed or a driver can’t bind (for example, “Failed to probe…”).

Device Tree and Kernel Modules​

Remember, enabling a device in DTS is one side of the coin; the other is having a driver in the kernel for that device. For example, adding a node for a device that has no driver built will do nothing visible. Make sure the kernel has the corresponding driver built (either as a module or built-in). If not, use the Kernel modification steps to enable that driver.

Submitting Device Tree Changes​

If you have gotten a new part of Tachyon’s hardware working by updating the DTS, that’s great news for everyone:

  • Ensure your DTS changes are clean (no unrelated whitespace or debug changes).
  • Push the changes to your fork of tachyon-u-boot (or kernel, if relevant).
  • Open a Pull Request explaining what the change does (e.g., “Enable GPIO expander and user LED on Tachyon”).
  • We will review the DTS change. Sometimes, we might request confirmation of certain hardware details or testing results.
  • Once merged, these improvements will be in the next builds for all users.

Device Tree contributions are among the most impactful, because they often unlock hardware functionality without requiring deep kernel hacking.