Configuring i.MX6 boards for different screens

One of the first hurdles to a great out-of-the-box-experience we have on i.MX6 at the moment is configuration of screen resolutions. We’re aiming to support four different displays on the Nitrogen6X and Sabre Lite:

Unfortunately, our set of tools doesn’t yet support automatic detection of the displays, so we’ve been using a number of work arounds. In this post, we’ll describe the general state of affairs and hopefully let you know how to set things up for your use.


To begin with, the U-Boot versions we’re shipping don’t yet support displays. Fabio Estevan published some patches that allow Sabre Lite to support the Freescale panel and we have some patches gathering dust that support the RGB display and our 1024×600 panel, but we haven’t yet released this into our shipments.

This is yet another reason for us to make the transition to main-line U-Boot.


The Linux kernels we’re shipping do contain support for all four displays listed above. You can configure them through the kernel command line (bootargs in U-Boot).

In the various releases, this is either done by a generic boot script which expects you to set and save a persistent bootargs or bootargs_base variable, or has a set of boot scripts with various settings hard-coded in the boot script.

Kernel parameters

The kernel parameter values for the displays are:
Display Setting
7″ 800×480 resistive touch mxcfb0:dev=lcd,CLAA-WVGA,if=RGB666
7″ 1024×600 capacitive multi-touch mxcfb0:dev=ldb,1024x600M@60,if=RGB666
Freescale’s LVDS1 mxcfb0:dev=ldb,LDB-XGA,if=RGB666
HDMI at 720P mxcfb0:dev=hdmi,1280x720M@60,if=RGB24
Note that there are four components to the video= clause:
mxcfbN: This display specifier defines the ordering of display devices under Linux. Note that there is not a 1:1 correspondence with /dev/fbN because /dev/fb1 and /dev/fb3 will be automatically configured as overlay devices for /dev/fb0 and /dev/fb2.
dev=X This clause specifies the output interface used for the display. Options are lcd for the parallel RGB interface, ldb for the LVDS interface and hdmi for the HDMI transmitter.
displayname or resolution This clause can either define a named panel such as LDB-XGA or CLAA-WVGA or a resolution in VESA Coordinated Video Timings format. Named panels are defined in a board-specific file.
if=depth This clause defines the output format at the transmitter. Options include RGB666 for 18-bit panels and RGB24 for 24-bit displays. Note that this does not define the in memory bit depth of the frame buffer. That’s done with the bpp= kernel command-line parameter.

Distribution-specific notes


Our Android image contains support for four different display resolutions through separate boot scripts:
-rwxr-xr-x 1 root root 887 2012-05-21 12:24 6q_bootscript
-rwxr-xr-x 1 root root 466 2012-04-15 20:57 6q_bootscript.1080p
-rwxr-xr-x 1 root root 342 2012-04-03 19:04 6q_bootscript.7inresistive
-rwxr-xr-x 1 root root 382 2012-04-03 19:05 6q_bootscript.dual_hdmi_hannstar
-rwxr-xr-x 1 root root 338 2012-04-03 19:01 6q_bootscript.hannstar
The default boot script will attempt to determine whether HDMI is supported using the hdmidet command. In order for this to function, a Boundary Devices U-Boot image newer than April 12, 2012 must be running. If present, a 720P HDMI display will be configured as the primary display and a WVGA display will be configured as a secondary (or vice versa).

Support for the 1024×600 LVDS panel was added after the Android image was built. Please note the notes in the comment section for a description of how to add support for this panel.


Timesys images generally expect you to define the bootargs variable to contain a display reference:
U-Boot> setenv bootargs mxcfb0:dev=hdmi,1280x720M@60,if=RGB24
U-Boot> saveenv
U-Boot> run bootcmd

Windows CE

Windows Embedded Compact 7 from Adeneo contains two support for HDMI and the Freescale LVDS1 panel in the form of two separate O/S images (NK*.bin).


At the time of this writing, only the 7″ Parallel RGB display is supported in QNX.

Known issues

There is a known bug in the HDMI driver which causes display corruption if an HDMI monitor is either disconnected and reconnected or powered down and back up during operation.


95 Responses to “Configuring i.MX6 boards for different screens”

  1. ericn July 25, 2012 5:56 pm #

    A customer just reminded me of an outstanding bug related to Ubuntu releases and the 7″ display.

    It appears that something in the startup of X decides to re-configure the display and in the process, bit 17 of the IPU1_DI0_GENERAL register gets cleared to zero. This bit defines the pixel clock polarity and this will result in visible artifacts on the display.

    If you see this problem, you can use the ‘devregs’ tool at to verify the symptom and temporarily fix it.

        root@linaro-ubuntu-desktop:~# devregs IPU1_DI0_GENERAL
        IPU1_DI0_GENERAL:0x02640000    =0x00300004
        root@linaro-ubuntu-desktop:~# devregs IPU1_DI0_GENERAL 0x00320004
        IPU1_DI0_GENERAL:0x02640000    =0x00300004
        IPU1_DI0_GENERAL:0x02640000 == 0x00300004...0x00320004

    You can read about devregs in this post:

    And you can get the sources here:

    • Michael S. June 4, 2013 11:05 pm #

      Hi Eric,
      I am trying to install Linux on our custom board similar to the I.MX6Q SabreLite board. I am using linux-imx6-boundary-imx_3.0.35_4.0.0 and linux-imx6-boundary-imx_3.0.35_1.1.1. On the SabreLite HDMI uses I2C2, and on our custom board HDMI uses I2C3.
      How to move HDMI from I2C2 to I2C3?
      I am move I2C_BOARD_INFO(“mxc_hdmi_i2c”, 0x50) from static struct i2c_board_info mxc_i2c1_board_info[] __initdata to
      static struct i2c_board_info mxc_i2c2_board_info[] __initdata in board_mx6q_sabrelite.c …
      What else it is necessary to make? (excuse for my bad English).
      During u-boot loading time I see the image on the monitor, and during Linux operating time – no …

      • ericn June 5, 2013 10:21 am #

        Hi Michael,

        That’s all of the glue you should need.

  2. ericn July 27, 2012 4:49 pm #

    The cabling for either LVDS displays uses two connections on the Sabre Lite or Nitrogen6X board and a single connection on the display end.

    We have custom cables for the Freescale LVDS1 display as shown in this photo:

    This photo shows how the cabling is routed to J6 and J7 on a Sabre Lite.

    • Michael January 14, 2013 7:13 am #

      Is there a pinout / schematic on the adapter cable that you have?
      Curious on how the signals are mapped between the connectors.

      • ericn January 14, 2013 8:17 am #

        The Hardware user manual for each of our products lists the pin-outs for each of the displays.

        The schematic for the SABRE Lite is also available in the Support tab of the product page.

        The data sheets for each of the panels (7″ 1024×600, 7″ 800×480) we distribute are also available in their respective Support tabs.

  3. ericn August 7, 2012 9:32 am #

    We just noticed that the Hannstar boot scripts in the Android image were missing a ‘vmalloc=400M’ clause, which caused them to fail allocating frame buffers.

    The zip file at contains updates.

  4. bmy September 3, 2012 4:56 am #

    I’m using the lvds output wich is working fine. I wonder if it is possible to rotate the screen to 90° clockwise. I haven’t found any kernel arguments or tutorials using xrandr.

    • ericn September 3, 2012 8:02 am #

      Hi bmy,

      This isn’t really i.MX6 specific, but we wrote some notes about X-Windows rotation under LTIB here:

      If you read the comments, there are some notes about Debian and the console as well.



      • bmy September 3, 2012 10:58 am #

        Thank you for your comment eric. Unfortunately I do not use LTIB but an Ubuntu 12.03 version. According to the comments I would have to follow a set of patches to perform on my system. Unfortunately I do not have the time to. I remember that most of the systems allowed several kernel arguments, why does the freescale drivers do not provide a corresponding implementation?

  5. zwitt September 18, 2012 12:45 pm #

    Hi Eric,

    for our application we need a 10″ PCAP display.
    Could you please check if it were possible that display :
    to the sabre board to connect ?
    If necessary, what should be done so that it works ?

    Thanks and Best Regards from Görlitz


    PS Sorry for my poor English

    • ericn September 18, 2012 1:42 pm #

      It certainly looks straightforward at first glance. You’ll need at least a custom cable to match up with J6 (LVDS) and J7 (Power/I2C) as shown
      in the SABRE Lite schematics.

      Backlight control is usually the hardest part of this kind of integration, but I’d be surprised if it required much if any additional circuitry.

  6. David February 5, 2013 12:40 pm #

    I have an HDMI TV display running that is not responding to the edid inquiry. I would like to change the default mode list so that I can get sound over the HDMI into the TV. Where is this list and is it persistent and editable?

    • ericn February 5, 2013 2:44 pm #

      I don’t know of an easy way to over-ride this, either through command-line or code edits. This is on our “like to fix” list, since for many applications, it’s the right thing to force a particular output resolution and config.

      You might want to reach out to others on i.MX Community to see if someone’s tackled this before.

  7. Alexander February 25, 2013 4:31 pm #

    Hi, we are using Sabre Lite board with 7″ 1024x×600 LVDS display for our SW development.
    Okaya specification saying that this display is capable to work in 6bit/8bit modes. I measured the SELB pin (#28) on LCD Daughter board: HIGH level, which is 6 bit mode.
    Are there any suggestions of how to turn this display into 8bit LVDS (24-bit color) mode? Some mods on LCD Daughter board somebody tried already? Thank You.

    • ericn February 26, 2013 5:27 pm #

      Hi Alexander,

      We’ll run this test when time permits.

      If you’re in a position to pull the pin low, you can test it from a software side
      by simply changing the ‘if=RGB666′ to ‘if=RGB24′ on the kernel command-line.

  8. Paul DeMetrotion March 27, 2013 8:59 am #

    I am looking for some video assistance on a custom i.MX6Q board we have in development. Currently I have HDMI and LVDS displays connected. When I boot our Ubuntu Linux kernel, only the video source which is attached to mxcfb0 displays the GUI. I can still utilize both displays using gstreamer. Should I be able to use both displays to extend the Ubuntu GUI? If so is the xorg.conf file used to set this up?

    Earlier in the boot cycle only the selected display displays the Linux penguins while the other display isn’t even in sync. Once the file system starts to load both displays get in sync. Following is the u-boot environment variables:
    bootargs=console=ttymxc0,115200 video=mxcfb0:dev=hdmi,1280x720M@60,if=RGB24 video=mxcfb1:dev=ldb,1024x600M@60,if=RGB666

    If I switch the fb0 and fb1 variables, then the LVDS display works and the HDMI display does not.

    Is there something within my custom board files that control which display gets enabled? How do I get both displays to work during the early boot cycle? I would expect to see penguins on both displays.

    Thanks is advance.

    • ericn March 27, 2013 1:43 pm #

      Hi Paul,

      I’m not certain what X magic is needed to drive both displays. I suspect that it involves Xinerama, but that could be wrong.

      I can explain the early boot cycle thing: U-Boot only has support for one display. Re-working it to support multiple would require hacking drivers/video/mxc_ipuv3_fb.c and associated modules in the U-Boot sources.

      • PaulD March 27, 2013 2:49 pm #

        Thanks for the response. I have been playing with Xinerama without any luck so far.

        Should I be able to have dual displays when the uImage is booting? I have an iWave board that displays penguins on both displays after u-boot hands off to the uImage kernel boot. Our custom board only displays penguins on the display that is mapped to fb0, either hdmi or lvds. Not a big deal but would like to have both if possible. The display mapped to fb1 never even syncs until late in the kernel boot.

        • ericn March 27, 2013 3:19 pm #

          Hi Paul,

          Nice dig with the “my iWave board does ….” ;)

          Penguins are easy though. You’ll just need to unblank /dev/fb2 somewhere in the boot process:

          # echo 0 > /sys/class/graphics/fb2/blank

          Note that /dev/fb1 is the YUV overlay associated with /dev/fb0 though. It’s not normally the second display.

          You can get a more complete picture through this bit of shell-fu to browse the /sys tree:

          for fb in /sys/class/graphics/fb? ; do
               echo "----------- $fb";
               cat $fb/name;
               cat $fb/mode;
               cat $fb/fsl_disp_*;
  9. PaulD March 28, 2013 11:29 am #

    New finding on the Dual Screen issue with our iMX6Q custom board. I found the following error in my Xorg.0.log file – Screen 1 deleted because of no matching config section. This would explain why I cannot utilize the second display. Any ideas what is missing?

    [ 73.592] (II) VIVANTE: fb driver for vivante: VivanteGC500, VivanteGC2100,
    [ 73.593] (++) using VT number 7

    [ 73.593] (WW) Falling back to old probe method for vivante
    [ 73.593] (II) Loading sub module “fbdevhw”
    [ 73.593] (II) LoadModule: “fbdevhw”
    [ 73.594] (II) Loading /usr/lib/xorg/modules/
    [ 73.605] (II) Module fbdevhw: vendor=”X.Org Foundation”
    [ 73.605] compiled for 1.10.4, module version = 0.0.2
    [ 73.605] ABI class: X.Org Video Driver, version 10.0
    [ 73.606] (II) Loading /usr/lib/xorg/modules/drivers/
    [ 73.606] (II) Loading /usr/lib/xorg/modules/
    [ 73.606] (II) VIVANTE(0): using default device
    [ 73.606] (II) Loading /usr/lib/xorg/modules/drivers/
    [ 73.606] (II) Loading /usr/lib/xorg/modules/
    [ 73.606] (II) VIVANTE(1): using default device
    [ 73.606] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
    [ 73.606] (EE) Screen 1 deleted because of no matching config section.
    [ 73.606] (II) UnloadModule: “vivante”
    [ 73.606] (II) Unloading vivante
    [ 73.606] (II) UnloadModule: “fbdevhw”
    [ 73.606] (II) Unloading fbdevhw
    [ 73.607] (II) VIVANTE(0): Creating default Display subsection in Screen section

  10. Soujanya April 8, 2013 11:53 pm #

    I am interfacing 1920X1080 LVDS bit display with IMX6 custom board(sabrelite).I changed the u-boot environment variables as below: video=mxcfb0:dev=ldb,LDB-1080P60,if=RGB24,ldb=spl0,
    but i am unable to see anything on the display, are there any other configurations that need to taken care of?

  11. Mughees Ahmed Chohan May 31, 2013 2:56 am #


    I am working with the Freescale LVDS Display in a proprietary RTOS using sabre lite platform. I have got the display working but I am unable to find any documentation about the TOUCHSCREEN CONTROLLER present on this LCD. There is no information available about it on the Freescale Website. I shall be glad if anyone is able to help on this. Thanks.

    Mughees Ahmed Chohan

    • ericn May 31, 2013 6:27 am #

      Hi Mughees,

      We don’t have any documentation on the touch controller (an EETI eGalax 5-pointer device), but we do have the source code, and it has a very simple interface.

      You may be able to get more information directly from EETI.

  12. Andrew June 26, 2013 7:07 am #

    Hi Eric, just to confirm if we are using an RGB 666 lcd with the the sabrelite, then the RGB signals mappings are as follows, right?:
    R7:R2 – DISP0_DAT23:DISP0_DAT18
    G7:G2 – DISP0_DAT15:DISP0_DAT10
    B7:B2 – DISP0_DAT7:DISP0_DAT2

  13. Andrew June 28, 2013 11:53 pm #

    Hi Eric, I am having difficulty interfacing to a 2.4 inch lcd screen in RGB666 mode with the sabrelite. I’ve spent 6+ hrs trying to debug it, hence seeking help here. I am using this mapping:
    R7:R2 – DISP0_DAT23:DISP0_DAT18
    G7:G2 – DISP0_DAT15:DISP0_DAT10
    B7:B2 – DISP0_DAT7:DISP0_DAT2
    I’ve posted the image irregulaties I am seeing here:

    Do you know what this could be? and do I have the mapping right? Regards

    • ericn June 29, 2013 9:51 am #

      Hi Andrew,

      What are you using for the video= clause in the kernel command-line?

      • Andrew June 29, 2013 10:05 am #

        I am using the following:

        but when I run fbset -s, I get the following:

        mode “240×320-55″
        # D: 5.510 MHz, H: 18.367 kHz, V: 54.663 Hz
        geometry 240 320 240 320 16
        timings 181488 49 1 4 10 10 2
        rgba 5/11,6/5,5/0,0/0

        which seems to indicate that it is configured for RGB565. Either way is fine with me, as long as I get the pin mappings right. I think thats where I am messing up.

        • ericn June 29, 2013 10:23 am #

          Hi Andrew,

          The 565 reference is to the in-memory pixel format, not the output.

          fbset knows nothing about the output pixel format.

          Can you try using if=RGB24 on your kernel command-line? This specification alters the way that pixel values are represented on the DISP0_DAT pins.

          • Andrew June 29, 2013 10:51 am

            I will try this but could you please elaborate how this changes the way that pixel values are represented on the DISP0_DAT pins? Thanks

          • ericn June 29, 2013 11:28 am

            Hi Andrew,

            I’m not aware of any good documentation on the subject, but the IPU of the i.MX processors does a pixel conversion from input (RAM) to output (in your case, the parallel display pins) based on two data formats, and the if= clause changes the output format.

            The sources are here in mxc_ipuv3_fb.c.

  14. MichaelG July 22, 2013 6:04 am #


    For some projects we need to adapt several LVDS displays to be supported on a sabreLITE board.
    We are using JB 4.2.2-1.1.0 from the bouldary repository.
    I found a 640×480 TFT (AUO G104VN01) and an appropriate connector and after changing the 6x_bootscript_jb.txt I could see a good picture on the display. But it seems that the Android desktop is 800 pixel width. I only can see 2/3 of the Android desktop. Strange is that dm.widthPixels gives 640.

    Is the minimum Android desktop widt 800?
    As we are running an own compiled Android it is possible for us to do changes. Where and how does Android set the the desktop width ?

    Many thanks,

    • ericn July 22, 2013 7:09 am #

      Hi Michael,

      The short answer is “No”. Android doesn’t have a minimum width of 800.

      We’re using Android with VGA displays (on the OC board), and also a 480×272 display.

      There is a bit of code in Android which determines whether to use a “tablet” or “phone” layout based on the screen resolution. In the “phone” layout, the on-screen controls for Home and Back aren’t displayed, so hard buttons are needed.

      If memory serves, VGA should select the tablet layout.

      Can you be more specific about what you’re seeing?

      Can you upload a photo and start a conversation on i.MX Community?

  15. Mark July 25, 2013 1:15 pm #

    Hey Eric, we’re seeing some strangeness with the way fg/bg gets assigned. The original goal (since the application is coded this way) is to have fb0/fb1 used for hdmi and fb2/fb3 used for a lcd touchscreen. Booting with the original bootscript, the lcd doesn’t get a fg fb (fb3), and poking through sysfs shows fb3/fb4 set up as fg/bg for ldb. Don’t have one at the moment, but if memory serves, if an ldb is present, it will get fb2/fb3 and the lcd will get fb4.

    Unplugging the hdmi and fb0/fb1 ends up with the lcd and fb2/fb3 ends up on the ldb. I think this happens whether the hardware is present or not.

    If the bootscript is changed so the hdmidet is after the touchscreen probes, the lcd gets a fg/bg (fb0/fb1) the hdmi only gets a bg (fb2), and fb3/fb4 are assigned to ldb. Somewhat expected, unplugging hdmi puts ldb on fb2/fb3.

    Of couse, in all cases, the boot log shows mxcfb[0-2] as on or off depending on what is present.

    Is there a simple explaination for what’s going on with fb2/fb3 and the presence of hdmi? If not, a more complicated wouldn’t hurt either…

  16. ericn July 25, 2013 4:16 pm #

    Hi Mark,

    I’d suggest doing this in two parts:

    1. Firstly, set ‘bootargs’ by hand until you get it all tested, and then
    2. Work on the boot script

    Step 1 normally looks something like

    U-Boot > setenv bootargs blah blah video=mxcfb0:dev=hdmi,1280x720M@60,if=RGB24 ...
    U-Boot > mmc dev 0 10800000 /boot/uImage && bootm 10800000

    You can copy the blah blah ... from the kernel output where it says “Kernel Command-line” and save it in a text editor somewhere for fixup and paste into the U-Boot command line.

    The device specified in a video=mxcfb0: clause will be connected to /dev/fb0 and /dev/fb1. Likewise, video=mxcfb1: will set up /dev/fb2 and /dev/fb3.

    Once you have these commands, you can just build a boot script with precisely what you want and skip the whole auto-detect thing. That’s really only needed for folks like us who don’t know what kind of displays a customer will use.

  17. Mark July 26, 2013 8:01 am #

    Hey Eric, I thought we had covered all the permutations, but to make sure I reran things this morning:

    # cat /proc/cmdline ; for i in /sys/class/graphics/fb?; do echo "------------ $i"; cat $i/name; cat $i/mode; cat $i/fsl_disp_*; done
    video=mxcfb2:off fbmem=10M,28M 
    console=ttymxc1,115200 vmalloc=400M consoleblank=0 rootwait debug root=/dev/mmcblk0p1
    ------------ /sys/class/graphics/fb0
    DISP3 BG - DI1
    ------------ /sys/class/graphics/fb1
    DISP3 FG
    ------------ /sys/class/graphics/fb2
    DISP3 BG
    ------------ /sys/class/graphics/fb3
    DISP4 BG
    ------------ /sys/class/graphics/fb4
    DISP4 FG
    # cat /proc/cmdline ; for i in /sys/class/graphics/fb?; do echo "------------ $i"; cat $i/name; cat $i/mode; cat $i/fsl_disp_*; done
    video=mxcfb2:off fbmem=10M,28M console=ttymxc1,115200 vmalloc=400M consoleblank=0 rootwait debug root=/dev/mmcblk0p1
    ------------ /sys/class/graphics/fb0
    DISP3 BG
    ------------ /sys/class/graphics/fb1
    DISP3 FG
    ------------ /sys/class/graphics/fb2
    DISP3 BG - DI1
    ------------ /sys/class/graphics/fb3
    DISP4 BG
    ------------ /sys/class/graphics/fb4
    DISP4 FG
    # cat /proc/cmdline ; for i in /sys/class/graphics/fb?; do echo "------------ $i"; cat $i/name; cat $i/mode; cat $i/fsl_disp_*; done
    video=mxcfb2:off fbmem=10M,28M console=ttymxc1,115200 vmalloc=400M consoleblank=0 rootwait debug root=/dev/mmcblk0p1
    ------------ /sys/class/graphics/fb0
    DISP3 BG
    ------------ /sys/class/graphics/fb1
    DISP3 FG
    ------------ /sys/class/graphics/fb2
    DISP4 BG
    ------------ /sys/class/graphics/fb3
    DISP4 FG

    fbmem= is mostly wrong in the above, but I’m just looking for fb assignment. I also don’t have a device for ldb, and hdmi and lcd are present in these tests (instead of having a boot script figure it out).

    Looks like the only thing which will get fg/bg on fb2/fb3 is ldb. lcd or hdmi as the second display/mxcfb1 never gets a foreground. At a guess, there’s something in ldb that along with insisting it be assigned , insists it have both a fg/bg.

    • ericn July 26, 2013 8:36 am #

      Hi Mark,

      Something’s wrong here. In particular, where is that 1280×800 LDB display coming from?

      We’ll look into this ASAP.

    • ericn July 26, 2013 8:56 am #

      Hi Mark,

      It appears that mxcfb3 (which isn’t connected) is coming up as a default LDB display, and needs to be explicitly turned off using video=mxcfb3:off.

      I’m guessing that this is a regression with the 4.0.0 kernel, since this wasn’t needed in our triple-display configuration on 1.1.1.

      Please try that out and let us know how it works for you.

  18. Mark July 26, 2013 10:03 am #

    I hate to say it Eric, but I believe I’m running 1.1.1 (doesn’t use board-mx6_nitrogen6x.c). At one point I tried to disable ldb completely, and the results were the same as adding video=mxcfb3:off:

    # cat /proc/cmdline ; for i in /sys/class/graphics/fb?; do echo "------------ $i"; cat $i/name; cat $i/mode; cat $i/fsl_disp_*; done
    video=mxcfb3:off fbmem=10M,28M console=ttymxc1,115200 vmalloc=400M consoleblank=0 rootwait debug root=/dev/mmcblk0p1
    ------------ /sys/class/graphics/fb0
    DISP3 BG
    ------------ /sys/class/graphics/fb1
    DISP3 FG
    ------------ /sys/class/graphics/fb2
    DISP3 BG - DI1
    • ericn July 26, 2013 10:07 am #

      Well, … rats!

      This did get rid of the spurious 1280×800 LDB display, but isn’t providing a proper FG for the HDMI port…

      You are running on a Quad-core CPU, right? The Solo/Dual-Lites only have a single IPU, so they only get one FG layer.

      • ericn July 26, 2013 10:29 am #

        Never mind my question. I just confirmed this on Quad.

      • Mark July 26, 2013 10:54 am #

        Just to confirm, this is a quad board.

    • ericn July 27, 2013 2:14 pm #

      Hi Mark,

      Okay, we’ve figured this out. The trouble stems from an internal artifact of the hardware and how we’ve assigned display channels to HDMI.

      I apologize for the delay. I knew this, but hadn’t visited it since we did the triple display demo last October.

      At the hardware level, the i.MX6Q processor has two internal IPU devices, and each of them has a single channel that can be used for an overlay.

      The RGB display output is a functional part of an IPU, and our RGB connection is attached to DI0 or Display Interface 0 of that part.

      The LVDS and HDMI channels can be assigned to either IPU, but the assignment isn’t made at run-time. We hardcoded them here (HDMI on DI0) and here (LVDS on DI1) in the ipu_id field.

      Displays are initialized in order of the video= statements on the kernel command-line, and the first display on each IPU will get a foreground or overlay layer.

      Since your command-line above initializes the LCD and HDMI ports, which are both assigned to IPU0, only the LCD gets the FG device.

      In the near term, you should probably edit the assignment of HDMI and place it on IPU1 to get two displays with overlays.

      • Mark July 27, 2013 3:11 pm #

        First, really appreciate you looking into this, Eric. I went off yesterday digging into the lvds (ldb.c?) since it seemed to be the one that was always “taking over” any second foreground (along with just being present until the extra video= was added). I was coming to the realization that it was the ipu, but it probably would have been a while before coming back to the board file.

        The examples I did with lcd first and hdmi second were to satisfy an application requirement. The lcd has to have a fb/bg and hdmi really only needs one framebuffer. Unfortunately, what I’m hearing from the application people is that swapping all the framebuffers and especially getting hdmi to use the background is problematic. So, the ideal situation would be to go back to hdmi first and lcd second. That being the case, I should probably go down a few lines for the lcdif assignment, correct?

        • ericn July 27, 2013 6:11 pm #

          Hi Mark,

          I’m not aware of anything to prevent you from placing the HDMI on IPU1 by changing this 0 to a 1, which will give you FG layers on each.

          Can you have the application people chime in and explain their concern? AFAIK, IPU1 isn’t background or in any way a less-capable channel, it’s just the second.

          You can’t change the LCD to DI1 because it’s hard-wired to that IP block.

          • Mark July 29, 2013 7:17 am

            Ok, Eric. Back in front of a build environment and hardware.

            Using the 4.0.0 kernel, this does setup the displays as expected. The lcd is fb0/fb1 and hdmi is fb2/fb3. This kernel has been giving me problems with the application. The only good information I’ve gotten has been ENOTTY on the ioctl() after opening /dev/galcore. After a short time, the application is killed with a SIGSEGV.

            Since that has been an issue, I’ve been using what I think is the previous kernel (1.1.1? since uname -a reports the same version, not sure how else to differentiate these), I made the same change in the board file there (board-mx6x_sabrelite.c). That causes a hang with:

            mmc0: Timeout waiting for hardware interrupt.
            sdhci: =========== REGISTER DUMP (mmc0)===========
            sdhci: Sys addr: 0x00000000 | Version: 0x00000002
            sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000001
            sdhci: Argument: 0x00000c00 | Trn mode: 0x00000000
            sdhci: Present: 0xfffd8089 | Host ctl: 0x00000001
            sdhci: Power: 0x0000000d | Blk gap: 0x00000000
            sdhci: Wake-up: 0x00000000 | Clock: 0x000010ff
            sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
            sdhci: Int enab: 0x007f0003 | Sig enab: 0x007f0003
            sdhci: AC12 err: 0x00000000 | Slot int: 0x00000003
            sdhci: Caps: 0x07eb0000 | Caps_1: 0x00000007
            sdhci: Cmd: 0x0000341a | Max curr: 0x00ffffff
            sdhci: Host ctl2: 0x00000000
            sdhci: ===========================================
            INFO: rcu_sched_state detected stall on CPU 0 (t=6000 jiffies)
            INFO: rcu_sched_state detected stall on CPU 0 (t=24030 jiffies)

            I will look at reimaging for 4.0.0. Any insight into either of two issues above?

          • ericn July 29, 2013 8:40 am

            Hi Mark,

            I’m glad to hear (and not surprised) that the kernel update fixed things up for you.

            Note that you will need to re-build your userspace to switch from kernel versions 1.1.x or earlier to 4.0.0, since there were ABI changes in the GPU driver.

            If you built your kernel from a git repository, you should be able to see a version tag in /proc/version:

            root@nitrogen6x:~# cat /proc/version
            Linux version 3.0.35-02668-g7d87529-dirty (ericn@ericsam) 
                (gcc version 4.6.2 20110630 (prerelease) (Freescale MAD -- Linaro 2011.07 -- Built at 2011/08/10 09:20) ) 
                #21 SMP PREEMPT Sun Jul 28 13:29:55 MST 2013

            The string after the -g is a short-version git revision. You can use git show to find it in your repository, and git branch --contains to find out what branch(es) the commit lives on. The -dirty flag indicates that something was changed but not committed in my repository.

            ~/linux-imx6$ git show 7d87529 | head -n 5
            commit 7d8752905c118af9063738a533227de0b2f6ecd4
            Author: Robert Winkler 
            Date:   Fri Jul 19 19:00:41 2013 -0700
                Add support for DVI monitors
            ~/linux-imx6$ git branch --contains 7d87529
            * boundary-imx_3.0.35_4.0.0

            As for the SDHCI issue, I’m not sure, but think we should address it in a separate thread if it persists on a matched userspace and kernel.

  19. Hannu September 8, 2013 7:45 am #

    is it possible to use a 1440×1050 LVDS lcd with the Nitrogen6x?

    • ericn September 9, 2013 6:54 am #

      Hello Hannu,

      The answer is probably “Yes”, but you’ll need to check how many lanes the panel has.

      Some high-def panels require both LVDS channels and we support that on some custom boards (not Nitrogen6x). To date, we’ve only seen that with 1080p displays though.

  20. ChrisS September 19, 2013 4:00 pm #


    I’ve recently purchased the Nit6X_10.1Hannstar, the BD-SL-i.MX6 and the LVDS Cable for Freescale 10.1″ Hannstar. Since all these products are from boundary I would have expected them to ‘plug and play’ before I started changing anything. This does not appear to be the case. I notice that the Freescale LVDS1 screen is specifically mentioned as supported but am not finding mention of the Hannstar. What SD image should I use or what configuration is best for me to get this combination of components working?



    • ericn September 19, 2013 5:26 pm #

      Hi Chris,

      For all practical purposes (Nit6X_10.1Hannstar == Freescale 10.1″ Hannstar == Freescale LVDS1). Only the plexiglass stand should be different.

      All of our current SD card images, and U-Boot should detect the panel if connected at boot time.

      Are you in a position to look at the output from U-boot on the serial console? You should see a message at boot time that says “detected Hannstar-XGA”.

      If not, please double-check the connection on the back of the panel. That one in particular has a habit of coming loose.

  21. Chris September 23, 2013 5:14 am #

    Hi Eric:

    Thanks for the reply. I have tried two different boards with two different screens with the same result. Below is the console output from boot.

    N.B.: edited to remove some irrelevant output

    U-Boot 2009.08 (Aug 16 2012 - 10:06:42)
    CPU:   Freescale i.MX 6 family 0.0V at 792 MHz
    Loading file "/6q_bootscript" from mmc device 1:1 (xxb1)
    361 bytes read
    ## Executing script at 10008000
    Loading file "/boot/uImage" from mmc device 1:1 (xxb1)
    3627844 bytes read
    ## Booting kernel from Legacy Image at 10800000 ...
       Image Name:   Linux-3.0.15-ts-armv7l
       Image Type:   ARM Linux Kernel Image (uncompressed)
       Data Size:    3627780 Bytes =  3.5 MB
       Load Address: 10008000
       Entry Point:  10008000
       Verifying Checksum ... OK
       Loading Kernel Image ... OK
    Starting kernel ...
    Uncompressing Linux... done, booting the kernel.
    Linux version 3.0.15-ts-armv7l (fourier@fourier-desktop) (gcc version 4.6.3 (Timesys 20120813) ) #1 SMP PREEMPT Thu Aug 16 10:06:09 EDT 2012
    Kernel command line: console=ttymxc1,115200 video=mxcfb1:dev=ldb,LDBXGA,if=RGB666 root=/dev/mmcblk0p1 rootwait fixrtc video=mxcfb0:dev=hdmi,1280x720M@60,if=RGB24 video=mxcfb1:dev=ldb,LDBXGA, if=RGB666 root=/dev/mmcblk0p1 rootwait fixrtc
    mxc_sdc_fb mxc_sdc_fb.0: register mxc display driver hdmi
    mxc_hdmi mxc_hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1
    fbcvt: 1280x720@60: CVT Name - .921M9
    imx-ipuv3 imx-ipuv3.0: IPU DMFC DP HIGH RESOLUTION: 1(0,1), 5B(2~5), 5F(6,7)
    Console: switching to colour frame buffer device 160x45
    mxc_sdc_fb mxc_sdc_fb.1: register mxc display driver ldb
    mxc_ldb mxc_ldb: Input pixel format not valid use default RGB666
    _regulator_get: get() with no identifier
    mxc_sdc_fb mxc_sdc_fb.2: register mxc display driver ldb
    mxc_sdc_fb mxc_sdc_fb.3: register mxc display driver ldb
    mxc_sdc_fb mxc_sdc_fb.3: ipu1-di1 already in use
    mxc_sdc_fb: probe of mxc_sdc_fb.3 failed with error -16
    imx-sdma imx-sdma: loaded firmware 1.1
    imx-sdma imx-sdma: initialized
    Serial: IMX driver
    imx-uart.0: ttymxc0 at MMIO 0x2020000 (irq = 58) is a IMX
    imx-uart.1: ttymxc1 at MMIO 0x21e8000 (irq = 59) is a IMX
    console [ttymxc1] enabled, bootconsole disabled
    console [ttymxc1] enabled, bootconsole disabled
    loop: module loaded
    Freeing init memory: 208K
    init started: BusyBox v1.20.2 (2012-08-16 10:09:55 EDT)
    Thermal: fuse data 0x58c4ef7d
    Setting hotplug handler: [ OK ]
    Creating device files: Auto-mount of [/media/mmcblk0p1] successful
    [ OK ]
    modprobe: module ft5x06_ts not found in modules.dep
    modprobe: module egalax_ts not found in modules.dep
    modprobe: module tsc2004 not found in modules.dep
    Starting system logging.
    Configuring network interfaces: done
    Starting dropbear sshd: OK
    Finding touchscreensh: 1000003: unknown operand
     using legacy method: /dev/event1 [ OK ]
    Finding mousesh: 1000003: unknown operand
    Framebuffer fb0
    Resolution 1280 720
    Screen resolution: 1280 x 720
    HDMI display
    Search for input device Acer T230H
    Mouse device is Auto
    Starting demo...
    Starting demo...
    BusyBox v1.20.2 (2012-08-16 10:09:55 EDT) built-in shell (ash)
    Enter 'help' for a list of built-in commands.
    • ericn September 23, 2013 7:34 am #

      Hi Chris,

      The primary problem seems to be that LDBXGA should be LDB-XGA.

      That said, you should also update your U-Boot and kernel when you have a chance. In the process, you’ll get U-Boot display support and auto-configuration in the boot script.

      • Chris September 25, 2013 10:19 am #

        Hi Eric:

        Thanks for your help. I now have the screen working! Now, it seems touch is not working. I am now using unnamed proprietary OS :-) that is driving the display just fine. I run a command to see touch metrics like the following.

        # cat /dev/screen/0/dev-0
        vendor = egalax
        product = (unknown)
        id string = egalax-0
        event type = SCREEN_EVENT_MTOUCH
        owner pid = (none)
        focus = dpy-1
        button count = 0
        buttons = 0x0
        transform = [[1 0 0],[0 1 0],[0 0 1]]
        power mode = SCREEN_POWER_MODE_ON
        reports = (none) = 0 = 0 = 0 = 0

        Per the vendor rep, I should see the metrics increasing as I touch the screen. The metrics never change. I have several boards, several cables and several screens. They all have the same problem. Do you have any tips for troubleshooting the touch function?



        • ericn September 25, 2013 11:18 am #

          Hi Chris,

          I certainly can’t comment on the un-named proprietary O/S or the tool above, but in general, the flow of the device driver is pretty simple:

          • Catch the touch-screen interrupt
          • Read packets over the I2C device until idle
          • Rinse and repeat

          Do you know if you’re catching interrupts from the device? The pad should be configured with an internal pull up and is active low.

  22. cladden October 2, 2013 6:27 am #

    Hi ericn,

    Our 480×800 18-bit RGB LCD renders wrong, but HDMI always renders correctly. We only want LCD to work, HDMI is not needed.

    We’ve tried many combinations of if=RGBxx and fbpix=RGBxx, but it still looks like the stride is off.

    What could cause this pattern?

    LCD RGB w/bad output:

    HDMI and the source image:

    Here’s the kernel command line:
    setenv bootargs $bootargs video=mxcfb0:dev=lcd,CLAA-WVGA,if=RGB666,fbpix=RGB32 video=mxcfb1:off video=mxcfb2:off
    setenv fbcon “fbcon=10M”;

    • ericn October 2, 2013 8:57 am #

      Hi Christopher,

      If your panel has significantly different timings from the CLAA-WVGA default, you’ll need to create a new entry for it to match the data sheet in two places:

      You’ll also need to edit the boot script to produce the name of your display instead of CLAA-WVGA.

      • Florian October 14, 2013 4:56 am #

        Hi Eric,

        I would like to do the mentioned steps (adjusting the driver settings in the mentioned github-files) with buildroot. Is this possible?

        Best regards

  23. cladden October 2, 2013 6:30 am #

    Sorry for the BAD URL.

    Here is HDMI and the source image:

  24. Mario October 24, 2013 7:26 am #


    we purchased the Nit6X_1024x600 display ( including cable.
    We use the Nitrogen6X board and want to adjust the brightness and contrast of the display.

    The brightness can be changed via sysfs (sys/class/backlight/pwm-backlight.3/brightness, range 0-256)
    But ‘0’ means not that display backlight is switched off.
    How can I achieve that the brightness continuously decreases until the display backlight is off?

    And how can the contrast be changed?
    The SABRE Lite schematics shows a DISP0_CONTRAST pin on LVDS0 20-pin connector (J6).
    The data sheet of the display shows a 40-pin connector. But no CONTRAST pin.
    How can the DISP0_CONTRAST pin be used?

    Thanks in advance


    • ericn October 24, 2013 7:35 am #

      Hi Mario,

      I’ll check into the backlight question.

      The DISP0_CONTRAST pin is kind of a placeholder for future use.

      As you noted, there isn’t such a pin on this display, and that’s typical.
      I think we’ve only encountered one display that needed an extra signal
      for that.

      • Ben November 5, 2013 4:02 pm #

        Hi Eric,

        I have two panels connected, both 1280×800, one is on the LVDS interface and one on HDMI. Both are on IPU0, LDB on disp_id=0 and HDMI disp_id=1. They work fine independently. But I’d like to be able to setup a mirror configuration, where HDMI displays the same content as LVDS connected display. Here is my config:

        console=ttymxc0,115200n8 video=mxcfb1:dev=hdmi,LDB-WXGA,if=RGB24 ldb=dul0 fbmem=24M enable_wait_mode=off

        Any ideas? Thanks,


        • ericn November 5, 2013 4:19 pm #

          Hi Ben,

          I’m not sure if/how this can be expressed in the kernel command-line, but you can certainly accomplish this by forcibly enabling the LVDS transmitter. If you pay attention to the LVDS display in U-Boot, you’ll see that we do this more or less inadvertently.

    • ericn November 2, 2013 8:58 am #

      Hi Mario,

      We checked into the backlight and it isn’t possible to turn it completely off without work to the daughter board. It’s hard-wired to deliver a small amount of current even when the PWM is completely off.

      We commonly do this for early-development boards so we see something displayed even before the software is fully baked, then tweak for production use. Unfortunately, the 1024×600 hasn’t (yet) been tweaked.

      • Mario November 4, 2013 4:13 am #

        Hi Eric,

        Thank you for checking the backlight question and your answer.

      • Tyler S July 3, 2014 9:12 am #

        Eric, do you know how to prevent the kernel from suspending the PWM backlight, or how to recover? It appears that this power management is the cause of our display problem.

        • ericn July 6, 2014 8:02 am #

          Hi Tyler,

          Which O/S build are you using?

          • tsheffield July 8, 2014 10:38 am

            Turned out to be a simple fix:
            set consoleblank=0 in Uboot bootargs. Losing the PWM was due to a frame buffer callback that checks the “screen saver” blanking status and kills the backlight if the screen is told to shut off.

  25. Andrey December 6, 2013 12:36 am #

    Dear Erich,

    we bought your products and have some questions to you:


    Defect description

    In debug set SabreLite (Boundary Devices) was discovered the following defect: when setting touch-screen display (N1T6X 1024×600) using LVDS connector to panel BD-SL-i.MX6 the picture on screen disappears in a few minutes, then appear color vertical lines. Thereby touch screen responds on touch, while brightness of the backdrop changes. When connecting the screen to HDMI output, the picture is displayed.

    Could you comment on the cause of the defect?

    How to solve this problem?

  26. digbyt January 27, 2014 3:44 pm #

    Hi Eric,

    I am trying to work out the mysteries of getting a LVDS display working with my iMX6 Saber Lite. I am close, but the resolution is a bit out.

    The display I am trying to use is:

    It is a 9.7″ display with 1024×768 pixel resolution.

    I tried it with the Ubunto 12.04 system (dist-upgrade’d from oneiric-imx6-20130307.tar.gz), and the display was recognized and came up perfectly – nice and clear. Except that the X server indicated a resolution of 1280×800 and I was missing the right hand and bottom parts of the desktop…

    I installed fbset and it showed me:
    mode “1280×800-60″
    # D: 71.098 MHz, H: 49.374 kHz, V: 59.993 Hz
    geometry 1280 800 1280 800 16
    timings 14065 40 40 10 3 80 10
    rgba 5/11,6/5,5/0,0/0

    I am not sure where it got that from…. My kernel command line is
    Kernel command line: enable_wait_mode=off video=mxcfb0:off video=mxcfb1:off vide
    o=mxcfb2:off console=ttymxc1,115200 vmalloc=400M consoleblank=0 rootwait root=/d

    and llater in the boot messages I get
    mxc_sdc_fb mxc_sdc_fb.3: register mxc display driver ldb

    I tried simple mindedly creating a new mode in /etc/fb.modes as follows:
    mode “1024×768-76″
    # D: 71.098 MHz, H: 49.374 kHz, V: 59.993 Hz
    # geometry 1280 768 1280 768 16
    geometry 1024 768 1024 768 16
    timings 14065 40 40 10 3 80 10
    rgba 5/11,6/5,5/0,0/0

    Ie just took the default modes and changed 1280×800 to 1024×768. Then did:
    /etc/init.d/lightdm stop
    fbset 1024×768-76
    /etc/init.d/lightdm start

    That produces a display which looks right, but I don’t know how (or if it is important) to determine what the optimal timings are. The documentation on this display seems rather superficial:

    Any suggestions on how best to make the system boot with correct display settings?


    • ericn January 27, 2014 8:14 pm #

      Hi Digby,

      What you need to figure out first is how to get the kernel command-line to have a clause that says video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666.

      We do this by default when using our 10.1″ 1024×768 display by detecting the I2C touch controller as shown on line 14 of our stock 6x_bootscript. You can probably just remove the test (and the corresponding else clause) and use our on-line boot script compiler to generate a binary (file 6x_bootscript).

  27. rob mcpherson January 27, 2014 4:21 pm #


    I placed a setenv bootargs: statement at the end of 6x_bootscript_android.txt configuring the screen, in the bootable/bootloader/…/nitrogen6x folder. After compiling I looked at the bootscript in the out/…/boot folder, and the change wasn’t there. Is that not where I’m supposed to make changes?


    • ericn January 27, 2014 4:53 pm #

      Hi Rob,

      Sorry for the dangling pointer. The file here uses the boot script source inside device/boundary/.

      We switched to using this when we realized that different versions of Android have different needs (i.e. new flags were added when we switched from ICS to JB), so using the U-Boot tree no longer made sense.

  28. digbyt January 28, 2014 3:14 pm #

    Hi Eric,

    Thank you for that explanation. I did as you suggest, and now it works perfectly.

    Where I went wrong was assuming that because the panel came up when no HDMI display was connected, it must have been recognized by the start script. I was puzzled by why the kernel seemed to use mxc_sdc_fb.3.

    Now I see the penguins when booting, and the panel has the correct resolution. But I am still a little puzzled at not seeing the command line parameters from the script in the dmesg output:

    Kernel command line: enable_wait_mode=off video=mxcfb1:off video=mxcfb2:off fbmem=10M consol
    e=ttymxc1,19200 vmalloc=400M consoleblank=0 rootwait root=/dev/mmcblk0p1

    I assume that with a hdmi display attached, I will have two frame buffers, with the panel available for application use.

    Your mention of the script compiler reminded me of one other thing that has been eluding me – I havn’t found any documentation on the header format for the 6x_bootfile format, or clues as to offline methods of creating one. Unfortunately I am stuck behind a quite aggressive firewall which doesn’t allow anything other than Windows PCs to access the Internet, and even that isnt always available. Is there an alternative way of doing it, either with an existing command, or a spec from which to write something.

    I have been using a simple script to automatically extract the text from my bootfiles:
    dd if=/6x_bootscript bs=1 skip=72
    To extract the text from my bootfiles. But automating the other direction has eluded me.


    • ericn January 28, 2014 3:20 pm #

      Hi Digby,

      Check out this comment for details of how to run mkimage. It’s arcane but there are only two variables (input & output files).

      Also check out this comment for how you can add an alias into .bashrc and make things even simpler.

  29. digbyt January 29, 2014 12:58 am #

    Ah, excellent. Thanks again Eric!

  30. David W February 26, 2014 1:28 pm #

    I’m debugging a problem where an image displays correctly on an 800 x 480 display in U-Boot, but in Linux it’s too small. I’d like to copy the U-Boot framebuffer to a file and then write that file into the Linux framebuffer. Is there any way to do that?

    • ericn February 26, 2014 1:37 pm #

      Maybe, but there’s no easy way.

      There are two primary issues:
      1. The frame buffer is malloc’d in U-Boot and isn’t stored such that the bdinfo command will show you where. You’d need to instrument the code to figure out where it it, and
      2. U-Boot isn’t particularly adept at writing files…

      You can be 100% certain that U-Boot takes each pixel directly into the frame buffer, so you should be able to do the same by converting the image into a .565 file and using ‘dd’ under Linux to write it to the frame-buffer there (dd certainly doesn’t know about scaling).

      There are some tools around for Android to convert images to .565 files because that’s what the animated Android logo code uses.

      • David W February 26, 2014 6:34 pm #

        Thanks. I used ImageMagick to convert the bmp file to a png file, then used dd to load it into the Linux framebuffer. I got a rectangle of colored dots but I was able to see that I still had the same problem. When I increased the size of the image, it increased vertically but not horizontally. Next I’ll capture an image from the Linux framebuffer and modify the U-Boot bmp display code to just copy an image into the framebuffer.

  31. FilterPunk March 26, 2014 11:04 am #

    I am using a G150XG01V2 (data sheet LVDS Display. I configured u-boot as follows:
    setenv bootargs mxcfb0:dev=ldb,1024x768M@60,if=RGB24
    U-Boot text is displayed (almost) correct. I have to problems:
    1.) The color of the U-Boot Text is not white (rather reddish-white or light-purple).
    2.) When I boot yocto-image (kernel 3.10.17-beta) which is working when using hdmi the display
    turns and stays black. I did not pass any kernel flags as I do not know any ;-)

    • ericn March 26, 2014 11:13 am #

      To configure U-Boot, you’ll want to use the Hannstar-XGA setting:

      U-Boot > setenv panel "Hannstar-XGA"
      U-Boot > saveenv && reset

      The 3.10.17-beta Yocto seems to have issues with all LCDs that require xrandr to fix. Check out this comment for details.

      • FilterPunk March 27, 2014 10:10 am #

        Thanks Eric,
        I followed your advice and set Hannstar as panel.
        Don’t know if that what made the change, but the U-Boot output is now white – great!

        But the monitor still turns and stays black after U-Boot and entering
        “DISPLAY=:0 xrandr –fb 1024×768″ returns “Can’t open display :0″.
        Also entering “ls: /dev/fb*” returns “No such file or directory”.

        I have tried with yocto 3.10.17-beta as well as with a compiled version 3.0.35-4.1.0+yocto+g5809938.

        The output on serial console is:

        ## Executing script at 10008000
        —— no HDMI monitor
        Setting bus to 2
        Valid chip addresses:
        —— no Freescale display
        Valid chip addresses:
        —— no 1024×600 display
        Valid chip addresses:
        —— no 800×480 display
        reading /imx6q-sabrelite.dtb
        ** Unable to read file /imx6q-sabrelite.dtb **
        only CEA modes allowed on HDMI port
        reading /uImage

        Error opening /dev/fb0: No such file or directory

        Do not know how to proceed.
        I see that in 6x_bootscript-rootinp2.txt from ( the Hannstar is not handled.
        And tried to figure out why “imx6q-sabrelite.dtb” was not build – using “imx6q-sabrelite.dtb”
        from other builds did not work.
        But my guesswork might not relate to the problem.

  32. Robert April 23, 2014 5:54 am #

    Hi everyone,

    I’m trying to connect SABRE Lite board to Chimei Innolux panel (model: V390HJ1-LE6) on LVDS connector. My problem is that SABRE board has 20 pin LVDS connector and panel has 51 pin connector. Here is a pinout from Sabre: (on page 6), and here is from panel: (on page 19).

    First, is this even possible? Can SABRE be connected to that panel? And, if it can be, what pin on SABRE do I need connect to pin on panel? Because, as it can be seen from pinouts, panels LVDS connector has, e. g. more GND pins than SABRE board. Do I just connect pins that match and extra pins left unconnected?

    Thanks in advance,


  33. jackson312 May 12, 2014 5:25 pm #

    On a sabresd platform, I am trying to enable the LCD (RGB) display and have it mirror what is being displayed on the HDMI display. I changed the HDMI to use disp_id 1 since the LCD needs to use 0:

    1531 static struct fsl_mxc_hdmi_core_platform_data hdmi_core_data = {
    1532 .ipu_id = 0,
    1533 .disp_id = 1,
    1534 };
    1536 static struct fsl_mxc_lcd_platform_data lcdif_data = {
    1537 .ipu_id = 0,
    1538 .disp_id = 0,
    1539 .default_ifmt = IPU_PIX_FMT_RGB565,
    1540 };

    I left the mux setting the way they were in the board-mx6q_sabresd.h files since they already had the LCD muxed to be on IPU0 and using DI0. Here are the uboot args I am passing in:

    setenv bootargs console=ttymxc4,115200 rdinit=/linuxrc enable_wait_mode=off verbose video=mcxfb0:dev=lcd,1280x1024M@60,if=RGB24 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24

    I assigned both the LCD and the HDMI to mcxfb0 since we just want the LCD to mirror what is on the HDMI. The resolution of the HDMI is set to 1280×1024@60 when our app starts, so it is only at the higher resolution during bootup.

    We have the RBG interface hooked into an Analog Devices “ADV7511 Low-Power HDMI 1.4 Compatible Transmitter with Audio Return Channel” We have used this part with another Freescale chip (MPC) and it works fine.

    Once the AD transceiver is enabled by the app, there is no signal. Is what I am trying to do possible? Is there something I missed?



    • ericn May 12, 2014 5:52 pm #

      Hi Jackson,

      I think you’re probably headed in the wrong direction. If you want things to be truly mirrored (with one frame-buffer), I think you want to map HDMI to ipu0:di0 and only pass in the video=mxcfb0:dev=hdmi parameter.

      Because the pin-muxing in the 3.0.35 kernels happens separately from activation of the device, this should produce signals on the lcdif interface.

  34. jackson312 May 12, 2014 5:59 pm #

    Hi Eric,

    So I put both HDMI and the lcdif on DI0? in the board-mx6q_sabresd.c ? I did no know you could do that.

    I’ll give that at try and remove the “video=mcxfb0:dev=lcd,1280x1024M@60,if=RGB24″ from the uboot args.



  35. jackson312 May 12, 2014 7:35 pm #


    Unfortunately that did not work, I am still not getting a signal. I put both the HDMI and the LCD interface on IPU0 and DI0:

    1531 static struct fsl_mxc_hdmi_core_platform_data hdmi_core_data = {
    1532 .ipu_id = 0,
    1533 .disp_id = 0,
    1534 };
    1536 static struct fsl_mxc_lcd_platform_data lcdif_data = {
    1537 .ipu_id = 0,
    1538 .disp_id = 0,
    1539 .default_ifmt = IPU_PIX_FMT_RGB565,

    I took the LCD video statement out of the uboot args:

    setenv bootargs console=ttymxc4,115200 rdinit=/linuxrc enable_wait_mode=off verbose video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24

    The pins DI0 and DISP0_DAT pins are already muxed in the header file:

    178 /* DISPLAY */
    180 MX6Q_PAD_DI0_PIN15__IPU1_DI0_PIN15, /* DE */
    181 MX6Q_PAD_DI0_PIN2__IPU1_DI0_PIN2, /* HSync */
    182 MX6Q_PAD_DI0_PIN3__IPU1_DI0_PIN3, /* VSync */
    183 MX6Q_PAD_DI0_PIN4__IPU1_DI0_PIN4, /* Contrast */
    184 MX6Q_PAD_DISP0_DAT0__IPU1_DISP0_DAT_0,
    185 MX6Q_PAD_DISP0_DAT1__IPU1_DISP0_DAT_1,
    186 MX6Q_PAD_DISP0_DAT2__IPU1_DISP0_DAT_2,
    187 MX6Q_PAD_DISP0_DAT3__IPU1_DISP0_DAT_3,
    188 MX6Q_PAD_DISP0_DAT4__IPU1_DISP0_DAT_4,
    189 MX6Q_PAD_DISP0_DAT5__IPU1_DISP0_DAT_5,
    190 MX6Q_PAD_DISP0_DAT6__IPU1_DISP0_DAT_6,
    191 MX6Q_PAD_DISP0_DAT7__IPU1_DISP0_DAT_7,
    192 MX6Q_PAD_DISP0_DAT8__IPU1_DISP0_DAT_8,
    193 MX6Q_PAD_DISP0_DAT9__IPU1_DISP0_DAT_9,
    194 MX6Q_PAD_DISP0_DAT10__IPU1_DISP0_DAT_10,
    195 MX6Q_PAD_DISP0_DAT11__IPU1_DISP0_DAT_11,
    196 MX6Q_PAD_DISP0_DAT12__IPU1_DISP0_DAT_12,
    197 MX6Q_PAD_DISP0_DAT13__IPU1_DISP0_DAT_13,
    198 MX6Q_PAD_DISP0_DAT14__IPU1_DISP0_DAT_14,
    199 MX6Q_PAD_DISP0_DAT15__IPU1_DISP0_DAT_15,
    200 MX6Q_PAD_DISP0_DAT16__IPU1_DISP0_DAT_16,
    201 MX6Q_PAD_DISP0_DAT17__IPU1_DISP0_DAT_17,
    202 MX6Q_PAD_DISP0_DAT18__IPU1_DISP0_DAT_18,
    203 MX6Q_PAD_DISP0_DAT19__IPU1_DISP0_DAT_19,
    204 MX6Q_PAD_DISP0_DAT20__IPU1_DISP0_DAT_20,
    205 MX6Q_PAD_DISP0_DAT21__IPU1_DISP0_DAT_21,
    206 MX6Q_PAD_DISP0_DAT22__IPU1_DISP0_DAT_22,
    207 MX6Q_PAD_DISP0_DAT23__IPU1_DISP0_DAT_23,

    Is a single IPU capable of driving two displays at 1280×1024 60Mhz? On a freescale sheet it says when you are driving one display at SXGA, you can run in Full up to WXGA (1366×768), or partial (reduced blanking) for WSXGA+ and HDTV.

    This is the fb.modes file we are using:

    19 mode “1280×1024 60Hz 24bit”
    20 # D: 107.99 MHz, H: 64.281 KHz, V: 60.08 Hz
    21 geometry 1280 1024 1280 5120 24
    22 timings 9260 128 128 40 2 144 4
    23 hsync high
    24 vsync high
    25 endmode
    27 mode “800×600 59Hz 24bit”
    28 # D: 41.38 MHz, H: 37.754 kHz, V: 59.93 Hz
    29 geometry 800 600 1280 5120 24
    30 timings 22727 128 96 24 2 144 4
    31 hsync high
    32 vsync high
    33 endmode
    35 mode “1920×1080 50Hz 16bit”
    36 # D: 148.500 MHz, H: 56.250 kHz, V: 50.000 Hz
    37 geometry 1920 1080 1920 1080 16
    38 timings 6734 148 528 36 4 44 5
    39 hsync high
    40 vsync high
    41 rgba 5/11,6/5,5/0,0/0
    42 endmode

    Is there anything else that I need to do?



    • ericn May 13, 2014 7:12 am #

      Hi Jackson,

      AFAIK, you should be getting signals on the LCDIF with this configuration.

      You should probably post the question on i.MX Community to see if others have some suggestions.

  36. jackson312 May 14, 2014 7:55 pm #


    The hardware guys probed the clock for the LCD interface. If I can make it match the HDMI clock, then the mirroring should work. Right now the clock is running at about 85hz, it needs to run at Pixclock = 9260 = 107.99 MHz, or the whole mode string “60, 1280, 1024, 9260, 128, 128, 2, 40, 144, 4″

    What is the easiest way to set these. I’ve been fighting drivers all day long. The mxc_elcdif_fb driver is registered, but never probed (I have the modes hard coded (for now) in the mxc_elcdif_fb_set_par function, but since the module is probed, nothing ever gets set.

    I also have the mxc_lcdif.c’s init method to set the same mode, but that driver does not really change the video mode.

    I figure it might just be easier to set the timings manually. We are doing the mirroring for EMC testing just to get the display up. In the future we will set up the LCD with fb2 and fb3 and draw on that monitor.



  37. jackson312 May 19, 2014 11:25 am #

    I put the HDMI interface on IPU2 and left the LCD on IPU1. Now I am not getting anything on ipu1_pixel_clk_0:

    ipu1_di_clk_0 pll5_video_main_clk 0 99000000
    ipu1_di_clk_1 pll5_video_main_clk 0 148500000
    ipu1_pixel_clk_1 ipu1_di_clk_1 1 108307692
    ipu1_clk mmdc_ch0_axi_clk 2 264000000
    perfmon1_clk ipu1_clk 0 264000000
    ipu1_pixel_clk_0 ipu1_clk 0 0

    1447 static struct ipuv3_fb_platform_data sabresd_fb_data[] = {
    1448 { /*fb0*/
    1449 .disp_dev = “ldb”,
    1450 .interface_pix_fmt = IPU_PIX_FMT_RGB666,
    1451 .mode_str = “LDB-XGA”,
    1452 .default_bpp = 16,
    1453 .int_clk = false,
    1454 .late_init = false,
    1455 }, {
    1456 .disp_dev = “ldb”,
    1457 .interface_pix_fmt = IPU_PIX_FMT_RGB666,
    1458 .mode_str = “LDB-XGA”,
    1459 .default_bpp = 16,
    1460 .int_clk = false,
    1461 }, {
    1462 .disp_dev = “lcd”,
    1463 .interface_pix_fmt = IPU_PIX_FMT_RGB24,
    1464 .mode_str = “SEIKO-WVGA”,
    1465 .default_bpp = 24,
    1466 .int_clk = false,
    1467 .late_init = false,
    1468 }, {
    1469 .disp_dev = “ldb”,
    1470 .interface_pix_fmt = IPU_PIX_FMT_RGB666,
    1471 .mode_str = “LDB-VGA”,
    1472 .default_bpp = 16,
    1473 .int_clk = false,
    1474 .late_init = false,
    1475 },
    1476 };

    I am using these bootargs:

    setenv bootargs console=ttymxc4,115200 rdinit=/linuxrc enable_wait_mode=off verbose video=mxcfb1:dev=lcd,SEIKO-WVGA,if=RGB24 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24

    The HDMI is working fine and is using fb0 and fb1. Is there something else I need to do? I’ve made sure all the options are configured in the kernel.

  38. Tyler S September 10, 2014 1:51 pm #

    Hi all,
    Looking for thoughts on a VERY strange problem we are having. We have a 512×128 display that is working fine with our Nitrogen board now that we have all the driver settings/margins, etc correct. However, the exact same display with the exact same code and driver settings gives a different result on a Nitrogen Lite board.

    We have mini adapter interface boards that allow the use of the same display on the two boards, but with the Lite the image is WRAPPED around. The image is drawn 1/4-inch down from the top of the screen, and the bottom of the image wraps around into that top 1/4-inch space. Horizontal is fine.

    No amount of messing with the drivers via the fbset tool helps, and we have verified HW and scoped things out several times.

    What’s really bizarre is that I can’t find a report of this ever happening anywhere. Has anyone seen anything like this before? Is there anything with driver settings that could explain it? Keep in mind, the driver settings have already been proven correct for this display with the Nitrogen board.

  39. AndreasD October 21, 2014 8:55 pm #

    Hi Eric, regarding the comment on your original post “There is a known bug in the HDMI driver which causes display corruption if an HDMI monitor is either disconnected and reconnected or powered down and back up during operation.”. I can clearly witness this behavior. It’s not a big deal for what I’m working on right now but I wonder if you have any more info where to dig to get this fixed. I just need a starting point. Thanks!

    • ericn October 22, 2014 7:05 am #

      Hello Andreas,

      That comment is very old, and should no longer be an issue.

      What kernel version and distribution are you running?

Leave a Reply