Rock64 HDMI video scan lines

[rock64user]

After shelving my Rock 64 I dusted it off and downloaded the latest desktop image with Ubuntu Focal. The latest OS has video artifacts that the older OS did not. I can only describe the issue as "scan lines," but they are random black bars that appear through out the entire screen (as if WiFi is interrupting the signal only there's no WiFi on the device). I would like to know the best way to bisect the issue as I'm fully capable of cloning the repo, building the image, loading the image and testing it out but if there are pointers to simplify the process I'd love to hear. Hoping to give back since this is a community supported board. Thanks.

[rock64user]

I found the rock64 archive at https://mirror.12z.eu/pub/linux/armbian/dl/rock64/archive/

So before I start bisecting I will be loading several versions to see if it's a kernel issue or userspace issue. (Taking a kernel from one release to another)

Will post updates on what I find!

[rock64user]

More news, I think this could be a u-boot issue. I have seen some u-boot related changes in the Armbian changelog at https://docs.armbian.com/Release_Changelog/

Thank you for moving to Jira and keeping such good track of completed tasks -- this gives me much more insight into what has changed and when.

 

Here's how I believe it's a u-boot issue:

1. I started with an older Armbian image I have: Armbian_5.91_Rock64_Debian_buster_default_4.4.184_desktop.img

2. I copied several Linux kernels onto this SD card and updated the /boot/Image and /boot/uInitrd and /boot/dtb symlinks to load different kernels.

 

All kernels I tried did not produce any black bars on the HDMI output.

 

The kernels tested were

- 4.4.184 from Armbian_5.91_Rock64_Debian_buster_default_4.4.184_desktop.img

- 4.4.213 from Armbian_21.08.1_Rock64_buster_legacy_4.4.213_xfce_desktop.img

- 5.10.60 from Armbian_21.08.1_Rock64_bullseye_current_5.10.60.img

- 5.13.12 from Armbian_21.08.1_Rock64_hirsute_edge_5.13.12.img

 

Next I will load the Armbian 21.08.1 images without any changes to SD card to verify that they are all affected before inspecting u-boot.

[rock64user]

More news, this is not u-boot issue. I git cloned current armbian build from github.com and compiled kernel+bootloader. This resulted in `output/debs/linux-u-boot-current-rock64_21.11.0-trunk_arm64.deb` I inspected this file and can see there is no `preinst` or `postinst` files so manual update of the bootloader is necessary (without doing more search). Looking at the `/usr/lib/u-boot/platform_install.sh` script and the files in the *.deb I can see the relevant dd commands that are needed to update the bootloader.

 

With `Armbian_5.91_Rock64_Debian_buster_default_4.4.184_desktop.img` as the image written to SD card, I wrote the newly compiled bootloader and I restarted the rock64. It did not display any HDMI/video artifacts.

To further exclude u-boot being problematic, I wrote `Armbian_21.08.1_Rock64_bullseye_current_5.10.60.img` to SD card then extracted the bootloaded from Armbian 5.91 and wrote it to SD card. This did not fix the HDMI artifacts.

 

Now time to investigate which package is causing the issue This will probably take a long time.

[rock64user]

So the issue might be in the kernel after all which is good. I found this by playing with armbian-config utility to change the kernel and u-boot versions. 4.4.x is ok but 5.10, 5.13, and 5.14 exhibit the behavior. I'm not sure why my older tests did not exhibit the HDMI artifacts. I've been trying to compile old versions for rock64 using armbian build but it seems that is quite challenging because gcc-linaro is not found because the old torrent file is not longer available (branch v20.08) and in a different branch (v20.05) u-boot fails to compile because of an error (/usr/include/libfdt_env.h:71:30: error: conflicting types for ‘fdt64_t’).

 

I think it's time to ask in the peer to peer section

[gedas07]

hello 

were you able to solve it somehow?

I have the same problems on the desktop , with buster and a rock64 , i have black horizontal lightning bolts every x seconds

[Jerry]

Same question. The video glitches are very annoying. Withe GUI running, moving the mouse seems to trigger them.
Also, under Display, it does not allow me change resolution or scan rate (grayed out). Is that related?

[rock64user]

On 3/1/2022 at 4:07 PM, gedas07 said:

were you able to solve it somehow?

I left armbian because of the cancer. You can thank the admins

[rock64user]

seems time has healed the wounds.

 

I find that adding `cpufreq_dt` to blacklisted modules and running `sudo update initramfs -u` seems to have resolved the issue but at the cost of having a slow CPU.

 

So I think the issue is cpu frequency scaling, possible caused by some device tree changes.

 

[Edit] I'm currently looking at this change to see if any parts made it into mainline since I know upstream doesn't like large patches like this: https://github.com/hanwckf/linux-rk3328-box/commit/23bd4498927474aeedd7cf45dcb498583aa4cfba

Edited March 5 by rock64user

[rock64user]

Can the [invalid] tag be removed please?

[Werner]

Yes. It's stating anyways.

[rock64user]

Thank you!

[tchebb]

This issue might be caused by DRAM frequency scaling, which changes RAM frequency at runtime based on usage. Mainline Linux supports DRAM frequency scaling on RK3399 via the `CONFIG_ARM_RK3399_DMC_DEVFREQ` kernel config, but mainline is missing a patch that prevents the frequency from changing while a frame is being scanned out. That patch is needed because changes during scanout can cause glitches like the ones you describe in the RK3399's Video Output Processor (VOP).

 

To check if that's the issue, you can try forcing the RAM frequency to the maximum by running the following:

echo 'performance' | sudo tee /sys/class/devfreq/memory-controller/governor

 

That'll result in higher power usage, but it should eliminate the glitches until you next reboot, as the RAM frequency won't change anymore.