HDMI Display goes black after uboot

Hello,

We are debugging a display with 1200x1920 resolution screen.
Uboot message display fine, however, as soon as a fb0 mode is set, the screen goes black

12.595285] mxc_sdc_fb fb@1: 1200x1920 h_sync,r,l: 8,120,72 v_sync,l,u: 23,63,39 pixclock=120004000 Hz

Any idea why this happen and how to fix it?

OS: Toradex reference multimedia image.
Hardware: colibri IMX6DL with colibri evaluation board

Thanks!
Warren

Hi @warrenlee,

Could you please share more information about how have you done your configuration?
You mentioned fb0, but you shared a print from fb1:

Also, I think this article can help you with that: Display Output, Resolution and Timings (Linux) | Toradex Developer Center

Best Regards,
Hiago.

Hi thanks for the reply.

The display we are using is a 1200x1920 portrait 7inch monitor. On top of the reference images, the only changes we have done is to change device tree overlay to the

fdt_overlays=colibri-imx6_hdmi_overlay.dtbo

When booting up the uboot message is correctly displayed, as soon as it hit this line the screen goes blank. mxc_sdc_fb fb@1: 1200x1920 h_sync,r,l: 8,120,72 v_sync,l,u: 23,63,39 pixclock=120004000 Hz. Not sure why it using the fb1.

However, when query the modes on the fb0, (cat /sys/class/graphics/fb0/modes), it listed two display as below, so I would think the 1200x1920 is supported.
D:1200x1920p-41
V:640x480p-60

We have tried manually set the mode by using
echo V:640x480p-60 > fb0/mode, it display correct content but only a 640x480 area is occupied. No surprise here. But when we set back to D:1200x1920 it goes blank with only backlight on it.

Full dmesg log is attached here, let me know if more information that could help to troubleshoot this issue.
dmesg.txt (22.7 KB)

I have tried the setting video mode as following
setenv vidargs video=mxcfb0:dev=hdmi,1200x1920@60. It always fall back to 640x480

Here is something that may either be a message from Captain Obvious or fresh cheese from the stupid factory.

D:1200x1920p-41
V:640x480p-60

Isn’t the number after the “p” the supported refresh rate?

If so, you aren’t ever getting 60 to work at 1200x1920

I’m not a hardware guy so this may be speaking out my lower mouth, but when you look here:

Your board has both a VGA V: port and a DVI D: connector.

Frame buffer is a Linux specific thing. I’m not a driver guy or a kernel mod guy, but any frame buffer device can be mapped by any driver. Typically when you have “mirrored” displays they get mapped to the same frame buffer.

Just trying to help. Please take note of everything I’m not when evaluating the content.

Also please try 1200x1920 with a refresh of 41

Hi @warrenlee,

Have you also changed the device tree file or have you just added to “fdt_overlays”?

This makes sense because your display is connected to fb0, and as soon as it hits this line, it changes to fb1.
From your dmesg file, I could see these lines (I’ve searched for “fb” keyword):

[    0.196159] mxc_sdc_fb fb@0: NO mxc display driver found!
[    0.196304] mxc_hdmi 20e0000.hdmi_video: Detected HDMI controller 0x13:0x1a:0xa0:0xc1
[    0.196345] fbcvt: 1920x1080@60: CVT Name - 2.073M9
[    0.196470] mxc_sdc_fb fb@1: registered mxc display driver hdmi
[    0.209102] mxc_sdc_fb fb@1: 1920x1080 h_sync,r,l: 44,88,148  v_sync,l,u: 5,4,36 pixclock=148500000 Hz
[    0.233566] imx-ipuv3 2400000.ipu: IPU DMFC DP HIGH RESOLUTION: 1(0,1), 5B(2~5), 5F(6,7)
[    0.270403] mxc_sdc_fb fb@1: 1920x1080 h_sync,r,l: 44,88,148  v_sync,l,u: 5,4,36 pixclock=148500000 Hz
[    0.337962] Console: switching to colour frame buffer device 240x67
[    0.375414] mxc_sdc_fb fb@1: 1200x1920 h_sync,r,l: 8,120,72  v_sync,l,u: 23,63,39 pixclock=120004000 Hz
[    0.498371] mxc_sdc_fb fb@1: 1200x1920 h_sync,r,l: 8,120,72  v_sync,l,u: 23,63,39 pixclock=120004000 Hz
[   12.595274] mxc_sdc_fb fb@1: 1200x1920 h_sync,r,l: 8,120,72  v_sync,l,u: 23,63,39 pixclock=120004000 Hz

We can see that fb0 didn’t find your display, but fb1 apparently found it and set the HDMI driver. I’m not sure why this is happening, but I think a good test would be trying to send the image from fb1 to fb0 and check what will happen.
Have you done any other modifications to your image?

Meanwhile, I’ll do some tests here on my side to see if I find something useful.

Best Regards,
Hiago.

Thanks a lot for the support Hiago, we will try to send to fb1 to test if something comeup

Warren

Hi Hiago,

Other modification we have done is that we installed the dotnet layer on yocto. Could this possibly cause any issues to the framebuffer? We will try the default reference image from toradex to test if the problem still happens.

Thanks!
Warren

Hi @warrenlee,

Probably not, but you can test in our reference multimedia image to see if the problem still happens.

From our device tree, I could see that fb1 is used by HDMI. You’re connecting your display using HDMI, correct?

Best Regards,
Hiago.

Hello Hiago,

I want to update on this. We were able to get it working correctly now. It is strange since we fixed it by replacing a different HDMI Cable and now booting up and display screen properly. Dmesg still logged this message:

mxc_sdc_fb fb@1: 1200x1920 h_sync,r,l: 8,120,72 v_sync,l,u: 23,63,39 pixclock=120004000 Hz.

Neverthless it is good for now and thanks for all the help! It brings me another question that if there is any impact on the colibri hdmi adapter that could cause this?

Warren

Hi @warrenlee,

I’m glad you could solve your issue!

There is nothing that I am aware of. Since you changed the cable and it worked, a faulty cable or the flat cable not connected properly was probably causing this issue.

Feel free to ask me if you need anything else.

Best Regards,
Hiago.