eselarm

I do not have this OP6plus, but have been looking at some similar Cix CPU based things. This thing can be treated as an x86_64 computer, so roughly 2 decades of issues with getting Linux to run on PC's should apply. Like for example endless issues with NVIDIA drivers/GPUs. 'factory defaults' is difficult to base upon as the version of the (closed-source?) factory firmware is unknown, you need to mention that in theory. But simpler things might be wrong, so it is a matter of enabling more logging, so you and forum users can see what is actually happening. I think it is not dead/frozen, just some issue with graphics subystem, can be setting, is very common problem. I hope you have it networked, so then the lowest effort is to login via ssh with the default root:1234 as soon as possible. I did that for an old 32-bit system where I generated my own image, UEFI and GRUB based. The problem with Armbian GRUB based is that the GRUB timeout for displaying the menu is set to 0, so you see and have no easy way to interrupt boot and ad-hoc edit the boot cmdline by adding loglevel=7 for example. Or have you seen a GRUB menu and just waited the default 5 seconds (the standard Debian that is overruled with 0 by Armbian custom GRUB script generation) ? There plenty of ways to approach, I would edit the rootfs /boot/grub/grub.cfg in another computer, so you are not left in the dark. But I don't know how easy that is for you to do. A serial console/debug cable is the best option traditionally.

What repo are you using then? I see this on mine: ~# apt list -i | grep linux-u-boot-rock-5b linux-u-boot-rock-5b-edge/trixie,now 26.8.3 arm64 [installed] ~# strings /usr/lib/linux-u-boot-edge-rock-5b/u-boot-rockchip-spi.bin | grep "U-Boot SPL 20" U-Boot SPL 2026.01_armbian-2026.01-S127a-Pab8a-Hc429-Vc955-B5da4-R448a (Aug 14 2026 - 13:24:43 +0000)Might be bit out-of-date as I use apt pinning, but: ~# cat /etc/os-release PRETTY_NAME="Armbian 26.11.0 trixie"EDIT: OK I see current is 2017.09 based when I do a test install of that package: Armbian 'uboot-rock-5b-current' for '2017.09-S39cd-P2e20-Hf5b5-V172f-B5da4-R448a': 'postinst' starting.So you can use that, depends on what you want/do with your ROCK5B.

As sort of conclusion, whether wanting grub-efi or not, there is another discovery w.r.t. DS18B20 temperature sensor(s) hooked up to 1-wire. On the Allwinner H3 the default SoC pad/pin is PD14 but that is not wired on the NanoPi-NEO. Via U-Boot scripting, including the fixup.scr and armbianEnv.txt (see boot.cmd how it works) I select PG11. However, extlinux bootmethod that I tend to use besides EFI in KVM, does not support parameter like this. And grub-efi when in KVM needs valid EFI partition which confuses modern U-Boot in a standard configuration. I managed to build a 7.3.3 sunxi kernel+dtbo with that PG11 as default, but it is by hacking the already downloaded sun8i-h3-w1-gpio.dtso file. I made also a patch via kernel-patch first, but I understand now that this patch is against the mainline kernel and not on top of or after the sunxi Armbian overlays for 32-bit. At least it does not work. Maybe I do something wrong w.r.t. Armbian Build, but I think I would need something like 'patch the armbian patch'. Anyway, 1 reason an extra FAT formatted boot partition is used for computers, is that Windows cannot handle Linux filesystems. But I do not use Windows, except a few times per year in a KVM on x86_64 to scan/digitize paper and maybe some unknown old electronics that has no Linux user program. This also means, if kernel crash due to overlay and/or specific HW, extlinux cannot be used to select older kernel ad-hoc. With boot.scr, it would need break autoboot via serial console and then select/load a previous kernel etc via a sequence of u-boot commands, which I once did, but all forgotten now, was in relation to soldered eMMC. For SD-cards, way easier to take out SD-card of-course unless you have glued it which I read once someone did. So I now use this on one of my 24/7 NanoPi-NEO's with just the standard boot.scr+ambianEnv.txt: # gdisk -l /dev/mmcblk0 GPT fdisk (gdisk) version 1.0.10 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/mmcblk0: 62357504 sectors, 29.7 GiB Sector size (logical/physical): 512/512 bytes [...] Partition table holds up to 56 entries Main partition table begins at sector 2 and ends at sector 15 First usable sector is 16, last usable sector is 62357488 Partitions will be aligned on 16-sector boundaries Total free space is 49766385 sectors (23.7 GiB) Number Start (sector) End (sector) Size Code Name 1 532480 13115391 6.0 GiB 8300 Linux filesystem 5 16 8191 4.0 MiB B000 U-Boot boot loader gdisk x l allows sector alignment set to 1 gdisk x s allows resizing partition table I figured out that max 56 partitions is max, so up to sector 16 where the H3/sun8i bootloader starts. The Armbian H3 images rootfs starts at sector 8192. Also nice then to put some protection around that area with a type 0xB000 allocation. This way, it is a bit more convenient to wipe and write u-boot if you hate the dd numbering/arguments. For easy trimming free space (with blkdiscard), I also used to allocate a type 0 partition at the end with high number, but it assumes sub-optimal SD-card internal garbage collection or whatever code is in there. Also good for figuring out if SD-card is counterfeit or so. One normally should not worry about wear-leveling, maybe more about leaving hidden data there. Bigger rootfs is easiest as then fstrim.timer does the job, but old habit of keeping rootfs partition small also plays a role here for me.

The whole issue is that the script /usr/lib/armbian/armbian-led-state-restore.sh writes by itself to the .conf file located in /etc One thing it does is store the state of the LEDs, but storing a state shall not be done in /etc, but in /var, that confused me for months actually as I also did not get the blue blinking of my ROCK3A disabled. The thing is that, if the system does not shutdown the normal way, but for example just by a power-cut, the .conf file is or might be different from the situation when normal reboot. Especially when new/fresh images, that I might configure ran as a container first, it becomes a real mess and frustration, so I masked/disabled the Armbian service and also Armbian repo and made my own simple LED mute .service. After that I saw on another system via: snapper status <snapshot-before>..<snapshot-after> that the .conf file was re-created and I started to understand what happens in the restore script. So what to do? Why should a LED state be restored to something original/boot/kernel state every reboot when the end-user wants it in a state as configured once in /etc ?

The Armbian variant of 2017.09 based for ROCK5B has enough changes/patches such that it runs mainline based Armbian based rockchip64 kernels AFAIK. But never used it on my ROCK5B after many issues with 2017.09 flavors on my ROCK3A, which also was due to PSU (it wants >5V else what should the on-board DC/DC do then). Inside the EDK2 UEFI v1.1 binary there is also the lower level 2027.09 SPL still but the higher level / bigger functionality should be EDK2 based. I don't know exactly how it is all interacting. Maybe a warning is that this UEFI based only is fine if you do not need any special HW (from 40-pin header for example). Also if you use GRUB, there is no support for overlays, so the M.2 E-key slot just stays PCIE2x1 instead of SATA6 when you use the Radxa SATA M.2 E-key breakout adapter, which I do. But luckily that setting is in the EDK2 'BIOS' menu and stored in SPI-flash, so even without loading the devicetree, a rolling release distro generic aarch64 kernel (>= 6.19 works I know) and my 8T SATA HDD is there. I made a sort of automatic change in /etc/grub.d/10_linux so the .dtb was loaded, but then panic days later as my HDD kept ticking like bad sector (so dead I thought) when reboot. Of course it overwrites the devicetree done by EDK2 so default to PCIE2x1 for the multi-PHY in the RK35xx. Also, if boot.scr (or a valid extlinux folder) is found in the first/boot partition, EDK2 UEFI will fall back to that, so make sure to hide/move those. I see I still have this (gdisk -l /dev/nvme0n1) Number Start (sector) End (sector) Size Code Name 1 32768 1081343 512.0 MiB EA00 XBOOTLDR partition 2 1081344 26247167 12.0 GiB 8300 Linux filesystem 3 26247168 38830079 6.0 GiB 8300 Linux filesystem 4 38830080 63995903 12.0 GiB 8300 Linux filesystem 5 63995904 76578815 6.0 GiB 8300 Linux filesystem 6 76578816 391151615 150.0 GiB 8300 Linux filesystem 7 391151616 953188351 268.0 GiB 8E00 Linux LVM 8 953188352 976773119 11.2 GiB 8200 Linux swap This still works with native/plain/original U-Boot and rk35xx vendor based 6.1 kernel, but I think not in an ARM64 computer that has closed-source UEFI (e.g. like an x86 PC) as that needs ESP, so 0xEF00 instead of 0xEA00 But easy to change, same as un-hiding boot.scr etc. I actually think 0x0700 or 0xEF00 or 0xEA00 all should not matter for U-Boot, at least if there is just 1 path/choice. But if multi OS and the option to store bootpath in SPI-flash (run efibootmgr ), you also can have multiple EFI partitions in theory so not sure what the various bootloaders for ROCK5B will do then. But I keep it simple 1 shared EFI/boot partition. Another note is that (I think) Armbian Build on Debian Trixie cannot build (older) U-Boot like 2017.09 based, you need (older) Ubuntu for that. I use my ROCK5B Armbian Trixie for building u-boot and kernels, I have no Docker installed as that changes up my networking beyond my own understanding, so for stuff connected to internet, I removed all potential show-stoppers and complexity (for me).

Download the file from https://github.com/edk2-porting/edk2-rk3588/releases Then: sudo flashcp -v -p --erase-all ./rock-5b_UEFI_Release_v1.1.img /dev/mtd0 Or use armbian-install to write the u-boot binary from the currently installed u-boot package. The EDK2 bootloader is most convenient when you have/use dedicated boot/EFI system partition and GRUB as bootmanager, so just like a x86 PC, also nice setup screen before kernel etc loads. U-Boot need serial console cable to do things before kernel load, it usually does not initialize HDMI fast enough is my experience.

Yes, it is not even Armbian U-boot; ROCK5B is very well supported, any recent mainline based U-Boot will even run a normal Debian Sid kernel (7.3.3+deb14-arm64 currently, I have that running currently, not U-Boot in SPI-flash, but EDK2 EUFIv1.1). But for old BananaPi I used Armbian Build to have 2026.07 with some Btrfs compress fix, so boots/runs 7.3.3-edge-sunxi directly from rootfs all compressed zstd. I do not have eMMC module, only SPI-flash (and SD-card for emergencies maybe). So I am sure I only have 1 bootloader (in SPI-flash). You might have 2, also in eMMC. Make sure you wipe old/double/redundent ones so only '1 captain on the ship'.

I think it is clear now to me how the hardware is, I also took a look at https://www.friendlyelec.com/index.php?route=product/product&product_id=309 (scroll down to the PCB pictures layout and interfaces). Also your b1) and b3) info points help confirming and I see that this is yet another step in complexity (or just more options, it is great hardware) but I can't find where in Armbian config this is handled in a way similar to the script attached in the other topic related to Btrfs for rootfs. In addition I took a peek at the (for me) banned 'AI-bot' account 'Boardcon_yang' and again see rubbish hallucinations. I understand that Boardcon is a real company, but my take is to avoid that company as a plague because simply this is how they deal with individuals/humans then apparently. Also Armbian should do something about it. Same as AI generated videos/pictures that are on social media (I am not, all blocked, I even do not have a big-tech Microsoft github account), it should be marked as such. Else it will be like email spam boxes: block all except the ones clearly human still or just not use Armbian and this forum anymore. So back to the issue: Is a matter of what you want or more difficult, what is wanted/done by Armbian and the people/organizations/companies doing the financial backing. There are (I think) 6 Linux block devices that could contain the bootloader or a part of it (a version of U-Boot in this case): sda sdb sdc sdd SD-card SPI-NOR-flash sdd is new to me and don't know what that shall be used for. It can easily take months or years before it is known in general what is a practical way of working for an individual (so non-profit, users at home for example). For professionals/industry there might be a exchange of info under Non-Disclosure-Agreement, so can be all clear, like Android system builders. Those also need large volume management of systems, at least end-users are certainly not the admins of the things they use. It might be even forbidden by law as is known from telcos (depends on country). The question is what the ROM code in the RK3576 does based on how the M5 HW design is, it is usually some signal level that determines which device is read first or check for a bootloader of some stage. You need documentation then, look in schematics of the board, but then still it might be unclear what steps the ROM does at power-on. If you have used the board with other OS earlier, that one might have written a version of its bootloader to SPI-flash (/dev/mtd0) for example. Compared to other already well-know SoCs/boards like ROCK5B, it is clear that SPI-flash offers the best options like we know from PC's: So you have like a BIOS setup as it can store variables about the OS there. I do that on my ROCK5B as it has SPI-flash only (or SD-card). My NanoPi-R6C has no SPI-flash, just soldered eMMC and with the current U-Boot variants does not offer the variable storage, so I need a sort of own hack/method to switch OS. So for the M5, I would boot with Armbian from SD-card, then wipe all (boot) areas from all devices and use a manual method to flash the Armbian U-Boot to SPI-flash. That is different from what is done in the other topic as there a combination of sda and sdb is used and also is in the UFS install script for the M5. But also SPI install method is there. It is in /usr/lib/u-boot/platform_install.sh The file for SPI is then /usr/lib/linux-u-boot-current-nanopi-m5/u-boot-rockchip-spi.bin and command would be: flashcp -v -p --erase-all /usr/lib/linux-u-boot-current-nanopi-m5/u-boot-rockchip-spi.bin BUT I do not own an M5, so it is just based on what I did last week for my ROCK3A a few times with own build U-Boot (with Armbian build framework) and using also various kernels. Everything related to M5 fails for me as I do this trials in a quick container run. You need to read info and as long as it is unclear to you keep studying and/or wait until the armbian-config tool helps you doing it correctly. You are correct that the script in the other topic is mainly an issue about wanting Btrfs for rootfs. You might not need Btrfs for root now, but having it allows you to manage the installation (so Armbian in this case) and especially the sizes of the block devices/partitions all to be done in the running system. That saves you from quite some boot time issues, as for example you don't need another temporary OS/system to boot with, like it is known as 'Live-CD-ROM' for PC's for example. Also saves money as you can fit a lot more on 1 fast UFS or NVME etc. I use it on all computers, even decade old RaspberryPi1, so can do upgrades etc from my desk or while traveling by train remotely, SD-card just stays inserted and also board is kept powered on via PoE as it is outside in difficult place and might be bad weather.

quick check: # strings /usr/lib/linux-u-boot-vendor-cm3588-nas/u-boot-rockchip.bin | grep "U-Boot SPL 20" U-Boot SPL 2026.07_armbian-2026.07-Sece3-P1c54-H1a10-V102f-B5da4-R448a (Aug 14 2026 - 13:26:47 +0000) which is very recent, not the old 2017.09 we see still quite often for RK3588 based devices, so if also the binary is actually used for booting (so written in SPI-flash or other bootloader device area), then I would say new mainline based kernels should work.

It depends on bootloader and surroundings if it works without action and/or issues. So also DeviceTree and overlays (if you use them). In general, if the CM3588-NAS is considered as a traditional PC, so just 8-core ARM64 CPU and no special Rockchip function block like HW video encoder used/needed, it is no problem to use a latest mainline based 7.x kernel. Even simply vanilla Debian kernel from Debian Sid works fine. I do that for my RK3588 SBC's mostly as for example for Jellyfin I hardly have/watch video's that need HW based video encoding. I use EDK2-UEFI v1.1 as bootloader, then no issue to use 7.x kernels, but a recent U-Boot is also fine if headless (no HDMI at power on). I also use grub-efi, so also same as PC's. Make sure you understand and/or have that in-place, as it allow easy switching the used kernel at power-on, you might need a serial console in order not to be blind for what is happening and able so select adhoc.

UFS is presented as SCSI /dev/sdX kernel names and is not related to SATA (also USB-stick would appear as /dev/sdX name). NVME and SD-card/eMMC both use different names. I see from the script in https://forum.armbian.com/topic/60020-nanopi-m5-2651-ufs-install-btrfs-root-does-not-boot-and-manual-partition-layout-is-not-available that bootfs and rootfs is not special compared to just SD-card, but U-Boot seems different although all covered by the standard Armbian U-Boot install script function. The confusion might be, also for me as I don't own UFS, is the four different sdX devices. I have a similar issue with my NanoPi-R6C where, in the eMMC, there is also 2 extra bootX block devices that can be used for bootloader objects (A and B schemes etc). They are normally not used, but now for UFS maybe, I don't know for real, but from the script one can derive certain things. Also I have not looked into the mentioned 26.8.1 GNOME image w.r.t. the write_uboot_platform_ufs in /usr/lib/u-boot/platform_install.sh, but that is needed if I would own a M5. At the moment, I think more of the 4 sda, sdb, sdc, sdd devices (what is what), kernel might do random order, at least Debian based distros do that, I know openSUSE usually has the device named sda, so the first, for the OS and other HDD's or so in a computer sdb, sdc, sdd, etc. But to have it more predictable, there is: root@rock5b:/dev/disk# l total 0 drwxr-xr-x 9 root root 180 Oct 26 16:23 ./ drwxr-xr-x 20 root root 4.5K Oct 26 18:27 ../ drwxr-xr-x 2 root root 880 Oct 26 18:27 by-diskseq/ drwxr-xr-x 2 root root 2.0K Oct 26 18:27 by-id/ drwxr-xr-x 2 root root 160 Oct 26 18:27 by-label/ drwxr-xr-x 2 root root 240 Oct 26 18:27 by-partlabel/ drwxr-xr-x 2 root root 620 Oct 26 18:27 by-partuuid/ drwxr-xr-x 5 root root 1.2K Oct 26 18:27 by-path/ drwxr-xr-x 2 root root 240 Oct 26 18:27 by-uuid/ Example, yesterday, I had to use a 'by-partuuid' path for iSCSI target in my ROCK5B as the underlying Samsung SSD is virtualized now (so /dev/vda instead of /dev/sda) and the 'by-id' is empty then.

Done this, with the difference no local hacking grub.sh anymore as $ARCH=arm64 (so no failure where topic is about) AND this is with both PR#11072 (already merged) and PR#11084 in effect. The build option BOOTPART_REQUIRED=yes needs removed, so this: ./compile.sh build BOARD=rock-3a RELEASE=trixie BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=yes NETWORKING_STACK=systemd-networkd FIXED_IMAGE_SIZE=2048 BOOTFS_TYPE=fat ROOTFS_TYPE=btrfs BTRFS_COMPRESSION=zstd COMPRESS_OUTPUTIMAGE=sha EXTRAWIFI=no KERNEL_CONFIGURE=no KERNEL_BTF=no KERNEL_GIT=shallow ENABLE_EXTENSIONS=grub-with-dtb GRUB_FDT_FILE=rockchip/rk3568 -rock-3a.dtb UEFISIZE=100 succesfully generates the desired image. However, without detail knowhow about grub config revert to normal Debian, not a workable solution as terminal I/O is muted and grub menu skipped. As my real rock3a is busy/used (and also there is no (UEFI) bootloader build with the image), I started the image in a KVM I call 'armbian64' just swapping normally used image with this new build. The method is then to hit edit in grub menu and ad-hoc remove the devicetree line as that is for HW rock3a and KVM does not need any, just all virtio. But no grub menu, so same as for real nanopineo revert to standard Debian grub config with a few edits like loglevel=7. Then all fine. Good thing is that also this time, my VM is know by my router, so after with a bit of ssh wiping I could login as root:1234 and immediately fix the grub and serial stuff. I think the idea behind this terrible grub config (for me) is to have the same as U-Boot boot.scr: no debug scrolling, hopefully a logo and no kernel selection. That seems fine if the boards only option is UEFI and no U-Boot or free open source bootloder (e.g. RPI), but people use grub so they can make selections at boot/power-on, not only kernels, but also multiple OSses. Maybe not for tiny 10-year old SBC's, but certainly for high end like RK35xx.

Something happened to the file below while installing and remove packages: root@ekker:/etc# stat armbian-leds.conf File: armbian-leds.conf Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 0,28 Inode: 42402 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2026-10-23 14:39:59.268000002 +0000 Modify: 2026-10-23 14:39:53.194144084 +0000 Change: 2026-10-23 14:39:53.194144084 +0000 Birth: 2026-10-23 14:02:59.333152304 +0000 root@ekker:/etc# date Fri Oct 23 15:10:41 UTC 2026 So now with empty file of course no leds problem. I will add snapper and change subvols so I can better track what is happening.

I see it is actually a failure for the 7.3.0-rc7-edge-sunxi kernel (with my extra setting CONFIG_EFI=y), just full log from armbian-debug here: https://paste.armbian.com/ucitawavax [ 1.526902] leds-gpio leds: error -EBUSY: Failed to get GPIO '/leds/pwr' [ 1.526958] leds-gpio leds: probe with driver leds-gpio failed with error -16 and already: root@ekker:~# systemctl status armbian-led-state.service * armbian-led-state.service - Armbian leds state Loaded: loaded (/usr/lib/systemd/system/armbian-led-state.service; enabled; preset: enabled) Active: active (exited) since Fri 2026-10-23 14:03:16 UTC; 27min ago Invocation: b071139a57234fb7a65ef3dc88c4534d Process: 376 ExecStart=/usr/lib/armbian/armbian-led-state-restore.sh (code=exited, status=0/SUCCESS) Main PID: 376 (code=exited, status=0/SUCCESS) Mem peak: 1.3M CPU: 485ms Oct 23 14:03:06 ekker systemd[1]: Starting armbian-led-state.service - Armbian leds state... Oct 23 14:03:16 ekker armbian-led-state-restore.sh[376]: warning: /sys/class/leds/nanopi:blue:status/trigger could not be restored Oct 23 14:03:16 ekker armbian-led-state-restore.sh[376]: warning: /sys/class/leds/nanopi:blue:status/invert could not be restored Oct 23 14:03:16 ekker armbian-led-state-restore.sh[376]: warning: /sys/class/leds/nanopi:green:pwr/trigger could not be restored Oct 23 14:03:16 ekker armbian-led-state-restore.sh[376]: warning: /sys/class/leds/nanopi:green:pwr/brightness could not be restored Oct 23 14:03:16 ekker systemd[1]: Finished armbian-led-state.service - Armbian leds state. So seems a matter of a new or wrong path for the leds or pins, where the older Debian kernel does is correct, also the leds config file is correct according to my understanding. Long time ago I disabled blue led of my rock-3a, so remenber a bit. Probably I install current sunxi as well (6.18) and see what that does. EDIT: sorry too fast, this won't work as it has no EFI enabled, so needs then booted via boot.scr or extlinux

To my surprise, the board also boots OK with the standard Debian Trixie 6.12.113+deb13-armmp kernel. Noticeable difference is quite a long pause between EFI_GRUB stub messages and kernel starting to spit out messages and that the red LED is constant on and green blinking as sort of activity. I prefer no LEDs on at all during normal operation, but this is a minor issue and likely some Armbian patch for sunxi puts them off. Of course Debian delivers no overlays, so the actual use-case is then 0, as I need analog-codec, SPDIF, 1-wire at leasta and some extra UART as well, all from the header pins, but it is great that it behaves now 'as a small UEFI Debian computer'.