ozacas

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

Perhaps this would work for you? https://forum.armbian.com/topic/35168-generic-uefi-arm64-on-orangepi-5/

not able to resume wol g using an opi5+ with 6.11.0-rc4 edge kernel either.

I was able to use the vendor kernel on the following armbian system, but not opi5+ (rk3588 vendor kernel tho') acas@t6:~$ hostnamectl Static hostname: t6 Icon name: computer Machine ID: 8a38793a5b9543f2a8467803940786e8 Boot ID: bf966b42e4cb458f80e1ac5fad8d312b Operating System: Armbian-unofficial 24.8.0-trunk noble Kernel: Linux 6.1.75-vendor-rk35xx Architecture: arm64 however, upon restore some filesystems (usb) were missing so it was not an indentical state prior to the suspend.

I did that, but unfortunately no good either: either using wakeonlan to the MAC address or unicast to the IP address(+MAC) after changing to g. I'll try a different armbian box on the weekend, running the vendor kernel rather than edge.

For me with an opi5+ with kernel 6.10.1 (edge) - ethtool reports Supports Wake-on: pumbg Wake-on: d but I was not able to wake up the opi5+ in freeze with either wakeonlan or ping.

It looks like you booted from your SD card/USB rather than NVME. The /boot mountpoint still points to it as shown by lsblk. Remove the SD card?

Looks a bit odd ... perhaps try to repair something that has gone wrong by re-installing: sudo apt remove rockchip-multimedia-config # check that /etc/apt/sources.list.d/* has the correct ubuntu version ie. 'jammy' in your case not 'noble' or 'focal' sudo apt install rockchip-multimedia-config

Dont forget that you can now use the vendor 6.1.x kernel now for hardware acceleration using MPP - acas@t6:~$ ls -l /dev/rga crw-rw---- 1 root video 10, 121 Aug 17 15:12 /dev/rga acas@t6:~$ ls -l /dev/mpp_service crw-rw---- 1 root video 241, 0 Aug 17 15:12 /dev/mpp_service acas@t6:~$ uname -a Linux t6 6.1.75-vendor-rk35xx #1 SMP Thu Aug 8 17:42:28 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux acas@t6:~$ hostnamectl Static hostname: t6 Icon name: computer Machine ID: 8a38793a5b9543f2a8467803940786e8 Boot ID: 0840de02a4a249e884141dee335ede77 Operating System: Armbian-unofficial 24.8.0-trunk noble Kernel: Linux 6.1.75-vendor-rk35xx Architecture: arm64 dont need to be stuck on 5.10 for MPP support. Works fine with rkmppenc just as for kernel 5.10 series. The only quirk is that for Ubuntu 24.04 you have to hack/build rkmppenc from source at the moment.

Hi @ioncube Apologies for the late reply. Although not recommended practice, in my 24.8.0 build tree, I commented out the debsums invocation - i'm sure its fine 😀 The relevant part of lib/functions/rootfs/rootfs-create.sh in my build tree reads: if [[ "${DISTRIBUTION_STATUS}" == "supported" || "${FORCE_CHECK_MD5_PACKAGES:-"no"}" == "yes" ]]; then display_alert "Checking MD5 sum of installed packages" "debsums" "info" declare -g if_error_detail_message="Check MD5 sum of installed packages failed" #chroot_sdcard debsums --silent fi and that should prevent the problem. Perhaps settings FORCE_CHECK_MD5_PACKAGES=no during ./compile.sh invocation might work also? Its a difficult one to work around due to random mirrors, cache contents etc... very sporadic. Andrew

I also experienced this issue with a kde-plasma ubuntu 24.04 (noble image build of 24.8.0 edge) on an Orange Pi 5 plus (16gb). Disabling the above code per the commit avoided the issue and the result was a successful image generation.

Hi all, I'm using a UEFI based edge ubuntu 24.04 image which reported a kernel stack trace (system still seems functional and no ongoing issue/messages) - [ 22.382942] rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 5-.... } 6 jiffies s: 381 root: 0x20/. [ 22.382966] rcu: blocking rcu_node structures (internal RCU debug): [ 22.382972] Sending NMI from CPU 7 to CPUs 5: [ 22.382983] NMI backtrace for cpu 5 [ 22.382995] CPU: 5 PID: 92 Comm: kworker/u16:2 Tainted: G W 6.8.5-edge-arm64 #2 [ 22.383004] Hardware name: Orange Pi Orange Pi 5 Plus/Orange Pi 5 Plus, BIOS v0.9.1 10/12/2023 [ 22.383009] Workqueue: writeback wb_workfn (flush-252:1) [ 22.383024] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 22.383032] pc : FSE_buildCTable_wksp+0x1ac/0x340 [ 22.383041] lr : 0xffff80008847c0ee [ 22.383047] sp : ffff80008309b0e0 [ 22.383051] x29: ffff80008309b0e0 x28: ffff00010117424b x27: 0000000000000006 [ 22.383061] x26: ffff80008309b2f8 x25: 0000000000000007 x24: ffff00010117424b [ 22.383069] x23: 0000000000001db5 x22: ffff8000885b4ad8 x21: ffff800088479ed4 [ 22.383077] x20: 000000000000002c x19: 0101010101010101 x18: 0000000000000080 [ 22.383086] x17: 0000000000000080 x16: ffff80008847c0ee x15: 0000000000000080 [ 22.383094] x14: 0000000000000104 x13: ffff800088479ed4 x12: ffff80008847c094 [ 22.383103] x11: 000000000000002c x10: 0000000000000007 x9 : ffff80008847c100 [ 22.383111] x8 : 000000000000002c x7 : 000000000000002c x6 : ffff80008847c15c [ 22.383119] x5 : 0000000000000004 x4 : 0000000000000023 x3 : 00000000000000ee [ 22.383127] x2 : 0000000000000006 x1 : 0000000000000048 x0 : 000000000000006f [ 22.383135] Call trace: [ 22.383139] FSE_buildCTable_wksp+0x1ac/0x340 [ 22.383145] ZSTD_buildCTable+0x1d0/0x1e8 [ 22.383155] ZSTD_buildSequencesStatistics+0x31c/0x3b8 [ 22.383164] ZSTD_entropyCompressSeqStore_internal.constprop.0+0x170/0x2c0 [ 22.383172] ZSTD_compressBlock_internal+0x8c/0x200 [ 22.383180] ZSTD_compressContinue_internal+0x1e0/0xa88 [ 22.383187] ZSTD_compressEnd+0x34/0x1a0 [ 22.383195] ZSTD_compressStream2+0x514/0x600 [ 22.383203] ZSTD_compress2+0x68/0xb8 [ 22.383211] zstd_compress_cctx+0xa0/0xc0 [ 22.383216] __zstd_compress+0x70/0xc8 [zstd] [ 22.383232] zstd_compress+0x30/0x48 [zstd] [ 22.383245] crypto_comp_compress+0x20/0x38 [ 22.383251] zcomp_compress+0x2c/0x40 [zram] [ 22.383267] zram_submit_bio+0x3dc/0x9a0 [zram] [ 22.383280] __submit_bio+0xb4/0x148 [ 22.383290] submit_bio_noacct_nocheck+0x10c/0x2e8 [ 22.383299] submit_bio_noacct+0x184/0x530 [ 22.383308] submit_bio+0xa4/0x118 [ 22.383317] ext4_io_submit+0x38/0x68 [ 22.383324] ext4_do_writepages+0x568/0xb48 [ 22.383332] ext4_writepages+0xa4/0x138 [ 22.383340] do_writepages+0x90/0x210 [ 22.383346] __writeback_single_inode+0x48/0x400 [ 22.383352] writeback_sb_inodes+0x234/0x5e8 [ 22.383356] __writeback_inodes_wb+0x68/0x150 [ 22.383361] wb_writeback+0x294/0x3a0 [ 22.383366] wb_workfn+0x32c/0x5d0 [ 22.383371] process_one_work+0x164/0x360 [ 22.383378] worker_thread+0x2b8/0x510 [ 22.383384] kthread+0xec/0xf8 [ 22.383389] ret_from_fork+0x10/0x20 Details from armbianmonitor -u at https://paste.armbian.com/tuxuroyunu cheers Andrew

Maybe sudo armbianmonitor -u might help shed some light about what is going on - perhaps there is an issue with the device or driver? But no problems for me with the arm64 uefi image on my opi5+ 16GB - acas@opi:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS 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 1.8T 0 disk ├─nvme0n1p1 259:1 0 259M 0 part /boot/efi └─nvme0n1p2 259:2 0 1.8T 0 part /var/log.hdd /

Hi, i went a slightly different route and built a custom image for UEFI support based on current amazingfate armbian build framework (edge kernel 6.8.1 with EDK2 0.9.1) which works well - with NVME boot support based on your instructions above. I needed to enable USB2 support in UEFI settings for the slow usb stick boot, but i've ended up with a nicely working grub on an arm64 box which feels weird 😁 ... but lovely! https://paste.armbian.com/obowabadak has the output from armbianmonitor -u I did get a kernel stack trace about 8s into the kernel boot, but doesnt seem to impact anything. In my case I could not get the EDK2 img md5sum to match during the SPI flash... same result everytime. I just assumed a bit of trailing garbage was the culprit and it booted anyway 🤪

passively cooled for me, just the aluminium case. Hate fans 😁 No worries about the LED just wasnt what I expected would happen.

Builds cleanly. No issues rebooting into the revised kernel - but for me poweroff doesnt turn off the red LED on the front panel. Not sure whether this is expected. cheers Andrew

Not quite ten percent, but certainly active around the 5-6% range as reported by top(1) - see attached piccie. Thanks for the poweroff patch, i'll patch my kernel tree and see how it goes. cheers

Hi all, FWIW I had made a custom image (based on Ubuntu 24.04, edge kernel 6.8.0rc1) for orange pi 5 plus. Booted successfully from SD card, copy to EMMC using armbian-config and NVME support (although not used for booting). Working nicely - most things working, except for GPU accel and other bits. Oddly, poweroff does not - it reboots. Details of the opi5+ can be found at https://paste.armbian.com/ovoyijijic