eselarm

I dumped all your text in ChatGPT and got enough answers; maybe do the same

I now actually see after some more reading and checking other SoC's that the CPU's in the A733 must start the kernel at EL2. See also ARM reference doc: 102412_0103_01_en So also 5.x kernel should work if EL2 I think If the A733 has not implemented EL2 and EL3 as could be the case as suggested in ARM reference doc, no KVM. See chapter6: As it is Allwinner, I won't be surprised, but wait and see what Radxa will come up with.

Have you also looked at the clocks? I have several NanoPi-NEO's (since around 2021 I think), H3 SoC, never had any overheating issues. I actually did some measurements recently and surprisingly low power, I had expected more. Clock stays at 480 mostly. I see the Duo2 is H3, Duo I don't see on FriendlyElec's site. But quite different HW/board. Only thing I could think of maybe is that I removed ( apt purge --autoremove) cpufrequtils after in-place upgrade from Bookworm to Trixie. Have not looked at it any further, it just is not in my vanilla Debian Bookworm -> Trixie, so just blind purge I thought. Still all fine, also with 6.18 kernel: # uname -a Linux raspi2 6.18.2-edge-sunxi #1 SMP Thu Dec 18 13:03:43 UTC 2025 armv7l GNU/Linux # cat /sys/class/regulator/regulator.?/microvolts 3000000 3300000 5000000 1100000 # cat /sys/class/thermal/thermal_zone0/temp 27116

May boot from new / known-to-work Armbian on SD-card and use command: sudo lsblk and/or sudo lsblk -f to see what is what. mmcblk numbers have swapped sometime in the past years, so indeed even if you know enough about Linux, mixing numbers might be a disater because you would overwrite the runnig installation. That might also be a reason why tooling might refuse or not list as there is a risk of having it wrong. But you should clean-up the 100% full filesystem. It will take time figuring out what should be deleted, but so does going to the toilet as well. It has to be done, cannot assume there is endless space.

Radxa staff actually does not answer the original question w.r.t. Allwinner A733 HW virtualization, it is just that kernel config has it. But I see from releases 'bullseye', that does not look good at all. In theory, that means 5.10 kernel, and oldoldstable libvirtd/KVM/QEMU etc. As this SoC is bigLITTLE, (Cortex-A76 Cortex-A55), starting a qemu-system-aarch64 process will pick some of those cores randomly, assuming you have more than 1 vCore (smp option > 1) . Kernel older than 6.8 or so does not support moving between an A76 and an A55. That is the same for Rockchips (RK3588). It took me quite a while before I discovered that this is known behavior. So on for example on vendor rk35xx 6.1.115, I pin vCPUs, can be done in virt-manager GUI xml config or cmdline via taskset. As easy test, use -smp 1, then it should work. mainline kernel CPU numbers are such that simplest/lowest CPU's get lowest number. That might be the other way around on 6.1 or older downstream/vendor/BSP kernels. On an RK3588, a 2-core VM with 2x A76 and 512MiB is done by: taskset --cpu-list 6-7 qemu-system-aarch64 -M virt -cpu host -enable-kvm -m 512 -smp 2 \ -bios u-boot.bin \ -drive if=none,file=armbian.img,format=raw,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -netdev bridge,id=hn1 -device virtio-net,netdev=hn1 \ -nographic Same should work on A733

log says: No space left on device So you need to look at that, remove unneeded stuff etc. Also check the output of df Maybe something else is wrong

OrangePi in general is bad support, as also is stated on the image download page. For just driving a relay, so a pin change between high and low, you first need to select which pin from the GPIO header you want to use. You can see what are probably generic GPIO by default from picture here: http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-Zero-2W.html In the latest image, I see there is no real support for OrangePi02W, only H5 and A64, not the actual H618 (it seems to use H616, so also that might lead to issues). You can look in file maybe, if you want other then defaults: /boot/dtb/allwinner/overlay/README.sun50i-H5-overlays I have older 32-bit Allwinner things, H3 for example. Analog and SPDIF audio works great there, that is why I bought those mainly. Also GPIO6 I use for driving a switch (via extra resistors and some MOSFET/TRIAC). I did some C-code and got working temp sensor and switch, see lgio code https://abyz.me.uk/lg/download.html But currently for years already in bash script: init: test -f /sys/class/gpio/gpio6/value && echo 6 > /sys/class/gpio/unexport echo 6 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio6/direction chown root:gpio /sys/class/gpio/gpio6/value chmod g+w /sys/class/gpio/gpio6/value on: gpioset gpiochip0 6=1 off: gpioset gpiochip0 6=0 This still works since Armbian Buster, now kernel 6.12. Not tested yet with 6.18

You have to allocate the I/O pins you want to use and how you want to use them yourself, can be done in armbianEnv.txt. A generic image cannot know what you want and what is connected to which I/O pins. GPIO is not like USB or PCIe that is can be automatically let its connected hardware enumerate. Also old Linux behavior w.r.t. GPIO is gone. You fundamentally need to open it, keep it operational with handle, in your code. Like you open a file when you want to read or write. Python might do that for you, but for C-code maybe look at lgio. So maybe tell first what you want to achieve, is it a temperature sensor maybe, or control a MOSFET or relay, etc.

There is at least no primary GPT, all zeros from 0x200-0x20000 Fixed with: # gdisk Armbian_community_26.2.0-trunk.130_Radxa-cubie-a5e_trixie_edge_6.18.2_minimal.img GPT fdisk (gdisk) version 1.0.10 Caution: invalid main GPT header, but valid backup; regenerating main header from backup! Warning: Invalid CRC on main header data; loaded backup partition table. Warning! Main and backup partition tables differ! Use the 'c' and 'e' options on the recovery & transformation menu to examine the two tables. Warning! Main partition table CRC mismatch! Loaded backup partition table instead of main partition table! Warning! One or more CRCs don't match. You should repair the disk! Main header: ERROR Backup header: OK Main partition table: ERROR Backup partition table: OK Partition table scan: MBR: protective BSD: not present APM: not present GPT: damaged **************************************************************************** Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk verification and recovery are STRONGLY recommended. **************************************************************************** Command (? for help): w Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!! Do you want to proceed? (Y/N): y OK; writing new GUID partition table (GPT) to Armbian_community_26.2.0-trunk.130_Radxa-cubie-a5e_trixie_edge_6.18.2_minimal.img. Warning: The kernel is still using the old partition table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) The operation has completed successfully.

OK, I have the following in my test NanoPi-NEO (using 6.18 kernel): U-Boot SPL 2024.01-armbian-2024.01-S866c-P7738-Ha5c2-V2b78-Bb703-R448a (Mar 09 2025 - 03:54:42 +0000) Same base, but it is older and anyway different hardware, although H3 SoC. I have no more ideas why you need that extra kernel cmdline statement. I think I have seen it as well for another board/SoC, but does not ring a bell.

I do not see something clearly wrong, but likely is is a newer U-Boot, maybe something wrong there; version in SD-card you can show with: dd if=/dev/mmcblk0 count=32k status=none | strings | grep "U-Boot SPL"

I think it must be /boot/armbianEnv.txt Besides that, I never had this issue with my 5 NanoPi-NEO boards, originally Armbian Buster, always in-place upgraded. Also 1 now tested with kernel 6.18, now issues. So I think you maybe need to look at what U-Boot you use, what kernel is it and logs ( all via armbianmonitor -u )

That the Helios64 SW/firmware did sequencing of 3.5inch HDD spin-up is indeed a good method to limit the maximum current draw. I do not know how power architecture is done in Helios64, but w.r.t. 3.5inch disks, so the 12V power need, you might avoid letting the current of the 12V flow through the SBC/motherboard. It is not needed, there might be connectors, still it is not needed. Even for traditional x86 PCs, 12V (and 5V as well) comes straight from the PSU, that is 100-1000W or so usually. The 12V also does not need to be exactly 12V, I feed a 4TB WD HDD from a 12V car battery in the field, is solar powered and 10 years old or so. Due to battery wear out, it sees a voltage of 10.5-14 Volts or so. No problem. 5V for SBC and some other small stuff is via a 3A DC/DC module. A car battery (72Ah or so) should have no issue with spinning up a handfull of 3.5inch HDDs simultaneously. The PCIe-to-SATA chips support hotplug, so you could use some P-MOSFETs or so to have GPIO-controlled powerswitch, but is of course electronics circuit design and soldering etc. Also maybe think if you need all that 5 HDDs (and at the same time) and with a RK3588 SoCo that can go as low as 1.5Watt idle. 5 spinning disks is 20W or so.

My NanoPi-R6C came with FriendlyWRT pre-installed (OpenWRT variant) and I bought it 2 years ago partly also because I had a Samsumg 970 Evo NVME that needed a computer wrapped around it. I do not use images, instead root-filesystems (Btrfs). I Initially kept the FriendlyElec U-Boot, with all rest on NVME. Now still use the same principle, but EDK2-UEFI v1.1 as bootloader in eMMC and Armbian Trixie or Opensuse Tumbleweed with Armbian kernel and grub-efi. With latest u-boot (2026 rc2) I get no HDMI audio. I thought it was a power/reset issue, but also later tested again with complete un-powering first, but then also no HDMI audio. It might simply be a latency issue. Both older U-Boot and even much older FriendlyElec U-Boot as well as EDK2-UEFI initialize HDMI before the kernel and do simple 1080p60, so you also see the kernel being loaded, before KMS (re)-inits the HDMI. EDK2-UEFI has GUI for its settings, so no surprise it works there. For Jellyfin, I currently use a ROCK5B Armbian Trixie with Armbian vendor 6.1.115 kernel (also EDK2-UEFI bootloader). There were some issue with Jellyfin strreaming/transcoding, also on N100, I currently don't know why/what. The jellyfin-ffmpeg via CLI works great though, so about 5x realtime transcoding HEVC->H264. But Firefox on N100 or x5-Z8350 uses HEVC HW decoder, so no real need to do transcoding for me. LibreElec a month ago or so on NanoPi-R6C temporary booted from SD-card did do HW decoding OK, except for VP9 it was artifacts, not usable actually. So there is unfortunately no easy 1-size-fits-all currenlty. You can scan the forum, there are people who took unfinished patches and use very latest unstable Debian stuff, then things might work same as for x86.

If this fails on multiple build host environments, maybe check your network/internet connectivity. Else I don't really know what could be the cause. I use Armbian Aarch64 (RK3588s) with various tweaks ans kernels and it works fine for builds.

This suggests it is 5V only and also no USB-C PD. You should power a ROCK5 with higher voltage, then no issues, at least that is my experience and is also what you can see if you look at schematics. You can also read the end-user docs/wiki. ROCK3A, ROCK5B, NanoPi-R6C all have own step-down DC/DC converter on the board itself. The latter one for example has an 8A component for it. So it can make enough power from 20 or 15 Volt input at a perfect 5V internally for USB devices on its type-A ports, and also easily maintain its 3.3V and lower voltages for CPU etc. OrangePi is cheap, same as RaspberryPi. Those shift the powering (issues) to the end-user, meaning you need a stable enough 5V on the USB power input connector. A slight voltagedrop can lead to problems. But board itself is cheap. RPi5 requires a quite rare 5A capable 5V USB-C PD (RPI5), where the ROCK3A/5B can just be fed from any voltage between 9 and 20 Volt (see docs/wiki). If you use 5V, the on-board DC/DC step-down cannot do its work of course, so essentially bypassed. Why did you buy a ROCK5 then. Same as buying a car with combustion engine with empty fuel tank, instead put a horse in front to pull you forward from A to B. (Or get a bicycle). The (extra) horse is the 27W Pi5 PSU here, costed me 18 Euros, half the price of the ROCK3A. I put a fixed 12V on a USB-C connector, from an old card battery, that by itself is kept at about 12V by a 12V/10A generic powerbrick. Is also UPS then is no 230VAC mains. The Nanpi-R6C with latest U-Boot and latest mainline kernel does also do USB-C PD, so with a generic 45W USB-C PD PSU, is flips automatically to 15V on its USB-C input. With another 60W USB-C PD PSU it was 20V. ROCK5B should be able to do the same, but haven't tried as run 24/7 for months as home/house server.

Mainline 6.18 or 6.19 does only decoding accelerated, not encoding (yet) what is to great benefit of Jellyfin. Also for that transcoding, Jellyfin uses RKMPP, not V4l2. So 6.1.115 vendor kernel is what I use on the Jellyfin server (headless). For desktop RK3588, I use mainline 6.18.2 at the moment, brute force SW decoding, that works for me as content is max 1080p60 (HEVC or VP9 or H264).

See here, HW description bulletpoint 17 https://www.hardkernel.com/shop/odroid-m1s-with-4gbyte-ram/ Maybe it is also available on the 40-pins or 14-pins I/O headers, so a simple generic USB serial cable with jumper wires can be connected.

If this is something with languages: I remember Armbian has a preferences option in apt config somewhere 'no languages'. Is old memory, maybe changed nowadays. Maybe a hint where to look and what to try. It would actually be a Cinnamon issue then.

What is booted also depends on boot scripts (and what is in armbianEnv.txt). This might have changed. And also the U-Boot code on the SD-card (sits invisible between partition table and 1st partition, usually sector 34-32767) might be newer and assume other defaults, I don't know. You need serial console cable and loglevel set to 7 so you can see what is happening after power-on. But maybe something else is wrong, at least make sure you post relevant info here on the forum. You can look in /usr/lib/u-boot/platform_install.sh to see where U-Boot is written. Also if you look there you can find some version string, likely in your mtd0/SPI is older than on the SD-card.

But that means you have 2 bootloaders and also 2 bootscripts. That will cause confusion, is it no surprise you end up in initramfs. I do not know which one has priority for the OPI5, maybe it is variable, depending on something in hardware on the board. On my ROCK3A, I can place an optional jumper that disables mtd0/SPI, so only option is U-Boot from SD-card. You can interrupt U-Boot if you connect serial console cable and then manually load the OS from SD-card or NVME, but it is a lot of commands and you need to know or study what those do. If you want to run a new OS from SD-card, you need to change (all) boot.* + armbianEnv.txt files, such that there is only 1 set (from SD-card or from NVME). Also only 1 U-Boot is best, else it will stay confusing. So wipe the U-Boot on SD-card. Then place the correct UUID in armbianEnv.txt (the UUID from rootfs on SD-card). Alternatively, you can use extlinux.conf boot method, you need to create that yourself, I use it on some SBC's so I can test new kernels etc (select at power-on in U-Boot via serial console cable). Or you flash EDK2-UEFI in mtd0/SPI and radically change all to EFI en grub bootmanager. Needs all manual own actions, not an Armbian thing.

This is based on mines, running Armbian Trixie: - NM can work without dhclient, it has it DHCP internally as well. So maybe look at that instead of AI with old info and certainly no clue about a specific SBC - modern kernel it is end0 - systemd-networkd is also an option - you also might use ifupdown still, also not needed, NM can do internally as well

I am not sure if this will lead to problems. The SBC is a Radxa ROCK3A. It might be EVB was used for development and never changed. Maybe won't matter as later on kernel rock-3a dtb is loaded. But could be a reason for issues I saw (year ago) with mainline u-boot, therefor I use Radxa's one / legacy.

Maybe. If it is better you'll have to see. Install package 'linux-u-boot-rockpi-4c-edge' and with dpkg -L linux-u-boot-rockpi-4c-edge you can see where the u-boot binary is located, then: strings <u-boot binary> | grep armbian

I get this on a Debian Trixie VM allocated only 4x Cortex-A76 on ROCK5B 1048576+0 records in 1048576+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.5407 s, 236 MB/s 2097152+0 records in 2097152+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.24198 s, 253 MB/s Numbers are lower on RPi4B and ROCK3A. However, since in-place upgrade from Bookworm to Trixie, this slow ssh login is very noticeable and also rather annoying. So this is a Debian issue as far as I can see. I had the same Debian VM running on ROCK3A and was all nice with Bookworm, although only 1GB allocated and of course is 4x Cortex-A55, so slow for crypto and compression (real-time Zstd). Just after upgrade and reboot into Trixie I spent a lot of time trying to figure out why ssh login was so delayed/slow. Also noticeable that it was random, sometimes it was OK, mostly took multiple seconds. I did strace sshd and I saw just delay, waiting time in the process. More I could not figure out, would take me too much time and I had no clue where to look. The plan was anyway to move the VM (and NVME and HDD, the whole NAS setup) to ROCK5B so that is what I did then the next day or so. On the ROCK5B, I do not notice the delay that much, but it seems still to be there. I have no clue why. I use quite a lot ssh unattended, so that I don't care and notice. So I basically still do not know what this is, I have not searched for It, I just see this topic and I recognise it.