5 inch hdmi display not working

[Ioan Bogdan Veringioiu]

Armbianmonitor:

https://paste.armbian.com/zodihaqiwi

Hello,

 

the latest armbian image (Bookworm_current_xfce) with kernel 6.6 has issues with the winstar tftp 5 inch hdmi display that I am using.

Bootloader (u-boot) is showing but after loading the  kernel message, screen goes blank.

 

The screen resolution is 800x480, in attach the pdf specs.

 

Info: the official asus image with kernel 4.4 works, but it is not an option for me as I don't want to use debian buster.

Please help.

Thank you very much.

Bogdan

WF50FSYFGDHNV.pdf

[jock]

@Ioan Bogdan Veringioiu hello, did you try any older image wth mainline kernel that was working for you, or just tried debian buster with kernel 6.6 and it just does not work?

HDMI compatibility is very hard to achieve, and fixing you problem may became very difficult.

[Ioan Bogdan Veringioiu]

Hi, thanks for answering.

 

What I tried:

- Official armbian image for tinker: Bookworm desktop xfce, kernel 6.6

https://dl.armbian.com/tinkerboard/Bookworm_current_xfce

This does not work. Bootloader shows, then kernel boots and screen goes blank. Backlight is on. Ssh works.

- Official asus image from here (based on Debian 10, kernel 4.4):

https://tinker-board.asus.com/download-list.html?product=tinker-board-r2

This works, but it is not an option for me as debian buster is too old.

 

Any ideas what I could try?

Thanks

[jock]

I may guess that the HDMI timings in the kernel driver for HDMI are not suitable for uncommon resolutions like 800x480 is. I borrowed the actual timing from LibreELEC project which, in turn, were elaborated from other informed persons, and those timing greatly improved compatibility among regular monitors and TVs around, but indeed they could have broken uncommon resolutions.

 

This is the patch which, among other things, modifies the existing HDMI timings. I could try to compile and image without that patch to see if works for you, but remember that you won't be able to upgrade the kernel, otherwise it would break again

[Ioan Bogdan Veringioiu]

I am also suspecting one of the applied patches, but don't know which.

I have today booted libreelec distro (kernel 6.6) and the display worked, so not sure what is causing the issue in armbian.

 

https://releases.libreelec.tv/LibreELEC-RK3288.arm-12.0.1-tinker.img.gz

 

 

[jock]

It could even be that I should re-align the libreelec patches in armbian... for some time those were not actively developed in the libreelec project, and thus I did some bare fixes to keep them compatible with newer kernels, but they could have been broken somewhere in the middle.

 

I will try to give a shot in the weekend, but I'm sorry I can't promise actual results

[Ioan Bogdan Veringioiu]

Thank you. If I can help in any way let me know.

[jock]

Here: https://users.armbian.com/jock/rk3288/

 

I repackaged the libreelec patches, there was a very small change in a device tree and I don't know if it could be of any importance.

 

You can try rockchip-6.6 and/or rockchip-6.11 debs for your setup.

You need to install linux-dtb and linux-image packages for sure, linux-headers is only needed if you have kernel modules built by yourself.

 

Also you may also want to try to force the HDMI resolution adding extraargs=video=HDMI-A-1:800x480@60D to /boot/armbianEnv.txt and see if you get a framebuffer

 

[Ioan Bogdan Veringioiu]

Hi,

 

thanks, I booted the kernel you build but no change.

 

However, using your advice  with the video kernel param, i got the following results:

 

1) First, without any intervention here's what Xorg says about the screen:

[    16.605] (II) modeset(0): Printing probed modes for output HDMI-1
[    16.605] (II) modeset(0): Modeline "800x480"x65.7   32.00  800 840 888 928  480 493 496 525 -hsync -vsync (34.5 kHz eP)
[    16.605] (II) modeset(0): Output HDMI-1 connected
[    16.605] (II) modeset(0): Using exact sizes for initial modes
[    16.605] (II) modeset(0): Output HDMI-1 using initial mode 800x480 +0+0

The EDID looks OK, the Modeline is read and applied (according to Xorg), but screen is black.

 

xrandr --verbose shows the following:

  800x480 (0x42) 32.000MHz -HSync -VSync *current +preferred
        h: width   800 start  840 end  888 total  928 skew    0 clock  34.48KHz
        v: height  480 start  493 end  496 total  525           clock  65.68Hz

 

2) Using video=HDMI-A-1:800x480@65D as kernel param, I indeed get a framebuffer, I see the kernel + systemd booting, all good. However, when Xorg starts, screen goes black. Note that I used 65 for refresh rate instead of 60 just to use what the EDID is delivering.

xrandr --verbose now shows:

  800x480 (0x42) 32.000MHz -HSync -VSync *current +preferred
        h: width   800 start  840 end  888 total  928 skew    0 clock  34.48KHz
        v: height  480 start  493 end  496 total  525           clock  65.68Hz
  800x480 (0x43) 32.691MHz -HSync +VSync
        h: width   800 start  824 end  904 total 1008 skew    0 clock  32.43KHz
        v: height  480 start  481 end  484 total  499           clock  64.99Hz

There is a second mode shown now.

 

3) If I force this new mode now, using the following xorg.conf

Section "Monitor" 
    Identifier "HDMI-1" 
    Modeline "800x480_65.0"   32.69  800 824 904 1008  480 481 484 499 -hsync +vsync 
    Option "PreferredMode" "800x480_65.0" 
EndSection

then Xorg is also working.

 

Now I see the following dmesg errors:

[   17.456578] rockchip_rk3066_pll_set_rate: Invalid rate : 32690000 for pll clk pll_npll

 

Waiting on your thoughts on this.

Thanks

[jock]

14 hours ago, Ioan Bogdan Veringioiu said:

[   17.456578] rockchip_rk3066_pll_set_rate: Invalid rate : 32690000 for pll clk pll_npll

Weird that 800x480@65Hz works despite the invalid rate warning, and 800x480@66Hz does not produce any warning but does not work at all.

By the way, the only "major" difference is the negative VSync for the native 800x480 mode.

 

You may want to compare those modelines against the kernel 4.4 to look for differences.

Perhaps there are some "restrictions" in the modeline on armbian kernel 6.6 that force the display with a vertical refresh rate (65.7 Hz) that is not supported by the display.

 

Did you try also to force display vertical refresh rate to 60Hz and 66Hz via kernel command line?

 

[Ioan Bogdan Veringioiu]

Hello,

 

I believe I found the problematic patch which is messing my display:

patch/kernel/archive/rockchip-6.6/patches.armbian/clk-rockchip-max-frac-divider.patch

This patch adds the code that generates this pll_set_rate error.

I have removed it from patches directory and rebuilt the kernel. The system booted fine (no video kernel param) and Xorg started fine (without extra modelines).

 

I will test this kernel with other displays I have around to make sure it works.

Do you know something about the patch above ?

Thanks

[jock]

8 hours ago, Ioan Bogdan Veringioiu said:

Do you know something about the patch above ?

I vaguely remember that it was inherited from somewhere when I merged rockchip 32 bit families (there was a separate family for rk322x).

It is actually an adaptation from a kernel submitted patch from a rockchip person: https://patchwork.kernel.org/project/linux-rockchip/patch/1569553244-3165-2-git-send-email-zhangqing@rock-chips.com/, but it actually never went into the mainline kernel.

[Ioan Bogdan Veringioiu]

Hi,

 

I can confirm that the mentioned patch is breaking another display i am using:

$ xrandr
Screen 0: minimum 320 x 200, current 640 x 480, maximum 4096 x 4096
HDMI-1 connected primary 640x480+0+0 (normal left inverted right x axis y axis) 400mm x 300mm
   640x480       60.05*   75.00    72.81    66.67    60.00    59.94  
   720x400       70.08

This is a LVDS panel using a LVDS to HDMI convertor.

 

I am seeing also the same kind of error:

[   28.408594] rockchip_rk3066_pll_set_rate: Invalid rate : 33290000 for pll clk pll_npll

 

Using the kernel built without clk-rockchip-max-frac-divider.patch makes the display work.

 

[jock]

@Ioan Bogdan Veringioiu thanks a lot for testing and finding this bug. Since that patch was more an inheritance rather than a real necessity, I will remove it or cut to the very minimal pieces needed soon.

 

Thanks again!

 

edit: Pull request opened: https://github.com/armbian/build/pull/7479

the patch will be removed soon from mainline.