Tinker Board HDMI resolutions do not all work

[Azq2]

Hi!

I connect my 1366x768 monitor to Tinkerboard, but resolution sets to 1280x720. 

 

$ xrandr
Screen 0: minimum 320 x 200, current 1280 x 720, maximum 8192 x 8192
HDMI-1 connected 1280x720+0+0 (normal left inverted right x axis y axis) 410mm x 230mm
1920x1080 60.00 +
1280x720 60.00*
720x480 60.00

 

Yes, i tried set timings manualy. I set native from edid:

Modeline "Mode 0" 85.50 1366 1436 1579 1792 768 771 774 798 +hsync +vsync

 

But after applying this modeline:

- monitor detects 1280x720 resolution instead of 1366x768

- crops image as 1024x768

- have many noises and waves on screen... very unstable image
(pixel clock 84.857 mhz, but expected 85.5 mhz)

 

I tried use modelines but result is one - not working.

 

Why it happens? Answer is simple: https://github.com/TinkerBoard/debian_kernel/blob/e57365482d2e2e5105d9d368eca432248fcf92a2/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#L2273

	/*
	 * Hdmi or DisplayPort request a Accurate clock.
	 */
	if (output_type == DRM_MODE_CONNECTOR_HDMIA ||
	    output_type == DRM_MODE_CONNECTOR_DisplayPort)
		if (clock != request_clock) // see this
			return MODE_CLOCK_RANGE;

 

Clock for HDMI must be set without any deviations. 

And this is the very reason why 1366x768 not listed in xrandr. 

 

But setting manual timings with xrandr omits this check. But not works too. Why? 

Here the answer was also simple. 

 

I added debug to hdmi_av_composer() for dump actual mpixelclock. 

And i set manual timings like this:

 

 

Debug for this timings:

[ 152.196219] hdisplay = 1366 pixel
[ 152.196224] vdisplay = 768 lines

// Front porch
[ 152.196231] h_de_hs = 70 pixel clks

// hsync len
[ 152.196236] hsync_len = 143 pixel clks

// back porch
[ 152.196226] hblank = 426 pixel - (143 + 70) = 213

// Front porch
[ 152.196234] v_de_vs = 3 lines

// vsync len
[ 152.196238] vsync_len = 3 lines

// back porch
[ 152.196229] vblank = 30 pixel - 6 = 24

// pixel clock
[ 152.196241] vmode->mpixelclock = 84857000 hz
[ 152.196243] vmode->mtmdsclock = 84857000 hz

And what do we see?

All is well, except pixel clock. I set 85.5 MHz, but driver set 84.857 MHz. WTF?

0.643 Mhz difference, Karl!

 

What does it mean? PLL can't calculate dividers for wanted DCLK frequency. 

 

Okay, after few day of research i randomly checked TinkerOS. And it works:
 

azq2@tinkerboard:~$ xrandr
Screen 0: minimum 320 x 200, current 1280 x 720, maximum 8192 x 8192
HDMI-1 connected 1280x720+0+0 (normal left inverted right x axis y axis) 410mm x 230mm
1366x768 59.79 +
1920x1080 60.00 59.94 
1152x864 75.00 
1280x720 60.00* 59.94 
1152x720 59.97 
1024x768 75.03 60.00 
832x624 74.55 
800x600 75.00 60.32 
720x480 60.00 59.94 
640x480 75.00 60.00 59.94 
720x400 70.08

O_O WTF???

This is a bug of Armbian maintainers...? (spoiler: It turned out that yes -_-)

 

I checked all patches that affect dw hdmi or VOP. 

And I found a problem. 

 

In commit 93ae28f78dce6c747f0616dced591af7edf31377 maintainer igorpecovnik upgrades kernel and for some strange reasons disables very important patch 01-linux-0005-dts.patch

But this patch contains important changes for HDMI:

 

+static struct rockchip_pll_rate_table rk3288_npll_rates[] = {
+	RK3066_PLL_RATE_NB(594000000, 1, 99, 4, 32),
+	RK3066_PLL_RATE_NB(585000000, 6, 585, 4, 32),
+	RK3066_PLL_RATE_NB(432000000, 3, 216, 4, 32),
+	RK3066_PLL_RATE_NB(426000000, 3, 213, 4, 32),
+	RK3066_PLL_RATE_NB(400000000, 1, 100, 6, 32),
+	RK3066_PLL_RATE_NB(342000000, 3, 171, 4, 32),
+	RK3066_PLL_RATE_NB(297000000, 2, 198, 8, 16),
+	RK3066_PLL_RATE_NB(270000000, 1, 135, 12, 32),
+	RK3066_PLL_RATE_NB(260000000, 1, 130, 12, 32),
+	RK3066_PLL_RATE_NB(148500000, 1, 99, 16, 32),
+	RK3066_PLL_RATE(148352000, 13, 1125, 14),
+	RK3066_PLL_RATE_NB(146250000, 6, 585, 16, 32),
+	RK3066_PLL_RATE_NB(108000000, 1, 54, 12, 32),
+	RK3066_PLL_RATE_NB(106500000, 4, 213, 12, 32),
+	RK3066_PLL_RATE_NB(85500000, 4, 171, 12, 32),
+	RK3066_PLL_RATE_NB(74250000, 4, 198, 16, 32),
+	RK3066_PLL_RATE(74176000, 26, 1125, 14),
+	{ /* sentinel */ },
+};
+
 #define RK3288_DIV_ACLK_CORE_M0_MASK	0xf
 #define RK3288_DIV_ACLK_CORE_M0_SHIFT	0
 #define RK3288_DIV_ACLK_CORE_MP_MASK	0xf
@@ -214,7 +235,7 @@ static struct rockchip_pll_clock rk3288_pll_clks[] __initdata = {
 	[gpll] = PLL(pll_rk3066, PLL_GPLL, "gpll", mux_pll_p, 0, RK3288_PLL_CON(12),
 		     RK3288_MODE_CON, 12, 8, 0, rk3288_pll_rates),
 	[npll] = PLL(pll_rk3066, PLL_NPLL, "npll",  mux_pll_p, 0, RK3288_PLL_CON(16),
-		     RK3288_MODE_CON, 14, 9, ROCKCHIP_PLL_SYNC_RATE, rk3288_pll_rates),
+		     RK3288_MODE_CON, 14, 9, 0, rk3288_npll_rates),
 };

It adds additional dividers for npll (used as source for DCLK). For exmaple, 85500000 needed for me. 

After applying this patch my problem resolved. All resolutions determinted and monitor works normal. 

 

root@tinkerboard:~# cat /sys/devices/platform/display-subsystem/drm/card0/card0-HDMI-A-1/modes
1366x768p60
1920x1080p60
1920x1080p60
1152x864p75
1280x720p60
1280x720p60
1024x768p75
1024x768p60
800x600p75
800x600p60
640x480p75
720x400p70

 

I send pull request https://github.com/armbian/build/pull/1317

I'm not sure that he will be accepted.

 

I created this topic for tinkerboard users with same problem. This patch helped me. 

 

You can manualy build kernel with this patch (needed ubuntu bionic as host system):

git clone https://github.com/armbian/build
cd build
wget https://patch-diff.githubusercontent.com/raw/armbian/build/pull/1317.patch -O 1317.patch
patch -p1 < 1317.patch
sudo ./compile.sh BOARD=tinkerboard BRANCH=default KERNEL_ONLY=yes RELEASE=bionic NO_APT_CACHER=yes BUILD_KSRC=no

 

P.S. The commit description speaks for itself

 

Quote

Rockchip/Tinkerboard default patches fixes. It compiles now but haven't check in details wheather disabled are still needed.

 

Debs for test:

linux-image-rockchip_5.77_armhf.deb

linux-dtb-rockchip_5.77_armhf.deb

 

Or image with installed patched debs:https://zhumar.in/Armbian_5.75_Tinkerboard_Ubuntu_bionic_next_4.19.20_desktop_v3.zip

sha256: 377040dd9c42beaec1531199099d0eb12a547cab3f4e761801bbe1c20afe00b1

 

Not official. Only for test. Use this as own risk.

[Igor]

56 minutes ago, Azq2 said:

The commit description speaks for itself

True. I didn't have time for deep investigation and that was noted. Alternative option was to leave things completely broken.

 

BTW. Thanks!

[berin]

I have the same issue with 1024x600.... very common RPI lcd but there is no built in support for my HDMI disploay

[TonyMac32]

I cleaned and re-enabled the full HDMI patch on 4.4, @Igor it could be rebuilt.

[berin]

I need to get 1024x600 on HDMI working to use my RPI lcd at the correct resolution. It is not supported on ether 4.4 or the latest 4.19

 

The booklet that comes with it list's the following

www.raspberrypi.org/downloads

www.raspberrypi.org/documentation/installation/installing-images/README.md

http://ms-iot.github.io/content/en-US/Downloads.htm

 

hdmi_group=2

hdmi_mode=1

hdmi_mode=87

hdmi_cvt 1024 600 60 6 0 0 0

max_usb_current=1

 

chip rtd2660h

 

The website keeps going up and down. 

http://www.eleduino.com <-- may not work try link below if needed.

https://web.archive.org/web/20180721025145/http://www.eleduino.com/7-0-Inch-1024x600-Pixel-IPS-Hdmi-Input-Capacitive-Touch-Screen-Support-Raspberry-pi-Banana-Pi-Pro-Be-p10533.html

Edited April 5, 2019 by lanefu
Moved to peer support subforum.

[NicoD]

What Armbian image did you use?
Normally this should just work. It's only the Raspberry Pi that needs to have the settings set before boot.
I've got a simular 7" display with the same resolution. Always worked for me.
I can try it tomorrow on the Tinker.
ps.
@lanefu I just saw

again and thought. Oh right, that's it, I come here to let it know and see everything has been put here already. I red it earlier and didn't make the link.

[TonyMac32]

3 hours ago, berin said:

I need to get 1024x600 on HDMI working to use my RPI lcd at the correct resolution. It is not supported on ether 4.4 or the latest 4.19

I merged this with the existing Tinker HDMI topic.  Please keep the discussion in the thread you began it in. 

 

Have you downloaded an image in the last day?  We just rebuilt the 4.4 kernel after I did some cleaning and re-enabled the rest of the hdmi patch that got disabled during some Rockchip shenanigans.

 

[berin]

"no I have not... will do and test."
I have now tested the latest 4.4 bionic

First opinion, very annoying scripting errors in the display settings. Its trying to default to 75hz regardless of what monitor is plugged in, I tried 3 monitors and 2 TVs. 60hz should always be the default refresh rate period, let the user define there refresh rate there after. Most lcd's and tvs do not support 75hz.

 

RPI lcd, 1024x600 is not listed as an option unless I plug the RPI lcd in, then its automatically listed and tries to use that res, but does not work. It just flickers widly and was very hard to see anything to get the res changed. I would strongly suggest NOT having the scripts change resolutions automatically  with out the users input. I used an external monitor and set it to a low resolution. But when I plugged my RPI lcd in it tried to default to 1024x600 that does not work, the screen flickers wildy and is hard to change to something else.  1024x768  works for the time being. I dont understand why 1024x600 is listed at the top of the list above 1920x1080. An other thing that is interesting is that DISPLAY list's my RPI 7" 1024x600 as a Lenovo 19" display? The way the display flickers I'm going to assume its a timing issue. The picture shows for anything from .1 seconds to .5 seconds, typically you can see the display just fine for that time frame. then its blank. Some times the display is streached in odd ways. But the display spends more time BLACK then showing anything at all.

 

An other thing I would strongly suggest is dropping the uboot resolution or at least have the easy option to change from the default 1920x1080 to 1024x768 60hz or other in general. That resolution is so high the display flickers on/off during boot and CLI actions are often impossible to see. Its usless to try and see anything using smaller displays like mine or smaller still like the 5" and the 2.5" etc. lcd's.

[TonyMac32]

On 4/5/2019 at 6:32 PM, berin said:

DISPLAY list's my RPI 7" 1024x600 as a Lenovo 19" display?

 

What you have here is simply a crappy HDMI controller.  I can't help you fix that, realistically.  The reason for this mess is that the EDID is garbage.  My 7" 800x480 identifies as the same.

 

On 4/5/2019 at 6:32 PM, berin said:

First opinion, very annoying scripting errors in the display settings.

 

I do not have this issue with any of my displays (haven't checked 7"), 100% of which use 60 hz.  Was this with a fresh install, or was it after some toying with modelines?  The only script I have added involves making the hot plug behavior work.

 

On 4/5/2019 at 6:32 PM, berin said:

it tried to default to 1024x600 that does not work, the screen flickers wildy and is hard to change to something else

EDID lists the modes in order, native is, I believe, first.

 

On 4/5/2019 at 6:32 PM, berin said:

An other thing I would strongly suggest is dropping the uboot resolution

U-boot driver operates same as kernel, it is trying to set the screen at 1024x600.

 

On 4/5/2019 at 6:32 PM, berin said:

Its usless to try and see anything using smaller displays like mine or smaller still like the 5" and the 2.5" etc. lcd's.

 

I will review this using my 7" lower res clone of yours (same controller/driver, etc).  

 

 

 

 

 

[berin]

I guess I'm comparing  bionic 4.19 download image  to the 4.4 bionic, aside from 1024x600 not being part of the system at all, it does not try to set everything to 75hz by default is what I'm getting at. "crappy HDMI controller" I'm not going to argue that  and reporting the lenovo 19" at least I'm not alone .  scripting errors: i'm refering to changing to display modes automaticlly with out user input and no i have not altered anything. Thats dump image to SD card and boot. "native first" ok makes sense    "Uboot boot resolution" boots fine with my normal full sized external monitors (they are all HD capable). but with the 7" PI LCD it uboots at 1920x1080 unkown HZ and does the flickering thing more like a blink on for a split second then off for 2-6 seconds then on for a second off half a second back again. very random. Same with my other HDMI tiny lcd's it boots at 1920x1080. And does the flicker thing.

[TonyMac32]

Just now, berin said:

scripting errors: i'm refering to changing to display modes automaticlly with out user input and no i have not altered anything

This is default Ubuntu behavior, a few Google searches recommend either creating a xrandr script or a config adjustment to the x server.  

 

U-boot no doubt has no modes for the native res, so goes to the next one down the line, 1920x1080.  

 

Wait a second.  I turned off video output on u-boot.  Can you verify you're booting the image you think you are?  

[berin]

https://dl.armbian.com/tinkerboard/Ubuntu_bionic_default_desktop.7z and that is what ever the latest version is that was released what a day ago?