Jump to content

Rock64 HDMI video scan lines


rock64user

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Posted (edited)

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 by rock64user
Link to comment
Share on other sites

  • Werner changed the title to Rock64 HDMI video scan lines

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines