RussianNeuroMancer

Ok, I get why you won't to submit this change. Just want to notice that it looks like Type-C port is in host mode in case legacy 4.4 kernel and in FriendlyDesktop (I don't remember kernel version, probably 4.4 too). So it looks like Type-C is intended to run in host mode after all.

I could, but this solution does not scale (specifically "things that don’t scale ... fix a problem for myself" and "things that scale ... fix the problem in way that will just work for most people, most of the time"). I there reason why you can't submit patch for type-c port to Armbian? You have better understanding of Armbian internals than I do, for sure.

I briefly tested 5.6.10 kernel and found that Samsung 970 EVO doesn't work again, same PCIe link training gen1 timeout. Rollback to 5.4.32, and it works again. Manually compiled dtb will be overwritten during linux-dtb-current-rockchip64 package updates, I guess?

I guess he found it here: https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/codecs/es8316/EnableSeq.conf#L16

Did you get Type-C port working on 5.4 too?

Is it possible to enable type-c port without updating to dev branch?

I have some progress with SSD issue: Try to remove (or move somewhere else) rockchip-pcie-gen2.dtbo from /boot/dtb/rockchip/overlay and let me know what you see. From my testing 5.4.8 and 5.4.20 fail like this: And 5.4.26 panic like this: I also noticed that these fresh 4.4 legacy images no longer boot with Samsung SSD attached (really long "Unhandled fault" error) so I had to use vendor's microSD image to restore eMMC backup from NVME (I know, my fault, had to have one more copy somewhere else). Do you observe same behavior with Armbian 4.4 legacy images on your NanoPC-T4? EDIT1 Hmm, somehow got 5.4.26 working with Samsung SSD. At least I upgraded to current u-boot manually by using dd (automatic u-boot updater from armbian-config didn't work with "Unsupported u-boot processing configuration" error) and removed rockchip-pcie-gen2.dtbo. Another difference with logs above that above I tried to boot from microSD and now I tried same steps with installation I have on eMMC. EDIT2 It's seems like part of the errors above caused by the fact that I didn't power down board completely between attempts to run 4.4 and 5.4 kernels - I didn't detached PSU and I didn't detached serial console. I guess if I would try that before boot Armbian with 4.4 kernel from microSD it would work. However, interesting part here that is that friendlydesktop never fail to boot and never fail to detect Samsung SSD, even without detaching PSU and serial console. So it's seems like some necessary patches that make board boot more stable is still missing from upstream. Right now I have Samsung SSD working on 5.4.26 even with rockchip-pcie-gen2.dtbo.

Same here on NanoPC-T4. While with 4.4 kernel I can set native resolution 2560x1600, with 5.3 there is no options above FullHD.

From 5.3.11 to 5.4.20, so simply from "old" current to "new" current. Removing fdtfile entry indeed helps, thank you! Any idea what to do with SSD? Upstream issue?

Couple of issues I discover so far: 1. Just found that kernel upgrade via armbian-config cause replacing legacy u-boot (linux-u-boot-nanopct4-default version 5.98) with linux-u-boot-nanopct4-current 2020.01 (that was Bionic installation updated to Eoan) which refuse to boot from eMMC: Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2949 bytes read in 21 ms (136.7 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 0 193 bytes read in 18 ms (9.8 KiB/s) 8355114 bytes read in 881 ms (9 MiB/s) 20722176 bytes read in 2146 ms (9.2 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting! 2698 bytes read in 39 ms (67.4 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 39000000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 8355050 Bytes = 8 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ERROR: Did not find a cmdline Flattened Device Tree Loading Ramdisk to f572b000, end f5f22cea ... OK FDT and ATAGS support not compiled in - hanging ### ERROR ### Please RESET the board ### Please let me know if I need to perform additional testing or provide additional logs. 2. While WD SSD, such as WDS200T3X0C, works just fine on both of Linux 4.4 and 5.3, SSD from Samsung, such as 970 EVO, works only with 4.4, but not with 5.3. Pci driver just fail to detect it, while on 4.4 same SSD works for half year without issues. 3. USB-C port doesn't work. Docking stations, flash drives, and external disks all detected in the same way: phy phy-ff770000.syscon:usb2-phy@e450.2: charger = USB_DCP_CHARGER

You sure this one is relevant? Traceback in this bugreport end up with "sqlite3.OperationalError: unable to open database file" (it can't open it due to permission issue caused by snapd) and it's looks like unrelated to error we see on Armbian.

Okay, I see this as way to workaround issue, but what is root cause that make command-not-found behave like this only on Armbian? (At least from what I see this happen only on Armbian.)

I have similar issue and it's looks like Armbian-specific. At least it's not arm-specific as I can not reproduce it on on RPi3B and Snapdragon-based Lenovo Yoga C630 WOS with regular Ubuntu, and it's not mentioned in package issues in Ubuntu bugtracker. Is anyone have an idea what cause this issue and how to resolve it?

I build today snapshot from oibaf for armhf too, but only for eoan: ppa:russianneuromancer/drivers https://launchpad.net/~russianneuromancer/+archive/ubuntu/drivers/+packages?field.name_filter=&field.status_filter=published&field.series_filter=eoan

WDS200T3X0C also works, tested on 4.4 and 5.3rc4.

In case anyone need this, there is pre-build deb-packages for arm64 with enabled Panfrost: ppa:oibaf/graphics-drivers

I tried to build Mesa with enabled lima and kmsro drivers, seems like this work mostly fine: https://launchpad.net/~russianneuromancer/+archive/ubuntu/drivers (for Ubuntu 19.04 only, due to Mesa 19.0 dependencies). However, attempts to interact with lima via X11 always result in "libEGL warning: DRI2: failed to authenticate". https://paste.fedoraproject.org/paste/vmKQVPcEURxlcvqkqLDiTw https://paste.fedoraproject.org/paste/2VbdPxubtS9a-9E~hzZbIA ...and attempts to run glmark2-es2-wayland under Weston reveal that it running on llvmpipe. Testing on NanoPC-M1 with current dev kernel: ~$ dmesg | grep lima [ 9.943493] lima 1c40000.gpu: bus rate = 200000000 [ 9.943506] lima 1c40000.gpu: mod rate = 384000000 [ 9.950490] lima 1c40000.gpu: gp - mali400 version major 1 minor 1 [ 9.950539] lima 1c40000.gpu: pp0 - mali400 version major 1 minor 1 [ 9.950581] lima 1c40000.gpu: pp1 - mali400 version major 1 minor 1 [ 9.950629] lima 1c40000.gpu: l2 cache 64K, 4-way, 64byte cache line, 64bit external bus [ 9.960591] [drm] Initialized lima 1.0.0 20170325 for 1c40000.gpu on minor 1 (full log) I wonder if anyone was able to install Lima from Mesa upstream with current Armbian dev kernel and replicate at least this results?