eselarm

While doing some testing of multiple things I decided to build 2 images, fresh/new for my nanopineo's also trying to have the resulting image as close as possible to what I have running on the nanopineo's for years since 2022 or so. That was originally Armbian Buster and I have been tweaking the installations to match other computer installations. Main thing is split the root partitions into a rootfs (Btrfs) and a bootfs (Ext4). More recently, I did more changes, such that I can run the whole image as KVM and/or systemd-nspawn container. The 1st image was adding extension 'u-boot-menu'; build ended in success, but have not tested it on HW. I saw in extlinux.conf that there was no 'FDT' line (with sun8i-h3-nanopi-neo.dtb), which I did ad myself in own extlinux testting/semi-automatic .conf generation, but as BOARD=nanopineo, the U-Boot can know a default to be loaded, or nothing at all as the DT in the U-Boot is likely good enough or almost the same as th eone from kernel, but maybe I test/challenge that later. The 2nd image build was just 'u-boot-menu' replaced by 'grub-with-dtb': cd /local/s0/armbuild/ sudo btrfs subvolume create nanopineo sudo chown 1000:1000 nanopineo cd nanopineo git clone https://github.com/armbian/build cd build ./compile.sh \ BOARD=nanopineo \ RELEASE=trixie \ BRANCH=edge \ BUILD_DESKTOP=no \ BUILD_MINIMAL=yes \ NETWORKING_STACK=systemd-networkd \ FIXED_IMAGE_SIZE=2G \ IMAGE_PARTITION_TABLE=gpt \ BOOTPART_REQUIRED=yes \ BOOTSIZE=256 \ 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=watchdog,net-systemd-networkd,uboot-btrfs,grub-with-dtb It then fails with: [🔨] E: Unable to locate package grub-efi-armhf-bin [🔨] E: Unable to locate package grub-efi-armhf The issue here is that the Debian package must be: grub-efi-arm Also I now remember an issue from years ago when I made a non-EFI system UEFI bootable, must have been RPi thing or so, but also did it several times for x86. AFAIR if only grub-efi-arm and grub-efi-arm-bin, you get into trouble later on, can be years later when dist-upgrading in-place. So I just do 'apt install grub-efi' which then works fine as is pulls in also some dependencies. Not 'efibootmgr', that is just recommended, and I add that manually as most systems allow storing boot URL's in SPI-flash or so, certainly the KVM ones where machine is using EDK2 UEFI, which I use extensively. So it seems to me that this is an architecture naming or aliasing issue, like we have amd64 vs. x86-64 vs. x86_64 and arm64 vs. aarch64 If just 'grub-efi' that also works for riscv I guess, so avoiding this naming/aliasing issue and also better future proof. It might be that dependencies are not supported in image building, I don't know enough about that to judge. I have also not looked in detail at size impact, but it is relative I would say. There is plenty of other issues that claim more space or can reduce way more. There were more issues, but I solved those via trial-error, no show-stoppers. Although topic tag NanoPi-NEO, this is more like an Armbian Build issue, but for me it is about my 5 NanoPi-NEO's that are still great (and still overkill for their 4x Cortex-A7), but they are still Debian 32-bit ARMv7, not like unsupported RPi0/1 single-core ARMv6 (arm11* or older). A reason for wanting EFI bootloader is that upgrading/testing can by done in a KVM running on RPi4 (fast USB3-SSD) or ROCK3A (fast PCI-Ev3x2 NVMe) while using (differential) btrfs send|receive, which is way faster than on SD-cards en real HW. The other option is via U-Boot (QEMU -enable-kvm option), is supported for 64-bit in Armbian by BOARD=qemu-uboot-arm64, not for 32-bit.

OK, I already wondered why /dev/sda for OS and not /dev/mmcblk0, but I thought maybe the Qualcomm HW/FW was due to that, I have PC's doing it like that, but this explains why your files seemed to have disappeared. Maybe also a good hint/wake-up call to use some scripts or so to do auto-backup on regular intervals via network. I have that for a decade or so, just use old slow HDD's for that. If you use Btrfs as rootfs and snapper or so to make last-known-good snapshots, you can transfer those in the background. Also works fine for databases, is atomic, perfect reliability, much better than rsync based when doing that in a running system. A tool call 'btrbk' is standard in Debian, has that all automated: # apt list btrbk btrbk/stable 0.32.6-2 all

This Q8B has: [ 0.000000] efi: EFI v2.7 by Qualcomm Technologies, Inc. That is not something available in source-code, so who knows what's happens inside. On the other hand, it would be strange that firmware would wipe the whole storage device for the OS. You should think and mention what you did as steps. From what I see is that you did overwrite your SD-card or storage yourself. From RPi forum I know many people use the word 'update' meaning then just overwrite the SD-card with a new image, using some other computer and an imager program. That is then your own fault. A powerful SBC/computer like Q8B can be updated without wiping and 'burning' new image. Instead, you should use a CLI tool 'apt' or GUI tool 'Discover' to get just newer version of various software/system/kernel packages. You can simply keep the SD-card inserted. That is anyway needed when OS runs from fixed soldered eMMC. But there are also people who just remove NVME/SSD from their SBC/computer so they can write ('burn') an new image to it (as they only know that from SD-cards).

I have a ROCK5B running 24/7 as server (custom powering/UPS) for NAS, KVM, and has EDK2 UEFI v1.1 in MTD/SPI-flash, initially set to 'vendor' so I could boot vendor 6.1.x based kernel, but set to- and using mainline based since kernel 6.19 was released. This can be the Armbian -rockchip64 variant (edge or bleedingedge), but normally Debian Sid standard arm64 kernel (done via apt pinning), now at 7.2.8 and not a single issue, all works as expected. Of course certain RK vendor features like HW video encoding don't work, but I find it more important that I use a mainline based kernel. The same ROCK5B also can boot vanilla Opensuse Tumbleweed, it can even boot from an USB installer stick and install the traditional way, like for a PC. That then needs the boot partition to be FAT32 formatted, either for grub-efi or grub-bls or systemd-boot. AFAIR EDK2 UEFI v1.1 can read Ext4, but not sure. For generic UEFI capable computers, you cannot assume that, so I simply settled for 1 FAT32 partition, 1 Btrfs rootfs partition and a swap partition. I all constructed that manually as images don't work if you want to run more than 1 Linux distro (or any other OS, like FreeBSD or MS-Windows). I do not know if BOOTPART_REQUIRED=yes implies FAT32 formatted and tagged type ESP (0xEF00). Last time I used it it was XBOOTLDR type, not something a PC or RPi4/5 or EDK2 used for libvirt/KVM/QEMU accepts. If you never clone systems to other ARM SoCs it might not matter, but I keep all the same/aligned, so 'pure UEFI' might mean something else for you than for me. For example, the rootfs running on the ROCK5B will run unmodified on my RPI4 as I also use EDK2 UEFI there. Same for a testing clone in a KVM on NanoPi-R6C for example. The DTB included in EDK2 UEFI v1.1 is kernel 6.10 based AFAIR, that is good enough for all-round Linux if enough RK3588 options are enabled in the kernel, which is of course the case for Armbian -rockchip64 kernels but also for rolling release/latest distro kernels. So in practice, I don't see/notice a difference between 7.2.x Armbian rockchip64 and 7.2.x Debian Sid arm64 and 7.2.x Opensuse Tumbleweed aarch64 and 7.2.x Armbian uefi-arm64. There are big differences, but will need looking into the respective kernel config files. I see all options are listed here: https://docs.armbian.com/build-framework/extensions/list/ So is a matter of reading. Maybe I do a test build for my ROCK5B and see if I can generate it the way I use and have it. I remember the grub-with-dtb is not compatible with how I want/use DTB's but it should work. Also uboot-btrfs option is great for smaller SBC's, no need to manually build U-Boot from denx.de what I did in the past. If 'something with grub' is done or installed, you can assume that U-Boot is not written into the image as that simply would ruin the desired behavior. Unless you have or want 'grub-uboot' package installed, but I think this is not supported by Armbian Build.

yes as I mentioned; an RK3588 wirh EDK2 in SPI will load U-Boot from SD-card (if it is there) as I mentioned, wipe U-Boot from SD-card; use dd to zero sectors 34-32767. But maybe first make clear what partitions you have, for example use: sudo lsblk --raw --bytes --output SIZE,START,NAME,FSTYPE,LABEL,UUID,MOUNTPOINTS /dev/mmcblk0

If you use this instead of BOARD=uefi-arm64 the image will be tailored for rock-5-itx and contain the U-Boot binary on the SD-card (written between sectors 34-32k ) and the EDK2 in the SPI will detect that and chainload that U-Boot. Also then that U-boot will find boot.scr which takes precedence over generic UEFI via file efi/boot/bootaa64.efi. So wipe the U-Boot would make EDK2 use itself and use the EFI bootmethod. Or rename/hide boot.scr, then the U-Boot is still used, but it will then use its EFI loader to also load efi/boot/bootaa64.efi but it usually does not initialize non-critical things like HDMI, so you might see blank screen first. In general, Armbian mainlinae based kernels, at least rockcchip64, understands all about UEFI, so you can keep the image or work done so far. You can simply add a general arm65 kernel or so, if new enough, it will include all drivers/HW about RK3588. I have the ROCK5B, is very flexible, same as the ITX.

There is indeed no nanopineo image on the main download page. I remember there was only rolling release, maybe image creation failed so then I think automatically not there/visible. The build definition is there: https://github.com/armbian/build/blob/main/config/boards/nanopineo.csc But if you just need the original or an original boot.cmd (so some version), it is in the BSP: armbian-bsp-cli-nanopineo-current/trixie,now 26.8.3 armhf [installed] # dpkg -L armbian-bsp-cli-nanopineo-current | grep boot.cmd /usr/share/armbian/boot.cmd

I did 2 runs with kernel 7.3.0-rc3-bleedingedge-rockchip64: 1st compiled with 'CONFIG_SCHED_CLUSTER is not set' 2nd compiled with 'CONFIG_SCHED_CLUSTER=y' So command as root: openssl speed -multi 8 rsa md5 sha256 sha512 aes sha1 camellia des rmd160 > $(timestamp).txt 2>&1 # diff -y -W 190 20260918_101405.txt 20260918_131402.txt md5 195473.11k 649713.49k 1552381.95k 2399496.19k 2867533.14k 2907575.64k | md5 193680.95k 643423.83k 1545036.12k 2381227.69k 2787740.33k 2907422.72k sha1 244179.63k 895310.46k 2693081.17k 5312768.68k 7934184.11k 8319795.20k | sha1 238851.57k 889777.58k 2673776.90k 5448719.02k 7900075.35k 8331236.69k rmd160 160717.62k 459518.78k 998510.25k 1421213.35k 1624244.22k 1641054.21k | rmd160 158611.37k 457548.65k 995554.05k 1421269.33k 1626974.89k 1643954.18k sha256 244299.85k 904019.26k 2719061.16k 5515426.13k 8056171.18k 8333934.59k | sha256 240987.41k 894283.18k 2696836.69k 5502382.08k 8063797.93k 8348718.42k sha512 132576.50k 530496.13k 1072615.51k 1729068.37k 2108967.59k 2143742.63k | sha512 131973.71k 526479.34k 1071986.69k 1730009.43k 2112348.16k 2146364.07k des-cbc 0.00 0.00 0.00 0.00 0.00 0.00 des-cbc 0.00 0.00 0.00 0.00 0.00 0.00 des-ede3 126802.83k 131960.75k 133454.93k 133826.22k 133958.31k 133918.53k | des-ede3 126945.35k 132138.60k 133681.92k 134063.45k 134160.38k 134142.38k aes-128-cbc 2749082.15k 6362386.43k 9682607.36k 11434917.55k 12150382.59k 12211273.73k | aes-128-cbc 2760766.55k 6371641.15k 9690578.60k 11451418.28k 12167091.54k 12230066.18k aes-192-cbc 2626037.58k 5604254.76k 8093569.28k 9210415.45k 9697626.79k 9734498.99k | aes-192-cbc 2632188.38k 5580423.04k 8100798.89k 9222450.86k 9712006.49k 9748419.93k aes-256-cbc 2552706.54k 5102452.86k 7039338.75k 7876314.79k 8187565.40k 8212135.94k | aes-256-cbc 2558937.55k 5113163.04k 7050647.38k 7887683.93k 8199165.27k 8224549.55k camellia-128-cbc 557388.59k 649808.17k 678503.17k 688174.08k 690517.33k 690918.74 | camellia-128-cbc 558809.32k 650699.29k 679674.71k 689085.10k 691882.67k 691595.95 camellia-192-cbc 449286.66k 506755.63k 524808.96k 530548.39k 532198.74k 532239.70 | camellia-192-cbc 450000.65k 507649.49k 525672.28k 531326.29k 532916.91k 532938.75 camellia-256-cbc 447559.94k 506777.09k 524796.33k 530373.97k 532146.86k 531984.13 | camellia-256-cbc 448415.03k 507589.10k 525694.81k 531273.73k 532854.10k 532781.23 sign verify encrypt decrypt sign/s verify/s encr./s decr./s sign verify encrypt decrypt sign/s verify/s encr./s decr./s rsa 512 bits 0.000016s 0.000001s 0.000002s 0.000018s 61323.6 704891.6 604001.5 54820.9 | rsa 512 bits 0.000016s 0.000001s 0.000002s 0.000018s 61356.9 720433.6 607364.1 54805.3 rsa 1024 bits 0.000088s 0.000004s 0.000005s 0.000090s 11420.5 222529.8 206941.7 11123.6 | rsa 1024 bits 0.000087s 0.000004s 0.000005s 0.000090s 11434.6 222705.9 206928.2 11133.9 rsa 2048 bits 0.000599s 0.000016s 0.000017s 0.000602s 1670.0 61262.5 59550.0 1661.5 | rsa 2048 bits 0.000598s 0.000016s 0.000017s 0.000601s 1671.7 61327.8 59606.2 1662.6 rsa 3072 bits 0.001849s 0.000036s 0.000036s 0.001852s 540.9 27990.4 27534.4 539.8 | rsa 3072 bits 0.001847s 0.000036s 0.000036s 0.001850s 541.4 28020.8 27561.6 540.5 rsa 4096 bits 0.004196s 0.000063s 0.000063s 0.004203s 238.3 15939.6 15763.5 237.9 | rsa 4096 bits 0.004192s 0.000063s 0.000063s 0.004197s 238.5 15957.3 15777.2 238.3 rsa 7680 bits 0.032663s 0.000217s 0.000218s 0.032670s 30.6 4607.5 4582.3 30.6 | rsa 7680 bits 0.032621s 0.000217s 0.000218s 0.032637s 30.7 4612.2 4587.5 30.6 rsa 15360 bits 0.199505s 0.000862s 0.000863s 0.193183s 5.0 1160.7 1158.6 5.2 | rsa 15360 bits 0.199280s 0.000860s 0.000862s 0.192447s 5.0 1162.8 1159.9 5.2 This time I had my NanoPi-R6C set to default to multi-user.target. All done via remote ssh. I had started a btop session as well but kept 800% all the time in both runs. I won't look back to previous kernels, so for me I don't see a clear bug, as at least even with this very artificial computing session (for me) I see no significant difference and I anyhow have no clue where or what to change in kernel code (the dev/torwalds branch).

Sofar I have not seen any testrun on a RK3588 with CONFIG_SCHED_CLUSTER=n, I don not know what is compiled/configured when it is not set. The other ROCK5B users likely have not used a kernel with CONFIG_SCHED_CLUSTER=n. I am not 100% sure that this is a bug; you want to see all cores loaded, but it does not mean that the total will be faster. It also depends on cache structures and levels and how clusters are interacting and are connected. You can have a look at Ampere SoC's versus SoC's from Intel. It might be that just not involving slow cores will result in better/higher cache hits for faster cores, just a thought. It might be that if you want a very long run with just dedicated CPU-bound tasks, that you actually should not do scheduling. So use other specific kernel, such that you anyhow get better results. It is more like a DSP then or sort of HW accelerator. I have been designing with- and using Cortex-R variants and also traditional DSP's, maybe that is why I think this.

Maybe an interesting thing is to do: # for i in 0 1 2 3 4 5 6 7 ; do cat /sys/devices/system/cpu/cpu$i/topology/cluster_id ; done 0 0 0 0 1 1 2 2 This is on RK3588 (and where the kernels have CONFIG_SCHED_CLUSTER=y All other 4-core SoC's I see the same for all 4 core, can be '-1' or '36' depending on bootloader and kernel. For RK3588 it reminds me of something I saw elsewhere in the DeviceTree or so AFAIR, is 3 power or clocking domains, but check yourself. Also Radxa Q6A would be interesting for listing this as well as the AllWinner 2xA76+6xA55 and other bigLITTLE SoC's.

After some thinking, I thought checking various kernel configs of various installs/distros: grep CONFIG_SCHED_CLUSTER /boot/config-* config-6.1.115-vendor-rk35xx:# CONFIG_SCHED_CLUSTER is not set config-6.1.172-vendor-rk35xx:# CONFIG_SCHED_CLUSTER is not set config-6.12.107+deb13-arm64:# CONFIG_SCHED_CLUSTER is not set config-6.18.44-current-rockchip64:CONFIG_SCHED_CLUSTER=y config-6.18.50+rpt-rpi-v8:CONFIG_SCHED_CLUSTER=y config-7.1.8-edge-rockchip64:CONFIG_SCHED_CLUSTER=y config-7.1.13+deb14-arm64:CONFIG_SCHED_CLUSTER=y config-7.1.13+deb14-arm64-16k:CONFIG_SCHED_CLUSTER=y config-7.2.4-1-default:CONFIG_SCHED_CLUSTER=y config-7.3.0-rc2-bleedingedge-rockchip64:CONFIG_SCHED_CLUSTER=y Maybe I use Armbian Build to just build latest 7.3 kernel with CONFIG_SCHED_CLUSTER=n, I need to read docs first as changing the .config did appear a bit confusing to me w.r.t. steps to take, but it should work. On the other hand, I have no clue what the effect is on let's say power-consumption, on average and also for various use-cases. For the NanoPi-R6C I am trying to get lowest idle power, which is still almost double for mainline kernels compared to vendor 6.1 last time I measured. Highest load on my NanoPi-R6C is building kernels and/or images, is anyway a constant high rate of starting and stopping processes (12 gcc threads/tasks by default) and the semi-permanent idling case for 1 or 2 cores would not happen.

I could reproduce on my NanoPi-R6C (RK3588S). It currently does nothing special other than showing an internal home automation website in a room where no-one really is. So I thought make it even more dedicated by doing first: 'systemctl isolate multi-user.target' so no firefox or so that can disturb. Then 2 ssh terminal sessions, 1 with 'btop' and 1 with 'openssl speed -multi 8' Ran for more than an hour, tempurature went up from 31 to 50 Celsius but still constant 8x 100% load. kernel: 7.3.0-rc2-bleedingedge-rockchip64 #1 SMP PREEMPT Sun Sep 6 22:07:20 UTC 2026 aarch64 GNU/Linux U-Boot: U-Boot SPL 2026.01_armbian-2026.01-S127a-Paca4-He05b-V36ee-B5da4-R448a (Aug 14 2026 - 13:26:35 +0000) I discovered I had not configured sysstat properly, not on this test computer, but also not on another server. I fixed it there, it was basically setting it to "true" in /etc/default/sysstat Then I did scp that file to the test computer still running the openssl test. BUT, when switching to its btop terminal, the 2 lowest numbered cores were idle and was kept like that. Until I restarted the openssl test, then again all 8 cores 100%. So my perception is that that some considerable action like a remote file copy disturbs the scheduling and it does not recover. My NanoPi-R6C has its Btrfs formatted rootfs on NVME. Another remarkable thing was that the date/time of the test computer was not correct, I see chrony did not correct it, it likely has to do with the brute-force switch from graphical to multi-user. Restart chronyd, then OK again; But don't think this impact scheduling issue discussed in this topic. /boot# grep CONFIG_SCHED_CLUSTER config-7.3.0-rc2-bleedingedge-rockchip64 CONFIG_SCHED_CLUSTER=y I could maybe run it also on my ROCK5B, uses other kernel and bootloader, but cannot do too much testing as it is my main server running 24/7 also running some KVM instances that probably make it too specific non-reproducible as I use CPU pinning there.

OK, I assumed you were using multi-device for rootfs, but the Btrfs filesystem is just something external I see. Qgroups/quota/squata should be disabled, unless you really need it.

A new trial with: U-Boot SPL 2026.01_armbian-2026.01-S127a-Paca4-He05b-V36ee-B5da4-R448a (Aug 14 2026 - 13:26:35 +0000) on otherwise blank SD-card has audio; (EDK2 UEFI v1.1 still in eMMC) Tested kernels: 7.1.12+deb14-arm64-16k 7.1.8-edge-rockchip64 7.3.0-rc2-bleedingedge-rockchip64 All 3 do audio, so case closed I would say. I also did a small modification to /etc/grub.d/10_linux such that a devicetree statement is used per kernel version, just using the .dtb from kernel package on rootfs. Needed a bit of a trick/symlinking as the new Debian Sid kernels store DTB files on other place than Armbian/Debian13.

There is likely a memory leak somewhere. Quick search does not reveal how much real RAM this XU4 has so please can you mention that. I only know it is 32-bit Samsung Exynos SoC. But 6GB of swap makes no sense I assume unless you have a very dedicated use-case with a small working-set but mayb lager virtual memory needed over a long period of time, much longer than lowest speed random 4kB I/O spoeed for your storage. Still no proper option if there is a memory leak. Main question is, how is your swap space organized? I hope you know Btrfs needs dedicated command to set up swapspace on the filesystem. But maybe you used separate swap partition, that is at least what I do on all computers, also on ancient RaspberryPi1 with 512M RAM and Btrfs rootfs with option compress-force=zstd for many years. Same for NanoPi-NEO's, including a variant with just 256M RAM. I disable Armbian zram swap mostly, so please also mention how and if you use that. The kernels on mentioned systems are 6.18 based and even 7.1.8-edge-sunxi runs without issues. But 6.6 and Exynos I am not so sure how robust/stable that is under load. Also what profile are you using? Please show output of: sudo btrfs device usage /