RussianNeuroMancer

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).

Re-tested with Dell DA300 - no positive changes. https://pastebin.ubuntu.com/p/pDsdRpmHCr/ (PARTUUID is different, as it's seems I like accidentally wiped microSD I used for testing DisplayPort last time, so I had to repeat all this extelinux, kernel extract and uboot steps, with adjusting PARTUUID in extlinux.conf.)

Armbianmonitor: https://pastebin.ubuntu.com/p/qymdnDjRpH/ Re-tested Armbian 21.02.1 focal server and focal desktop images: 1. I found that not-working audio playback via integrated H3 Audio Codec probably was caused by some issues in asound.state file or UCM file for audio adapter (if there is any). Shortly, if I just boot Focal desktop image and try to playback audio via 3.5mm jack - it works. However, if I enable and then disable H3 Audio Codec in pavucontrol - then audio playback via 3.5mm jack just stop working. 2. Microphone doesn't work even on fresh Focal server (via arecord) or Focal desktop or Focal Gnome desktop (via gnome-sound-recorder) where PulseAudio settings was never touched or PulseAudio was never installed in first place. With FriendlyCore image microphone is working. I didn't tested HDMI Audio this time. EDIT Found workaround for getting microphone working: amixer cset name='Mic1 Capture Switch' on,on amixer cset name='Mic2 Capture Switch' on,on Not sure why it's not enabled by default?

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.) Understood.

You mean "anything" literally or "anything besides microSD/eMMC"? With change described here this board works for me. Armbian 21.02.0-trunk is installed on eMMC and I typing this message on this board right it now. There is of course several issues, such as not working DisplayPort and unreliable Type-C ports behavior, but at least it's as good as ROCKPro64, even Gnome Shell Wayland works (earlier it was limited to X11 due to workaround).

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!

Did you checked ssh? Could be something like this: I have similar issue, and ssh works for me, and even Xorg works.

Hi, balbes150! Any idea what could cause the difference in HDMI output behavior I described in the post above. There is also a separate thread about this issue now.

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).

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.

Oh, sure, I perfectly understand this, which is why I going to try to get Dell DA300 so we can proceed with this (I am just afraid it will get some time until I will get it on hands). I just explained why it would not help in my particular use-case, that all Right, I totally forgot I could try Armbian legacy builds too. Thanks for reminder! Armbian_20.11.7_Nanopct4_bionic_legacy_4.4.213_desktop.img: Can't setup desktop due to "Cannot execute /usr/bin/bash: No such file or directory" error. When only Type-C cable is attached - there is no picture on external display. Same flicker via HDMI during boot, but then kernel probably re-initialize display and I can see text console properly (but can not interact with it without bash; ssh doesn't work too). Tried older image instead: Armbian_20.02.7_Nanopct4_bionic_legacy_4.4.213_desktop.img: No HDMI flicker during boot. DisplayPort still does not work (no errors, not even mentioned in dmesg during connection). I also remember there is convenient way to start with my HDMI issues: 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. So between this and this tags there was this commit. I guess first things I should do regarding HDMI issue is to try flash uboot 2020.04 (building it now) on newer Armbian image and see if it help to get HDMI working.

Yes, sure. I guess all three 4.4 kernels (by Firefly, PINE64 and FriendlyARM) is based on Rockchip code? I could try to get Dell DA300 for testing (it probably will take a few weeks) but I would not be able to use it in practice for anything but just testing. In practice I'll still need Belkin F4U093, because there is not many docking stations out there that can charge anything PD-compatible. I tried several docks, from Dell WD15 to StarTech TB3CDK2DP, but after all I had to stick with Belkin F4U093, because Dell and Lenovo docks refuse to charge old HP laptops, StarTech refuse to communicate with Qualcomm USB implementation and doesn't charge HP laptops too, HP docks doesn't charge old Dell laptops, and so on, and so on... so unfortunately Belkin dock is solution with most broad compatibility, and I have to choice but to stick with it for now. Please clarify why you think this incompatibility is caused by patch, while even vendor kernel couldn't use this dock as video output on this specific board? Please take into account that ROCKPro64 (with vendor 4.4 kernel) and Libre Computer Renegade Elite (with vendor 4.4 kernel) works with this dock, while NanoPC-T4 (with vendor 4.4 kernel) does not. No, HDMI output still doesn't work on both of 2020.07 and 2020.10. I had yet to bisect how it was broken and when.

Flashed uboot, displayed version during changed from 2020.07-armbian to 2020.10 with zero timestamp, so I guess it's yours. Unfortunately, still same error: "typec_displayport port0-partner.0: No compatible pin configuration found:0000 -> 000c, 001c <- 0000". But it's seems like I shouldn't be using NanoPC-T4 for testing DP stuff at all. Turns out DP doesn't work for me on this board even with vendor's FriendlyDesktop image based on Rockchip 4.4 branch - getting "cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Not connected. Disabling cdn" error in dmesg. Perhaps there is some incompatibility between this specific boards and this specific dock? (No idea how this would be possible, but not sure what else could be happening here.) Anyway, DisplayPort do work for me on ROCKPro64 (with PINE64 image) and Libre Computer Renegade Elite (with Firefly image). I don't have spare ROCKPro64 on hands right now, but I could use ROC-RK3399-PC for further testing - is there chance you could prepare dtbo file for this board? Actually, vendor said everything should be in upstream by now, but even with uboot 2020.1 and Linux 5.10 DisplayPort doesn't work for me, at least on Armbian. If you have time for this, we could continue here.

Thanks for explanation! I tested this build and unfortunately DisplayPort still doesn't work (dmesg). HDMI issue I mentioned earlier is also there. Just in case, on vendor's 4.4 DisplayPort works work with same docking station (at least on ROCKPro64, but I could test it again on NanoPC-T4, if necessary).

I guess you don't see rendering artifacts because your EDID is different from mine. Dell UP3017 resolution is 2560x1600 - so possibly drm driver trying to initialize output and fail to do so in my case, while for you it works. By the way I found a workaround HDMI issue I getting on vanilla Armbian (first paragraph). 1. Getting text console usable: boot board without HDMI cable attached, and attach cable when boot process is complete. 2. Getting GUI usable: in case of Gnome Shell I had to disable Wayland support in /etc/gdm3/custom.conf - then Xorg re-initialize output during start and it just works. So boot process looks like this: normal uboot, screenflicker, black screen, gdm3 appear on the screen. I wasn't able to found any way to get Wayland session working - screen just stay black.

Balbes150 images with Linux 5.9 never worked for me - red light doesn't even turn on (I just checked images from your link, still doesn't work). Images with Linux 5.10 on other hand does work, but with rendering artifacts.

I see menu but it's seems like it doesn't accept keyboard input, probably due to the fact that my keyboard is attached via USB dock. But since it separate board specifically for testing it's fine, really. During testing I found interesting difference between old Armbian installation running on first NanoPC-T4 that I been used for testing of your rk3399-nanopc-t4-tc.dtbo and fresh Armbian installation I running on second NanoPC-T4 where I tested this extlinux.conf. The difference is incompatibility with Dell UP3017, which I previously mentioned in first paragraphs of this message, is also reproducible on second NanoPC-T4 too. Since I tried to run exactly same kernel on both boards, I think this difference could be caused by much older uboot (probably something from 2019) flashed to eMMC on first NanoPC-T4. By taking into account difference in uboot I re-tested rk3399-nanopc-t4-tc.dtbo on second NanoPC-T4 but DisplayPort still doesn't work. By the way, there is "typec_displayport port0-partner.0: No compatible pin configuration found:0000 -> 000c, 001c <- 0000" error message in dmesg. Does it tell something useful? I will try to build image with uboot v2020.10 just to see if it will help with HDMI or DisplayPort.

Turns out this issue is not ROC-RK3399-PC specific - seeing same issue on NanoPC-T4 too. Display model is Dell UP3017.

~# cat /proc/cmdline root=UUID=1381bbaa-1ce4-41e6-8e85-2ae1d4a974e2 rootwait rootfstype=ext4 console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart=7ac8d505-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 ~# ls -hal /boot итого 65M drwxr-xr-x 3 root root 4,0K дек 27 03:57 . drwxr-xr-x 19 root root 4,0K дек 12 17:46 .. -rw-r--r-- 1 root root 166 дек 27 03:57 armbianEnv.txt -rw-r--r-- 1 root root 1,5K дек 12 17:50 armbian_first_run.txt.template -rw-r--r-- 1 root root 38K дек 12 17:50 boot.bmp -rw-r--r-- 1 root root 3,1K дек 12 17:46 boot.cmd -rw-rw-r-- 1 root root 3,2K дек 12 17:51 boot.scr -rw-r--r-- 1 root root 212K дек 15 15:52 config-5.9.14-rockchip64 lrwxrwxrwx 1 root root 21 дек 27 02:55 dtb -> dtb-5.9.14-rockchip64 drwxr-xr-x 6 root root 4,0K дек 27 02:54 dtb-5.9.14-rockchip64 lrwxrwxrwx 1 root root 25 дек 27 02:55 Image -> vmlinuz-5.9.14-rockchip64 -rw-r--r-- 1 root root 17M дек 27 02:55 initrd.img-5.9.14-rockchip64 -rw-r--r-- 1 root root 0 дек 27 02:55 .next -rw-r--r-- 1 root root 5,5M дек 15 15:52 System.map-5.9.14-rockchip64 lrwxrwxrwx 1 root root 25 дек 27 02:55 uInitrd -> uInitrd-5.9.14-rockchip64 -rw-r--r-- 1 root root 17M дек 27 02:55 uInitrd-5.9.14-rockchip64 -rw-r--r-- 1 root root 27M дек 15 15:52 vmlinuz-5.9.14-rockchip64 ~# lsblk -o +PARTUUID NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT PARTUUID mmcblk2 179:0 0 14,6G 0 disk mmcblk2boot0 179:32 0 4M 1 disk mmcblk2boot1 179:64 0 4M 1 disk mmcblk1 179:96 0 29,8G 0 disk └─mmcblk1p1 179:97 0 29,5G 0 part / 7ac8d505-01 zram0 252:0 0 50M 0 disk /var/log zram1 252:1 0 1,9G 0 disk [SWAP]

Sure, we could try this, but for further test I will use one of spare NanoPC-T4 I have on hands (above I tested board running in production) with fresh image from downloads. It will probably take a few days until I find time to deploy the image to sd card and post output (hopefully I will manage to do so in Saturday) so in case you find free time earlier than I do - you probably could retrieve all needed information from Armbian image itself. Or, alternatively, I could try to build 5.10 with your config.

I don't know what components I should check. Anyway, it's seems like Armbian use same .config for boards where DisplayPort works (Helios64 and PineBook Pro) and boards where it doesn't work (like mine, at least at this moment). Just in case, I didn't changed Armbian default config, so I using .config that you can find below: https://github.com/armbian/build/blob/master/config/kernel/linux-rockchip64-current.config https://github.com/armbian/build/blob/master/config/kernel/linux-rockchip64-dev.config

Yes, it's installed as part of linux-firmware package.

Just to check if I understand you: their pre-compiled uboot doesn't work from SPI or eMMC, only from microSD, right?

I struggle to understand what is the current situation with Renegade Elite board. On one hand I see it's not mentioned anywhere on Armbian download page, and packages for this board is not published in Armbian repository. Although building image manually is possible, so this is a bit strange to see this topic in "Bug tracker - supported boards only" subforum instead of Development. Unfortunately, while result image with Linux 5.9 seems to work fine in headless mode - HDMI output doesn't work for me (uboot is visible, then upper side of the screen flicker several times and it become black, that all). It's fine, but I would like to ask other users - do you observe same behaviour on current Armbian images on this board? Was there version that supported HDMI on this board? On other hand there Armbian fork by balbes150. Image based on 5.9 doesn't looks like boot at all, while image based on 5.10rc4 at least trying to display text console via HDMI, but in result rendering is incorrect (text moved around by small waves, as if Dell UP3017 is attached via analog cable, but in fact it's pure HDMI-HDMI connection and this happening only with this board) so it's not much useful for my task either. By looking at locked topic and bugreports like this one it doesn't looks like balbes150 accept reports for anything but for his build scripts (which is totally fine, of course). So I would like ask, how other owners of this boards using it? Is my HDMI issue caused by high display resolution or maybe this is some recent regression on uboot or kernel side? (I can't check board with othder display right now.) Is there image that works for someone? Or there nothing useful for this board besides vendor image from Firefly web-site?

Yep, this is what I did. Except, in my case I attaching not adapter but docking station that works as USB hub as well (Belkin F4U093). I wonder if mixed mode (when connector is used for both of USB and DP) is excepted to work at this stage?