How to enable HDMI video output

  • Hello,

    how do I set video output to HDMI with the standard linux kernel / rootfs?

    I tried to add following to the bootargs:

    1. video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24

    but the efus is always booting with a standard set 800x480 LCD display. So how can I change display settings?

    Here's my Kernel Command Line:

    1. Kernel command line: console=ttymxc3,115200 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 fec_mac=00:05:51:08:ED:CE mtdparts=gpmi-nand:512k(NBoot)ro,2m(UBoot)ro,256k(UBootEnv),256k(UserDef),6m(Kernel)ro,-(TargetFS) gpmi_debug_init enable_wait_mode=off ubi.mtd=TargetFS root=ubi0:rootfs rootfstype=ubifs rootwait rw

    Here's my fbset --info:

    I tried to find out some more. Here is what the kernel log is displaying:

    1. mxc_sdc_fb mxc_sdc_fb.0: register mxc display driver hdmi
    2. mxc_sdc_fb mxc_sdc_fb.0: NO mxc display driver found!
    3. mxc_sdc_fb mxc_sdc_fb.1: register mxc display driver lcd

    I guess HDMI is enabled in kernel. These related files are compiled:


    Any suggestions what's wrong? Help is needed please.

    Thanks for answers.

  • OK, I'll try to explain what happens. The board support file has an internal list of activated displays. On the Quad and Dual versions of the CPU we have two IPUs which are each capable of driving up to two displays. So we can have up to four displays (1x RGB-LCD, 1x HDMI, 2x Single-Channel-LVDS or 1x Dual-Channel-LVDS). Each display gets an internal display instance called mxcfb and a framebuffer in the /dev directory, numbered starting with zero and increasing in the order of appearance. In addition the first display instance on each IPU also automatically gets a video overlay added that adds an additional framebuffer. So in fact our current release does activate three displays on armStoneA9 and QBlissA9: display instance mxcfb0 as HDMI on /dev/fb0 (with video overlay on /dev/fb1), display instance mxcfb1 as LVDS on /dev/fb2 and display instance mxcfb2 as RGB-LCD on /dev/fb3 (with video overlay on /dev/fb4).

    On the DualLite and Solo versions of the i.MX6 CPU we only have one IPU. So we can activate at most two displays at the same time. So in the default board configuration file of efusA9 and PicoMODA9 we have decided for LVDS and LDB: display instance mxcfb0 as LVDS on /dev/fb0 (with overlay on /dev/fb1) and display instance mxcfb1 as RGB-LCD on /dev/fb2. There is a compile time option "HDMI_ON" in the board support file (see arch/arm/mach-mx6/board-mx6q_<boardname>.c) to activate HDMI instead of one of the other two displays.

    OK, what happens if you give the video= setting on the command line? This setting will override the setting for the appropriate mxcfb display instance. Because you have given mxcfb0, your setting will override the first entry of the internal table, that is the LVDS setting (in i.MX6 terms called LDB). So actually the LVDS display is deactivated and the driver tries to activate HDMI. But because of the HDMI_ON macro being zero in the board support file, some necessary structures of the HDMI driver are not registered at start-up and therefore activating the HDMI display will fail. So you will not have HDMI output, in fact you will not have any output for this display instance.

    But where does the 800x480 display come from that you actually see instead? Well, as I said, there are two active entries in the internal display table. So the second entry is still active, and this is the RGB-LCD entry. So you now have display instance mxcfb1 as RGB-LCD on /dev/fb0 (with video overlay on /dev/fb1).

    So what can you do to get HDMI running? I assume you will have to recompile the kernel with the HDMI_ON macro set to 1 in the board support file. Then on the efusA9, HDMI should be active as display instance mxcfb0 on /dev/fb0 by default (with video overlay on /dev/fb1). And of course RGB-LCD is active as mxcfb1 on /dev/fb2.

    This need for recompilation is a little bit unfortunate and we try to get this better in the next release. Most probably we will only have one display instance active there by default. Because most people don't know about the additional displays anyway and do not deactivate them (by removing them from the internal table) if they don't need them. And then they have unnecessary system bus load and power consumption for the (up to two) additional displays.

    Your F&S Support Team

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    Edited once, last by fs-support_HK ().

  • Please, I would be grateful if you can explain how did you enable the HDMI_ON from the board support files?

    I have efusA9 board and I want to compile the build "buildroot-2016.05-fsimx6-V3.1" but when I do "make menuconfig" I can not find in the list the option to activate the HDMI driver.

    kind regards

  • Activating HDMI is already pre-configured in the device tree. You only need to set the framebuffer macro (CONFIG_EFUSA9_MXCFB0) accordingly. Let's assume that you only want to have HDMI output, no LCD (RGB) output and no LVDS output. So you only need one framebuffer for HDMI. Depending on whether you have a Solo/DualLite or a Quad efusA9, you need to change the file efusa9dl.dts or efusa9q.dts. This file is located in the Linux source tree under arch/arm/boot/dts. If you have already built Buildroot, then you can find this in


    Look for the lines


    Change the first of the two lines to:


    Then rebuild the Linux kernel

    1. make linux-rebuild

    Now you have a new device tree in

    output/images/efusa9dl.dtb (or efusa9q.dtb on the Quad version)

    If you call make menuconfig in Buildroot, you will only get the configuration for Buildroot. If you want to change the kernel settings, you have to call make linux-menuconfig. Similarly, if you want to change the busybox settings, you need to call make busybox-menuconfig.


    Changes to the kernel that are done in output/build/linux-custom are only temporary changes. Please note that they are completely lost if you ever do a make clean or other cleaning command. So the best way is to sync your changes from time to time to the linux-fsimx6 directory next to your buildroot directory. This is also the directory that you should use if you put the source code under version control.

    When buildroot is built for the very first time, it copies the Linux directory (next to buildroot) to output/build/linux-custom by using rsync. From then on, this build directory is used, unless you trigger the rsync process again.

    Your F&S Support Team

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.