Display Guide

Here you find documented everything supported displays and how to add support for displays to our CoMs software.

Supported Displays

The following table gives an overview of displays that can be connected to the various baseboards.

Display / Bridge

Connected via

Compatible Baseboards


Raspberry Pi Display

DSI Connector

  • QSBase 2

  • QSBase 3

Raspberry Pi Touch Display


(default for 10” panel)

DSI Connector

  • MIPI-MB (integrated)

  • TX8M-1620 (integrated on CoM)

  • QSBase 2

  • QSBase 3

MIPI-to-LVDS bridge

Texas Instruments SN65DSI83


DSI Connector

  • QSBase 2

  • QSBase 3

MIPI-to-RGB bridge

Glyn Displays via MIPI

Toshiba TC358867


40 Pin LCD header

  • Mainboard 7

  • QSBase 1

Raspberry Pi Touch Display

For more see: Raspberry Pi 7inch Touch Display Site Site.

Usage: add the *-raspi-display FDT overlay.

Fixed resolution

RGB Displays

Glyn’s Family Concept displays


MIPI Bridges

Texas Instruments SN65DSI83

The default MIPI-2-LVDS bridge used by Ka-Ro is the Texas Instruments SN65DSI83.

An overview of its features is given by this excerpt from the Product Manual:

The SN65DSI83 DSI to FlatLink bridge device features a single-channel MIPI D-PHY receiver front- end configuration with four lanes per channel operating at 1 Gbps per lane; a maximum input bandwidth of 4 Gbps. The bridge decodes MIPI DSI 18 bpp RGB666 and 24 bpp RGB888 packets and converts the formatted video data stream to a FlatLink-compatible LVDS output operating at pixel clocks operating from 25 MHz to 154 MHz, offering a Single-Link LVDS with four data lanes per link.

The SN65DSI83 device can support up to WUXGA 1920×1200 at 60 frames per second, at 24 bpp with reduced blanking. The SN65DSI83 device is also suitable for applications using 60 fps 1366×768 / 1280×800 at 18 bpp and 24 bpp. Partial line buffering is implemented to accommodate the data stream mismatch between the DSI and LVDS interfaces.

For more see its Product Page.

Toshiba TC358867

The Toshiba TC358867 - in its industrial version called TC9595XBG - is used as a standard MIPI to RGB bridge for the TX8M, QS8M and QSXM/QSXP COMs. Despite the different names, there is no difference in functionality, and as such the Linux kernel only refers to it as a device named TC358867.

Some information of this is as follows (from the Product Manual, emphasis added):

Possible modes of Operation:

  • MODE S2P: TC9595XBG uses only Parallel output port and disables DisplayPortTx to interface to single RGB display device. Videostream source is from MIPI® DSI Host.

  • RGB Parallel Output Interface:

  • RGB888 output (DisplayPortdisabled) with only DSI input supported in this mode

More information can be found at the Product Overview, Product Page and the Product Manual available there.

Setting Display Resolution

Setting or changing the display resolution the device tree (short DT) for the Linux kernel needs to be adjusted and recompiled.

Changes might include the setting of other values of the DT node like pixelclock frequency, active high or active low, front porch and back porch, etc. These values are usually found in the sepcific display’s reference manual.

As a general rule changes to the device tree should be done by creating a new dts file that follows the include structure and changes the specific devices nodes and properties therein as needed. Changes in a dts file, which represents the leaf of the structure, will overwrite previous set values.

On the example of the SN65DSI83 MIPI-2-LVDS bridge. The current (default) values of a system set up with this bridge are given in the following DTS file:


A more comprehensive excerpt (incl. github) of the whole SN65DSI83 device node is found here.

An the excerpt (also github reference) for the whole TC358867 device node can be found here.

The node’s properties to change display setting look as follows, where each of the values shown has been taken from the respective display’s reference manual:

lvds {
        clock-frequency = <62500000>;
        hactive = <1280>;
        vactive = <800>;
        hback-porch = <6>;
        hfront-porch = <5>;
        vback-porch = <2>;
        vfront-porch = <3>;
        hsync-len = <2>;
        vsync-len = <1>;
        hsync-active = <0>;
        vsync-active = <0>;
        de-active = <0>;
        pixelclk-active = <0>;

Further on with the procedure of changing the resolution - assuming a display of some values - would look like this:

cd yocto/gatesgarth/sources/meta-karo-nxp/recipes-kernel/linux/linux-imx-5.10/mx8/dts/freescale
cp imx8mm-qsxm-mm60-qsbase3-dsi83.dts imx8mm-qsxm-mm60-qsbase3-dsi83-my-product-changes.dts
$EDITOR imx8mm-qsxm-mm60-qsbase3-dsi83-my-product-changes.dts


$EDITOR is a system variable of Linux pointing to an editor, usually something like vim or nano. Replace the command as needed.

The original file’s (imx8mm-qsxm-mm60-qsbase3-dsi83.dts) content looks like this:

// SPDX-License-Identifier: (GPL-2.0 OR MIT)
 * Copyright (C) 2021 Markus Bauer <MB@KARO-electronics.de>

#include "imx8mm-qsxm-mm60-qsbase3.dts"
#include "imx8m-qs8m-dsi83.dtsi"

/ {
        model = "Ka-Ro electronics QSXM-MM60 (NXP i.MX8MM) module on QSBASE3 baseboard with DSI83 MIPI2LVDS bridge";

&vpu_g1 {
        status = "okay";

&vpu_g2 {
        status = "okay";

&vpu_h1 {
        status = "okay";

Edting the file to respresenting own changes, particularly the display of choice, with a display of exemplary values of:



Pixelclock frequency:

50 MHz

Horizontal resolution:


Vertical resolution:


Back porch:


Pixelclock Active:


// SPDX-License-Identifier: (GPL-2.0 OR MIT)
 * Copyright (C) 2021 Oliver Wendt <OW@KARO-electronics.de>

#include "imx8mm-qsxm-mm60-qsbase3-dsi83.dts"

/ {
        model = "Ka-Ro electronics QSXM-MM60 (NXP i.MX8MM) module on QSBASE3 baseboard with DSI83 MIPI2LVDS bridge + My Changes";

&lvds {
        clock-frequency = <50000000>;
        hactive = <1024>;
        vactive = <800>;
        hback-porch = <12>;
        pixelclk-active = <1>;

This changed DT file, is then to be compiled into a DTB which then needs to be uploaded to the COM.

MIPI to RGB Bridge

There is an exception pertaining RGB TFT displays (specifically Glyn’s Family Concept displays) connected via the TC358867 MIPI-2-RGB bridge. As also stated in the DTS file itself, does the TC358867 bridge require to be set to an specific pixelclock frequency, see also example below.

For more see the RGB Bridge Display Device Tree.

display-timings {
        lcd {
                // all EDT displays - Leave clock at 25175000!!!
                clock-frequency = <25175000>;
                hactive = <320>;
                vactive = <240>;
                hback-porch = <38>;
                hfront-porch = <20>;
                vback-porch = <14>;
                vfront-porch = <4>;
                hsync-len = <30>;
                vsync-len = <4>;
                hsync-active = <0>;
                vsync-active = <0>;
                de-active = <1>;
                pixelclk-active = <0>;

Loading Display DTB

To apply the changes of the DT on the module the user needs upload the newly created and changed DT to the COM and adjust the U-Boot e.g. TX8M-1620 environment as to which DTB is to be loaded from the eMMC boot partition.

The DT file to be loaded by U-Boot is defined in the variable fdt_file:


changing this to the apporpriate file name will apply the changes to the system at next reset.


Which file has been loaded by U-Boot can be seen in the e.g. TX8M-1620 POR output of U-Boot, where it says:

loading FDT from mmc 0 'imx8mm-tx8m-1620-lvds-mb.dtb'

STM display setting

For our STM modules, QSMP* and TXMP*, you need to set the videomode variable in U-Boot as follows:

setenv videomode TM101

With the videomode variable U-Boot selects the display-timing out of the dtb. You can see the available displays for your module with the following command in U-Boot

fdt ls display/display-timings

Choose your connected display and replace TM101 in the command above.