DSI Display Issue

Tachyon
1

Hello there! I am working on using this display as it is very cell phone like. It supposedly works with Raspberry Pi, however, I am not able to get it working on the Tachyon.

Display:

MF Sales page: 5inch DSI Capacitive Touch Display, 720 × 1280, IPS, Optical Bonding Toughened Glass Panel, DSI Interface, 5-Point Touch, Aluminum Alloy Case | 5-DSI-TOUCH-A

Amazon (faster) Sales page: Amazon.com

Wiki Page: https://www.waveshare.com/wiki/5-DSI-TOUCH-A

Now, I understand that currently, the only IC supported is the ILI9881D driver IC as per the docs.

The one I picked out, I believe, uses a Himax HX8394 display controller. The Himax HX8394 is a 16.7M colors TFT-LCD controller with a maximum 800RGBx1280 resolution. The benefit of this driver is that it doesn’t use an I2c bus for touch and fully uses the 4 lane MIPI DSI connector + power. and it is cheap!

Any help would be appreciated. Also, any tips on probing the DSI lanes with terminal commands would be helpful as well. The docs mention that it should just be outputting signal without any further configuration. On a Raspberry Pi, there are display overlays and other config settings to be made, how does this work on the Tachyon?

-Thanks,

Dave

2

It was noted in the docs as far as I recall, that the DSI/CSI port needs to be set to DSI mode. I think it defaults to CSI.

3

here is the section from the docs:

The DSI display is only supported on the DSI/CSI2 connector. By default, the connector will output the DSI signal, so no additional configuration changes are needed. The display should be probed and detected on boot. In the Desktop Variant, the display will show as a built in screen. In the Headless Variant, it will display a wayland desktop.

4

@psktruck Thanks for the clarification.

5

Not an expert, but also interested in this, here’s what I can tell, hopefully this might help with your own research:

  • DSI displays need specific drivers for the specific driver IC (it’s not a driverless protocol). Hence why the docs say that only ILI9881D is supported right now.
  • On Linux on ARM, the drivers for these types of peripherals are configured using ‘device trees’, because there is no automatic-detection or probing like you would expect from an x86 PC platform.
  • The Tachyon has dtbo_a and dtbo_b partitions, which is likely where these overlays need to be added. (Seems to be an A/B partition arrangement like for Android (for fail-safe upgrades), in fact judging by /proc/cmdline it looks like it is an Android bootloader!)
  • If you can find a .dtbo file for your display panel, perhaps intended for Raspberry Pi, this is a binary-compiled ‘device tree overlay’, which is kind of like a dynamic config file for part of the device tree, selectable at boot time. You can decompile it to a textual form with dtc -I dtb -O dts -o vc4-kms-dsi-waveshare-panel.dtb vc4-kms-dsi-waveshare-panel.dtbo
  • I expect it should be possible to decompile the dtbo from the Tachyon in the same way, but have not yet attempted this.
  • The hard part: we would then need to graft the display driver config onto the Tachyon’s device tree. From what I understand: the DSI driver section is contained within a configuration for a Broadcom-specific host-side driver (for the RPi at least) and we would need to adapt it to the equivalent Qualcomm host-side driver. I can’t really provide advice here because I haven’t done this yet.
  • It should then be possible to recompile the device tree to the binary form with dtc -I dts -O dtb -o new.dtbo new.dtb.
  • We would then need to figure out how to flash this onto the Tachyon, or whether there is another easy way of loading an overlay.

I will just remind that this is only what I’ve figured out from reading, I have not put most of this into practice yet, so there may be factual errors.

1 Like
6

That is great info. Unfortunately, it is about 5 levels above what I can tinker with haha. I am not sure how to compile or decompile much of anything. I was hoping a particle engineer would hop on with an easy answer. Looks like I am going to be learning some deep hacking skills today!

Thanks.

1 Like
7

So, doing some chatgpt agent research, they said the following would be necessary. Does it look correct to you?

To get a Himax HX8394‑based display working on a Tachyon board you’re essentially adding support for a new MIPI‑DSI panel to a Qualcomm‑based Linux system. Particle’s current builds only enable the ILI9881D panel, so nothing in the shipping OS knows how to drive your screen. Porting the HX8394 panel requires kernel work, device‑tree updates and careful flashing.

Here’s what would need to happen at a high level:

  1. Ensure there’s a driver in the kernel.

    • The Linux kernel has a panel-himax-hx8394.c driver in the DRM subsystem. You must build this driver against the version of the kernel Tachyon uses (which is based on a Qualcomm Snapdragon SoC). In the kernel configuration this driver is selected via CONFIG_DRM_PANEL_HIMAX_HX8394. If Particle’s pre‑built kernel doesn’t include it, you’ll need to clone the kernel source used for Tachyon, enable this option and cross‑compile the kernel and modules.

  2. Create a device‑tree overlay for the panel.

    • Each DSI panel needs a matching node in the device tree, specifying properties such as reset and backlight GPIOs, number of data lanes, pixel format and the panel’s dimensions. The HX8394 binding requires reset-gpios, bl-gpios, data‑lanes, pixel‑format, width and height.

    • You can start from an existing HX8394 overlay for another board (for example, one used on a Raspberry Pi or i.MX board). Decompile that overlay with dtc -I dtb -O dts -o hx8394.dts existing_overlay.dtbo to get a human‑readable .dts file. Then edit it so the DSI host phandle, GPIO numbers and regulators match the Tachyon’s hardware.

    • Use dtc -@ -I dts -O dtb -o hx8394.dtbo hx8394.dts to compile the overlay back to a binary dtbo.

  3. Flash the overlay to the Tachyon.

    • Tachyon’s bootloader uses A/B partitions and separate dtbo_a/dtbo_b images. You’ll need to flash your hx8394.dtbo into the appropriate slot (e.g. via fastboot flash dtbo_a hx8394.dtbo). The exact procedure depends on Particle’s tooling; you may need to unlock the bootloader.

  4. Load the new kernel and verify.

    • Boot the board with the kernel that includes the HX8394 driver and the device‑tree overlay. Use dmesg | grep hx8394 and check /sys/class/drm/ to see if the panel is bound. If the driver isn’t probed, check that the compatible string in the overlay matches the kernel driver ("himax,hx8394"), and that the regulators and clocks used by the panel are defined.

  5. Troubleshoot and adjust.

    • Porting a DSI panel often involves tuning panel timings or initialization sequences. You may need to edit the driver’s parameters (or add a new panel descriptor) to match your specific HX8394 variant.

    • Ensure your overlay sets the panel’s status to "okay" and ties the backlight GPIO to a PWM or regulator so the panel illuminates.

Because the Tachyon OS currently only supports ILI9881D panels, Particle doesn’t provide tooling for these steps. Porting a DSI panel is an advanced task that involves kernel compilation and bootloader modifications. If you’re not comfortable building and flashing Android‑style A/B images, the safer option is to use a supported ILI9881D‑based display or wait for Particle to add HX8394 support.

8

HI Dave,

I don’t know if you’re still looking for this information, but as I’ve landed on your question multiple times while researching this subject, so let me leave some breadcrumbs.

The Waveshare displays consists of some DSI panel, a Goodix touch controller and some form of MCU which is used to control power, enable, and reset signals to these components. As you can see on the Waveshare page, the package is fed 3.3V and 5V, the flex cable provides DSI signals for the video signal as well as the I2C signals used to communicate with the MCU and the touch controller.

Wiring up the Tachyon to the panel is done exactly like in the pictures provided on the web page.

On the software side, two “work-in-progress” patches that recently showed up on LKML are needed:

The first one provides the interface to the MCU, exposing controls of those on-board signals. The latter defines the sequences and properties for a variety of Waveshare displays.

With these patches applied to a modern (v6.18+) Linux kernel, we just need to describe how the pieces are connected, in the board’s DeviceTree.

The 5V supply in the debug connector needs to be explicitly enabled. Then we need to enable &i2c13 with the MCU and the touch controller:

&i2c13 {
        clock-frequency = <400000>;

        status = "okay";

        display_mcu: regulator@45 {
                compatible = "waveshare,touchscreen-panel-regulator";
                reg = <0x45>;
                gpio-controller;
                #gpio-cells = <2>;
                enable-gpio = <&display_mcu 2 GPIO_ACTIVE_HIGH>;
        };

        touch-screen@5d {
                compatible = "goodix,gt9271";
                reg = <0x5d>;
                reset-gpio = <&display_mcu 9 0>;
                touchscreen-size-x = <1920>;
                touchscreen-size-y = <720>;
                touchscreen-x-mm = <292>;
                touchscreen-y-mm = <110>;
        };
};

Which allows us to describe the DSI controller and the actual panel:

&mdss_dsi {
        vdda-supply = <&vreg_l6b_1p2>;
        status = "okay";

        panel@1 {
                compatible = "waveshare,12.3-dsi-touch-a,4lane";
                reg = <1>;

                reset-gpio = <&display_mcu 1 0>;
                iovcc-gpio = <&display_mcu 4 0>;
                avdd-gpio = <&display_mcu 0 0>;
                backlight = <&display_mcu>;

                rotation = <270>;

                port {
                        panel_in: endpoint {
                                remote-endpoint = <&mdss_dsi0_out>;
                        };
                };
        };
};

&mdss_dsi0_out {
        data-lanes = <0 1 2 3>;
        remote-endpoint = <&panel_in>;
};

&mdss_dsi_phy {
        vdds-supply = <&vreg_l10c_0p88>;
        status = "okay";
};

There are no “terminal commands” or similar, once wired up it just becomes the default display. Both the Linux console and Wayland will use it without any additional tinkering.

Regards,
Bjorn