DVI-I not working - Colibri iMX6DL on Iris Carrier Board

Because the topic changed completely I started a new question with my resent problem, getting a monitor to work with Colibri iMX6DL and Carrier Board Iris. You can find the related question following the below link.

https://www.toradex.com/community/questions/18974/toradexeasyinstaller-kernel-not-starting-on-iris-b.html?childToView=19003#answer-19003

After working the hole day on the issue, I am not a bit wiser.

To my hardware config:
The Colibri iMX6DL ist connected to a Carrier Board Iris via SO-DIMM and Colibri DVI/VGA FFC
connector. A Monitor ist pluged in via DVI to Display-port cable into the DVI-I interface(I tried with another DVI to DVI cable to another monitor and it did not work either).
The Iris Board is connected to the host system via USB and RS232. The ethernet-port is connected to a local LAN. At the USB-port I pluged in a USB-hub with a keyboard.

I am running the Colibri-iMX6_LXDE-Image 2.7b4 20171004 as distributed on the Toradex website. To use the ToradexEasyInstaller I had to connect with VNC-Viewer, because on the DVI-I was no output, either.

When I have read the Iris Datasheet, from my point of view it sounded like the DVI signal is passed throw from the FFC to the DVI-I interface. Therefore I have no idea where to start configureing the device to get a DVI output.

My second thought was to access the OS via VNC, but when I try on the default IP “192.168.11.1” I get the message “Connection rejected by the computer” (translated from german message!). So it looks like there is no VNC-server running or it is not accepting the connection. The usb0 interface on the device is up and configured with the default IP. It is also responding to a ping-request.

I would appreciate an answer either if there is something more to configure on the Hardware or the Software to get the DVI running, or if there is a way to access the device with VNC when the OS (Linux) is running.
If any more information is needed, please let me know, so I can provide the data.

After another turn of research I found the below linked question.

After checking the /sys/kernel/debug/clk/clk_summary I realized the same issue as in the coresponding answer. The clock for the video device is set wrong to 47,5 MHz.

    pll5_bypass_src                       1            1    24000000          0 0
       pll5                               1            1   759999984          0 0
          pll5_bypass                     1            1   759999984          0 0
             pll5_video                   1            1   759999984          0 0
                pll5_post_div             1            1   189999996          0 0
                   pll5_video_div           1            1    47499999          0 0
                      ipu2_di1_pre_sel           0            0    47499999          0 0
                         ipu2_di1_pre           0            0    23750000          0 0
                            ipu2_di1_sel           0            0    23750000          0 0
                               ipu2_di1           0            0    23750000          0 0
                      ipu2_di0_pre_sel           0            0    47499999          0 0
                         ipu2_di0_pre           0            0    15833333          0 0
                            ipu2_di0_sel           0            0    15833333          0 0
                               ipu2_di0           0            0    15833333          0 0
                      ipu1_di1_pre_sel           0            0    47499999          0 0
                         ipu1_di1_pre           0            0    15833333          0 0
                            ipu1_di1_sel           0            0    15833333          0 0
                               ipu1_di1           0            0    15833333          0 0
                      ipu1_di0_pre_sel           1            1    47499999          0 0
                         ipu1_di0_pre           1            1    23750000          0 0
                            ipu1_di0_sel           1            1    23750000          0 0
                               ipu1_di0           1            1    23750000          0 0
                                  ipu1_pclk0_sel           1            1    23750000          0 0
                                     ipu1_pclk0_div           1            1    23750000          0 0
                                        ipu1_pclk0           1            1    23750000          0 0   

Therefore rebuilding the kernel would probable solve the problem for linux.
But it is not working with WEC8 either. So could it be the same issue for both OS? And if so, is there a similar solution for WEC8?

Did you follow this step Iris Carrier Board - First steps to get it running during board setup? Check if FFC cable connected correctly.

Thanks for the response. I followed exactly these steps and I checked the FFC cable several times. Of course I cannot exclude the possibility of a broken cable, but the hole setup came right out of the box.

After some experimenting with the environment varible ‘vidargs’ in Uboot, I am pretty sure that the pixelclock is set properly.

I have no clue whats wrong with my setup. So perhaps there realy is something broken. Next week I hopefully will get some new and editional hardware. Then I will test the Colibri iMX6DL with the development board and see if it works properly.

If you got any other idea what to do, please let me know. Of course everyone else is welcome to give me a hint, too.

The easiest way to check if you DVI setup is OK - to load Toradex Easy Installer (Downloads & Installers | Toradex Developer Center). The HDMI output works out of the box. I did double check it right now.
To enable HDMI output for Linux - please set UBoot “vidargs” environment variable correctly -

setenv vidargs video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb1:off fbmem=8M
saveenv

Please see more details here - Display Output, Resolution and Timings (Linux) | Toradex Developer Center

Thanks again for your answer. Today I was finaly able do test the setup configuration with the eval-board. It turned out, that one of my monitors doesnot work with the DVI-I interface provided by the Iris carrier board. For my bad I obviously never tested the second one with the right config for vidargs.
Know I am trying to use 2 framebuffers. So first I configured the Uboot variable vidargs with the parameters set for the EDT-WVGA display (connected throw FFC) on framebuffer 0 and the framebuffer 1 for hdmi.

(setenv vidargs 'video=mxcfb0:dev=lcd,EDT-WVGA,if=RGB666 Video=mxcfb1:dev=hdmi,1920x1080M@60,if=RGB24 fbmem=32M')

This worked for the touch-display but not for the monitor, which is connected throw the Colibri HDMI Adapter V1.0.
I tried to change the parameters the other way round and no wonder the monitor worked, but the touch-display stayed black.

(`setenv vidargs 'video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb1:dev=lcd,EDT-WVGA,if=RGB666 fbmem=32M'`)

dmesg is telling me, that framebuffer 0 (fb@0) is set correctly to the specified values in mxcfb0 and that framebuffer 1 (fb@1) is set to the values of mxcfb1 from vidargs.

[    0.199996] fbcvt: 1920x1080@60: CVT Name - 2.073M9
[    0.200131] mxc_sdc_fb fb@0: registered mxc display driver hdmi
[    0.212806] mxc_sdc_fb fb@0: 1920x1080 h_sync,r,l: 44,88,148  v_sync,l,u: 5,4,36 pixclock=148500000 Hz
[    0.233077] imx-ipuv3 2400000.ipu: IPU DMFC DP HIGH RESOLUTION: 1(0,1), 5B(2~5), 5F(6,7)
[    0.266974] mxc_sdc_fb fb@0: 1920x1080 h_sync,r,l: 44,88,148  v_sync,l,u: 5,4,36 pixclock=148500000 Hz
[    0.304625] Console: switching to colour frame buffer device 240x67
[    0.339247] mxc_sdc_fb fb@1: registered mxc display driver lcd
[    0.342478] mxc_sdc_fb fb@1: 800x480 h_sync,r,l: 128,40,88  v_sync,l,u: 2,10,33 pixclock=33260000 Hz

For me this is a bit confusing, because when reading “Display Output, Resolution and Timings (Linux)” it said, that /dev/fb1 is a overlay of /dev/fb0.
If someone got a hint, where to look to configure both framebuffers right, please let me know.

Thanks again for your help.

Hi

Try

cat /dev/urandom > /dev/fb2

The i.MX6 Vivante Xdriver can only use one framebuffer. So in your setup mxcfb0 is displays X, the other framebuffer displays black content.

Note that mxcfb0 is represented by /dev/fb0 and /dev/fb1 while mxcfb1 is represented by /dev/fb2.

Max

Hi Max,

thank you for your quick answer.

Now that you mention it, I remember reading something about Vivante Xdriver only supporting one framebuffer. And I tried your suggestion and I got a colorful output on fb2.
I also read something about the open source driver which can handle both framebuffers at the same time, but I cannot remember on which page it was. When I found it, I will give it a try and switch drivers.

Thanks again

Christoph