HDMI is broken on RK3399-based boards for high resolution display since Armbian 20.08

[RussianNeuroMancer]

Armbianmonitor:

http://ix.io/2LJw

Hello!
 
First, and foremost, how issue looks like: https://imgur.com/a/ZrPUi9t
 
Initially I noticed this issue with Dell UP3017 (2560x1600) on Libre Computer ROC-RK3399-PC (post). However later I noticed this on fresh Armbian installations on NanoPC-T4 too (post). Later on I found that old Armbian installations on NanoPC-T4 is unaffected, probably because of older uboot (something from last Armbian 5.xx days) that already flashed on eMMC.
 
Yesterday I compared a couple of old Armbian images (initially that was posted here)
 
Armbian_20.05.7_Nanopct4_focal_current_5.4.49.img - issue is not reproducible,
Armbian_20.08.2_Nanopct4_focal_current_5.8.6.img - issue is reproducible.
 
Today I tried to take Armbian 20.08.2 sources, changed uboot tag to 2020.04 (because tag variable wasn't there in 20.05.7) build it and installed on sd card flashed with Armbian_20.08.2_Nanopct4_focal_current_5.8.6 image. After flashing bootloader via armbian-config uboot version on initial boot screen changed to 2020.04, however issue didn't go away, so probably some other change between Armbian 20.05.7 and 20.08.2 cause difference in HDMI drivers behavior.  
 
I also tried to flash Armbian_20.05.7_Nanopct4_focal_current_5.4.49.img to sd card, update only uboot package, flash it via armbian-config, and now I have this issue on 20.05.7, which is logical, however it does not explain why flashing uboot 2020.04 on top of Armbian 20.08.2 installation didn't help.
 
So I probably missing something here regarding 20.05/20.08 difference? What it could be?

 

P.S. I know I could try to bisect between 20.05 and 20.08, but I guess lack of build tag variable for uboot in Armbian 20.05 could cause problems during bisect.

[RussianNeuroMancer]

Forgot to mention:

Issue is also reproducible on Armbian_20.11.7_Nanopct4_bionic_legacy_4.4.213_desktop.img, probably because modern uboot 2020.10 is there now in legacy images too.

There is workaround for getting Xorg working (which does not help for Wayland, but at least this something).

[piter75]

5 hours ago, RussianNeuroMancer said:

changed uboot tag to 2020.04 (because tag variable wasn't there in 20.05.7)

The tag was always there but at a different configuration level so no need to change it manually ;-)

 

Nonetheless the ideas to explore for this issue (which I will unfortunately have no time for in foreseeable future) would be:

1. Disable HDMI support for rk3399 boards in u-boot again - something like this PR (may need adjustments)
   It was already disabled once because of similar issues (which were supposed to be fixed with v2020.07) but I am leaning towards disabling it for all rk3399 boards again;
2. Blacklist panfrost module, reboot and see if it helps - there was quite some development in panfrost between 5.4 and 5.8
   This however does not apply to issues found in legacy;
3. Try both of the above at the same time if none helps on its own;

If you can spare some time - try testing the above scenarios.

[RussianNeuroMancer]

On 1/12/2021 at 6:37 PM, piter75 said:

Disable HDMI support for rk3399 boards in u-boot again - something like this PR (may need adjustments)
It was already disabled once because of similar issues (which were supposed to be fixed with v2020.07) but I am leaning towards disabling it for all rk3399 boards again;

Yep, that did it - when HDMI support is disabled in uboot 2020.10 issue is not reproducible on Libre Computer ROC-RK3399-PC.

 

Thank you for advice!

[usual user]

On 1/14/2021 at 10:28 AM, RussianNeuroMancer said:

when HDMI support is disabled in uboot 2020.10 issue is not reproducible

I stumbled across a patch set that enables higher resolutions than FHD. I'm wondering if this has some impact on your HDMI issue. Since I built a kernel for other reasons, I pulled the patches also in. Is there an interest in trying it out with my uboot on your NanoPC-T4? It will be picked up by the test verbose option.

[RussianNeuroMancer]

8 hours ago, usual user said:

Is there an interest in trying it out with my uboot on your NanoPC-T4?

 

Yes, hopefully I wall have a chance to test it mid Februrary or a bit later. (By the way, I going to get Dell DA300 on next week or so.)

 

8 hours ago, usual user said:

It will be picked up by the test verbose option.

Understood.

[denni_isl]

The board is nanopi-m4v2  and the image is Armbian 21.02.0-trunk Focal with Linux 5.10.13-rockchip64.

 

The problem is that hdmi - resolution 1920x1080@60Hz does only work if I physically connect the hdmi to nanopi-m4v2 AFTER I see "Starting kernel ..." in the UART serial console terminal.

 

What I have understood is that hdmi of the new u-boot does conflict with the hdmi of the kernel.   

 

This is probably a bug in u-boot so the workaround would be to compile u-boot without hdmi support.

 

How can one compile u-boot and apply the newly compiled u-boot to armbian on the emmc with those modification?

 

 

Quote

diff --git a/configs/nanopi-m4v2-rk3399_defconfig b/configs/nanopi-m4v2-rk3399_defconfig

index 0b7077ca..45d05078 100644

--- a/configs/nanopi-m4v2-rk3399_defconfig

+++ b/configs/nanopi-m4v2-rk3399_defconfig

@@ -55,15 +55,8 @@ CONFIG_USB_ETHER_ASIX88179=y

CONFIG_USB_ETHER_MCS7830=y

CONFIG_USB_ETHER_RTL8152=y

CONFIG_USB_ETHER_SMSC95XX=y

-CONFIG_USB_KEYBOARD=y

CONFIG_SPL_TINY_MEMSET=y

CONFIG_ERRNO_STR=y

-CONFIG_DM_VIDEO=y

-CONFIG_VIDEO_BPP16=y

-CONFIG_VIDEO_BPP32=y

-CONFIG_DISPLAY=y

-CONFIG_VIDEO_ROCKCHIP=y

-CONFIG_DISPLAY_ROCKCHIP_HDMI=y

CONFIG_LOG=y

CONFIG_LOG_CONSOLE=y

CONFIG_SPL_LOG=y

 

Something like this maybe https://www.olimex.com/wiki/ArmbianHowTo

 

Perhaps this to adapt the compiled image to emmc - sudo dd if=u-boot-with-spl.bin of=/dev/sdX seek=16 conv=sync

 

 

[RussianNeuroMancer]

On 2/2/2021 at 11:01 AM, usual user said:

Is there an interest in trying it out with my uboot on your NanoPC-T4?

 

Yes, it does slight positive effect - now I seeing kernel boot log and then Armbian desktop. However, everything after uboot (both of kernel log and Armbian desktop) is distorted by exactly same rendering artifact I described here (probably because balbes150 used same patch in his Armbian fork).