ozacas

ok, so that tells me the running kernel has the module configured (first command) and that it is present in the vendor kernel module folder tree (third command). but the second command is the interesting one: it tells me nothing loaded the driver module during startup. weird. what does sudo modprobe r8169 do on your system (it should produce no output if all is well) but once that is done, you should have ethernet interfaces present on your system. ip link will tell you. the next question is why the driver is not being loaded automatically. My system is a little different to yours - we use slightly different software to get the networking started.

yep, so networkd couldnt start properly due to interfaces not being present. Hardware isnt being detected (unlikely as you say) or more likely driver is not there to drive them. Lets test theory #2 - acas@opi2:~$ zcat /proc/config.gz | grep 8169 CONFIG_R8169=m CONFIG_R8169_LEDS=y acas@opi2:~$ lsmod | grep 8169 r8169 106496 0 the running kernel should have an appropriate driver configured into it and that driver should be loaded and running. My guess is somehow the driver is missing after the update - try this to see if it is present acas@t6:~$ find /lib/modules -name r8169.ko /lib/modules/6.1.75-vendor-rk35xx/kernel/drivers/net/ethernet/realtek/r8169.ko i see it with both vendor and edge kernels, so it should be there...

try to see what happened during kernel boot by searching through the messages: acas@opi2:~$ sudo dmesg | grep eth [ 0.000000] psci: probing for conduit method from ACPI. [ 3.410292] r8169 0003:01:00.0 eth0: RTL8125B, c0:74:2b:fe:78:ab, XID 641, IRQ 23 [ 3.410304] r8169 0003:01:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko] [ 3.433464] r8169 0004:01:00.0 eth1: RTL8125B, c0:74:2b:fe:78:aa, XID 641, IRQ 24 [ 3.433479] r8169 0004:01:00.0 eth1: jumbo features [frames: 9194 bytes, tx checksumming: ko] [ 3.451419] r8169 0004:01:00.0 enP4p1s0: renamed from eth1 [ 3.452652] r8169 0003:01:00.0 enP3p1s0: renamed from eth0 and if that looks ok, then likely a higher level problem failed to configure the networking systemctl list-units --state=failed might give you clues as to what failed to work during startup.

maybe try something like: acas@t6:/boot$ find /boot/dtb* -name \*hdmirx\* /boot/dtb-6.1.75-vendor-rk35xx/rockchip/overlay/rk3588-hdmirx.dtbo to try to find the overlay name. And verify its presence on the system.

@Benjamin Sonntag I think you want to ask aplay to list recording devices rather than playback devices - I have a different rk3588 device and it shows: acas@t6:~$ aplay -C -l **** List of CAPTURE Hardware Devices **** card 0: rockchiphdmiin [rockchip-hdmiin], device 0: rockchip-hdmiin i2s-hifi-0 [rockchip-hdmiin i2s-hifi-0] Subdevices: 0/1 Subdevice #0: subdevice #0 card 1: realtekrt5616co [realtek,rt5616-codec], device 0: fe470000.i2s-rt5616-aif1 rt5616-aif1-0 [fe470000.i2s-rt5616-aif1 rt5616-aif1-0] Subdevices: 1/1 Subdevice #0: subdevice #0 that is with the overlay enabled as described

the OS is produced with a custom build directive (note the BOARD chosen and how EDK2 is selected as the opi5+ variant for the SBC) and installed to the USB stick per - ./compile.sh EXPERT=yes KERNEL_GIT=shallow BRANCH=edge UEFI_EDK2_BOARD_ID=orangepi-5plus BOARD=uefi-arm64 BOOT_FDT_FILE="rockchip/rk3588-orangepi-5-plus.dtb" CLEAN_LEVEL=debs,cache,make-kernel ENABLE_EXTENSIONS=grub-with-dtb as per this thread

the original system that started the thread, after (failed) armbian-install run, looks like this with the USB stick used to boot the system: acas@uefi-arm64:~$ df Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 1605708 12816 1592892 1% /run /dev/sda2 59094688 5773640 52631248 10% / tmpfs 8028524 0 8028524 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock efivarfs 64 42 23 65% /sys/firmware/efi/efivars tmpfs 8028524 0 8028524 0% /tmp /dev/sda1 258094 150 257945 1% /boot/efi /dev/zram1 47960 2152 42224 5% /var/log tmpfs 1605704 60 1605644 1% /run/user/1000 acas@uefi-arm64:~$ fdisk -l Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors Disk model: Fanxiang S501Q 1TB Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: A3C2AE18-4086-48D2-B1F9-90B315BAB1FA Device Start End Sectors Size Type /dev/nvme0n1p1 2048 2000408575 2000406528 953.9G Linux filesystem Disk /dev/sda: 57.62 GiB, 61865984000 bytes, 120832000 sectors Disk model: USB Flash Drive Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 611F458A-F35E-B04A-9F22-8E04707F1E17 Device Start End Sectors Size Type /dev/sda1 8192 532479 524288 256M EFI System /dev/sda2 532480 120831966 120299487 57.4G Linux root (ARM-64) Disk /dev/zram0: 7.66 GiB, 8221212672 bytes, 2007132 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram1: 50 MiB, 52428800 bytes, 12800 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes note how there is no EFI partition on the NVME drive. But the image from the armbian build framework has an EFI system partition and is what i'm using to boot the system right now via the USB stick.

wait - you wanted me to do it to the original system in the thread? I think I did it to the wrong one...

system boots successfully without the sata ssd adapter plugged in - so it boots successfully off SPI (EDK2) -> nvme -> linux via ACPI alone.

the box i was referring to has the following - acas@opi2:~/build$ fdisk -l Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors Disk model: Fanxiang S500Pro 1TB Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x4f11c8df Device Boot Start End Sectors Size Id Type /dev/nvme0n1p1 2048 411647 409600 200M ef EFI (FAT-12/16/32) /dev/nvme0n1p2 411648 2000409263 1999997616 953.7G 83 Linux Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: ASM1153USB3.0TOS Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 33553920 bytes Disklabel type: dos Disk identifier: 0x2eeae39f Device Boot Start End Sectors Size Id Type /dev/sda1 2048 8390655 8388608 4G b W95 FAT32 /dev/sda2 8390656 50333695 41943040 20G 83 Linux /dev/sda3 50333696 3907029167 3856695472 1.8T 83 Linux Disk /dev/zram0: 3.74 GiB, 4014276608 bytes, 980048 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram1: 50 MiB, 52428800 bytes, 12800 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes ah... i have a USB connected sata adapter ssd as /dev/sda - forgot about that. Maybe that is accidentally providing boot (used to be connected to an rpi4)

https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md describes the current overview of collabora RK3588 efforts, which are going into the mainline kernel as things become available. But there is also a vendor kernel for opi5+, which is currently at 6.1 and includes working HDMI: incl. audio, kde plasma 1080p or 4k with kodi hwaccel is what I use. Using the armbian build framework you can prepare images with the features you need and the underlying ubuntu and linux kernel version (and many other settings) to suit your requirements. If you could share some details about your needs we may be able to help further.

No problem - i'm starting the get the picture that there is a lot of corner cases here... Can you expand on this? I have it working on another opi5+ running armbian right now: acas@opi2:~$ df Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 784040 12828 771212 2% /run /dev/nvme0n1p2 983175932 901075092 32084516 97% / tmpfs 3920192 0 3920192 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock efivarfs 64 9 56 14% /sys/firmware/efi/efivars /dev/nvme0n1p1 204580 308 204272 1% /boot/efi tmpfs 3920192 15492 3904700 1% /tmp /dev/sda3 1896953852 1309223496 491296588 73% /data /dev/zram1 47960 31804 12572 72% /var/log tmpfs 784036 8264 775772 2% /run/user/1000 acas@opi2:~$ uname -a Linux opi2.local 6.10.11-edge-arm64 #1 SMP Wed Sep 18 17:25:18 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux also EDK2 installed to SPI flash and then /boot/efi and root from NVME, just slightly older kernel.

are we talking about different things here? I didnt think I was using U-BOOT but rather EDK2 (SPI flash) -> grub -> linux (ACPI) for the boot process. But i'm no expert here, so could be wrong. The way I see things working as far as armbian-install is concerned for a UEFI system - eg. when using an image compiled with UEFI_EDK2_BOARD_ID=orangepi-5plus BOARD=uefi-arm64 locate EFI partition on source volume (running system) locate root partition on source volume fail if (1) and (2) cannot be found ensure target volume (eg. NVME drive) has appropriate partitions and filesystems for (1) and (2) ensure partitions on target volume are visible to user-land via /dev entries - fail if not populate each filesystem in (4) with corresponding data from source volume notify the user if something goes wrong. This is probably hard to do given the number of programs involved and the complexity of operations, but failed steps cause gaps downstream which can be hard to spot adjust /etc/fstab to reference the new partitions on the target volume eg. nvme drive only. Maybe some other adjustments too?

the image was written to USB stick using balenaEtcher and then booted via USB2 port on the opi5+ - which appears as sda as the source/boot/root drive. No EMMC on the opi5+ nor SD card was installed or used at all.

OK - fresh install!! before armbian-install monitor results - https://paste.armbian.com/jifapohama (iostat was not installed so results from it are missing) armbian install log data (I screwed up the shell capture the first time, had to run it twice): ran install using bash -x /usr/sbin/armbian-install 2>&1 | tee -a /tmp/install-bash-out.log to capture output (terminal characters and all). Recommend you cleanup the bash capture with col -b to reduce the pesky terminal emulation characters captured /var/log/armbian-install.log after run. Both files are attached below. post-condition (no EFI partition on nvme drive, but no leftover mount point this time): root@uefi-arm64:/etc/grub.d# df Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 1605692 12844 1592848 1% /run /dev/sda2 59094688 5723500 52681388 10% / tmpfs 8028460 0 8028460 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock efivarfs 64 41 24 64% /sys/firmware/efi/efivars tmpfs 8028460 20 8028440 1% /tmp /dev/sda1 258094 150 257945 1% /boot/efi /dev/zram1 47960 1532 42844 4% /var/log tmpfs 1605692 60 1605632 1% /run/user/1000 root@uefi-arm64:/etc/grub.d# fdisk /dev/nvme0n1 Welcome to fdisk (util-linux 2.39.3). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. This disk is currently in use - repartitioning is probably a bad idea. It's recommended to umount all file systems, and swapoff all swap partitions on this disk. Command (m for help): p Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors Disk model: Fanxiang S501Q 1TB Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: A3C2AE18-4086-48D2-B1F9-90B315BAB1FA Device Start End Sectors Size Type /dev/nvme0n1p1 2048 2000408575 2000406528 953.9G Linux filesystem Command (m for help): after a reboot, EDK2 0.11.2 is unable to boot from the drive when chosen from the boot manager in the UEFI bios. I'll leave the system alone for now should further debug be required. armbian-install.log install-bash-out.log

Unfortunately, I hacked the system but i'll redo the test and capture more. I performed two armbian-install runs: first time (after first boot) where I accepted all the defaults. The system failed to boot: no EFI FAT partition was setup despite nuking the entire drive. This led to the "intermediate state" above that I captured. I cant see how armbian-install is going to work with that device state: no way to setup the right partitions as they are not present in /dev. I noted that after completion of this run, a temporary mount was still present (presumably lsblk picked that up too from the mountpoint shown) second time (after reporting the above) I created an EFI partition and a second partition only for the root filesystem using gdisk by hand and then forced it to use those partitions rather than nuking the entire drive. This sort-of worked: root was populated, but the EFI partition was not. No problem: just copied it from the USB stick I used to boot from. The result was a bootable system. Happy to run bash -x /usr/sbin/armbian-install to capture state (as well as the install log) shortly, once a fresh image is built.

Hi, A UEFI-ARM64 install of armbian opi5+ 24.11.0-trunk fails during armbian-install due to incorrect knowledge of partitions: root@uefi-arm64:/usr/sbin# lsblk -l NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 1 14.4G 0 disk sda1 8:1 1 256M 0 part /boot/efi sda2 8:2 1 14.2G 0 part /var/log.hdd / zram0 252:0 0 7.7G 0 disk [SWAP] zram1 252:1 0 50M 0 disk /var/log zram2 252:2 0 0B 0 disk nvme0n1 259:0 0 953.9G 0 disk nvme0n1p2 259:3 0 953.6G 0 part /mnt/armbian-install.NQULbp/rootfs /mnt/tmp root@uefi-arm64:/usr/sbin# udevadm settle root@uefi-arm64:/usr/sbin# lsblk -l NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 1 14.4G 0 disk sda1 8:1 1 256M 0 part /boot/efi sda2 8:2 1 14.2G 0 part /var/log.hdd / zram0 252:0 0 7.7G 0 disk [SWAP] zram1 252:1 0 50M 0 disk /var/log zram2 252:2 0 0B 0 disk nvme0n1 259:0 0 953.9G 0 disk nvme0n1p2 259:3 0 953.6G 0 part /mnt/armbian-install.NQULbp/rootfs /mnt/tmp root@uefi-arm64:/usr/sbin# ls -l /dev/nvme0n1* brw-rw---- 1 root disk 259, 0 Oct 5 06:18 /dev/nvme0n1 brw-rw---- 1 root disk 259, 3 Oct 5 06:18 /dev/nvme0n1p2 root@uefi-arm64:/usr/sbin# fdisk /dev/nvme0n1 Welcome to fdisk (util-linux 2.39.3). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. This disk is currently in use - repartitioning is probably a bad idea. It's recommended to umount all file systems, and swapoff all swap partitions on this disk. Command (m for help): p Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors Disk model: Fanxiang S501Q 1TB Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: D98AAC78-13E2-42D7-948D-3BD864476713 Device Start End Sectors Size Type /dev/nvme0n1p1 2048 526335 524288 256M EFI System /dev/nvme0n1p2 526336 2000408575 1999882240 953.6G Linux filesystem Command (m for help): q although I can hack the install, just curious if there is a cleaner solution other than reboot...

Grub is available, but I've not tried it with both Android and Ubuntu dual boot as you describe. Note that there is also waydroid which may be worth considering to avoid the endless reboots - see But to come back to your original question, try this approach to setting up Grub on your OrangePi 5+ - it works well. Just be careful to choose an appropriate kernel for your requirements. You might have to enable USB2 support in the UEFI in order for the first boot to work (if you use a USB stick like I did) - see https://forum.armbian.com/topic/35168-generic-uefi-arm64-on-orangepi-5/

perhaps some of the tips suggested here may be relevant? https://serverfault.com/questions/1011077/linus-ext4-nvme-crashes-during-high-io

You might wanna bump the kernel for more modern support, but check to see if the drivers are blacklisted within /etc/modprobe - see various comments in https://askubuntu.com/questions/1407357/rtl8821ce-driver-not-working-on-ubuntu-22-04

No worries, I use panthor for hwaccel kodi desktop running under wayland & kde plasma. Works well. I just included the panthor logs for the mali GPU discovery info.

Depending on what you want (headless?), you may not need it - https://www.collabora.com/news-and-blog/news-and-events/release-the-panthor.html But if you do want it - ensure panthor-gpu is present in loaded overlays (no other is needed) acas@t6:~$ grep overlays /boot/armbianEnv.txt overlays=panthor-gpu rk3588-hdmirx acas@t6:~$ find /lib/modules/ -name \*panthor\* -ls 76560560 4 drwxr-xr-x 2 root root 4096 Sep 7 19:19 /lib/modules/6.1.75-vendor-rk35xx/kernel/drivers/gpu/drm/panthor 76560716 180 -rw-r--r-- 1 root root 182920 Sep 7 19:10 /lib/modules/6.1.75-vendor-rk35xx/kernel/drivers/gpu/drm/panthor/panthor.ko then you should see its messages after system boot.

other comparative info - acas@t6:~$ find /lib/firmware -name mali*.bin -ls 76559798 268 -rw-rw-r-- 1 root root 274432 Jun 26 22:44 /lib/firmware/arm/mali/arch10.8/mali_csffw.bin 76582704 268 -rw-r--r-- 1 root root 274432 Aug 10 16:46 /lib/firmware/mali_csffw.bin acas@t6:~$ sha256sum /lib/firmware/mali_csffw.bin 8e7c821a55ca1c345cc79f61243616dd25fc35b81f090946f302886d67712df5 /lib/firmware/mali_csffw.bin acas@t6:~$ dpkg -l | grep -i mesa ii libegl-mesa0:arm64 24.2.2~kisak1~n arm64 free implementation of the EGL API -- Mesa vendor library ii libgl1-mesa-dri:arm64 24.2.2~kisak1~n arm64 free implementation of the OpenGL API -- DRI modules ii libglapi-mesa:arm64 24.2.2~kisak1~n arm64 free implementation of the GL API -- shared library ii libglx-mesa0:arm64 24.2.2~kisak1~n arm64 free implementation of the OpenGL API -- GLX vendor library ii mesa-libgallium:arm64 24.2.2~kisak1~n arm64 shared infrastructure for Mesa drivers ii mesa-utils 9.0.0-2 arm64 Miscellaneous Mesa utilities -- symlinks ii mesa-utils-bin:arm64 9.0.0-2 arm64 Miscellaneous Mesa utilities -- native applications

acas@t6:~$ sudo dmesg | grep -i panthor [ 7.838279] panthor fb000000.gpu-panthor: [drm] clock rate = 198000000 [ 7.838367] panthor fb000000.gpu-panthor: Looking up mali-supply from device tree [ 7.839653] panthor fb000000.gpu-panthor: Looking up sram-supply from device tree [ 7.839662] panthor fb000000.gpu-panthor: Looking up sram-supply property in node /gpu-panthor@fb000000 failed [ 7.844455] panthor fb000000.gpu-panthor: EM: OPP:400000 is inefficient [ 7.844460] panthor fb000000.gpu-panthor: EM: OPP:300000 is inefficient [ 7.844541] panthor fb000000.gpu-panthor: EM: created perf domain [ 7.844722] panthor fb000000.gpu-panthor: [drm] mali-g610 id 0xa867 major 0x0 minor 0x0 status 0x5 [ 7.844726] panthor fb000000.gpu-panthor: [drm] Features: L2:0x7120306 Tiler:0x809 Mem:0x301 MMU:0x2830 AS:0xff [ 7.844729] panthor fb000000.gpu-panthor: [drm] shader_present=0x50005 l2_present=0x1 tiler_present=0x1 [ 7.857514] panthor fb000000.gpu-panthor: [drm] Firmware protected mode entry not be supported, ignoring [ 7.857895] panthor fb000000.gpu-panthor: [drm] CSF FW v1.1.0, Features 0x0 Instrumentation features 0x71 [ 7.858927] [drm] Initialized panthor 1.0.0 20230801 for fb000000.gpu-panthor on minor 2 for me, mali firmware is located in: acas@t6:~$ find /lib/firmware -name mali*.bin /lib/firmware/arm/mali/arch10.8/mali_csffw.bin /lib/firmware/mali_csffw.bin the latter being a legacy location, just there for posterity 😀

To use the rkmpp service you must be using a vendor based kernel (6.1.xx is recommended) - using armbianmonitor would identify that. Alternatively $ ls -l /dev/mpp_service crw-rw---- 1 root video 241, 0 Sep 9 21:43 /dev/mpp_service $ uname -a Linux t6 6.1.75-vendor-rk35xx #1 SMP Mon Sep 2 13:12:21 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux