eselarm

which image did you write to the SD-card ?

Various (newer) Armbian OS images do not have a separate boot partition (anymore). So there is then only 1 partition where also the DTB files are and it is Ext4 formatted, which Windows cannot read. So you need a Linux computer to do DTB file copy. You might encounter another problem, as usually a DTB file is paired with a matching kernel/version, but I do not know your files/version/images, also have no Amlogic box.

The SoC has an ADC AFAIR, but it is used for 'Recovery Key' AFAIR. Look in Radxa PCB schematics to be sure.

I see from: http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_5_Plus#Start_the_Orange_Pi_development_board what you mention: No PD, only 5V. That means that you cannot use a USB-C PD measurement device that shows actual voltage and current being used. But you need normal multimeter etc and maybe some wire soldering. It also means that a 65W PSU that does USB-C PD won't output more than 3A at 5V if it is standards compliant I think. If the OP5+ tends to want to draw more than 3A, the PSU might drop voltage (e.g. even 0), I don't know.

The big questionmark(s) are still then: - can that PSU offer 5A at 5V? - does your OP5+ (and your specific Armbian installation) negotiate 5A at 5V? - or maybe does it negotiate e.g. 15V with 3A ? I got also a 65W laptop type PSU, works fine with tablet/laptop, seen 15V being used. When using with a diskless (headless netboot netroot) RPi4B, it worked, but some undervoltage warnings, that aren't there when I power it with a PSU once bought together with a RPi3B+. So I guess more ripple or so for that 65W PSU and of course RPi4B does not support USB-C PD (only base 5V max 3A).

I think I don't believe that unless you post a similar serial log where we can see what U-Boot, kernel, etc is used. Board is: https://radxa.com/products/rock5/5c I have a RK3588S board running mainline U-Boot 2024.10 and kernel 6.12.6. Is headless (serial console) but if I connect HDMI, it runs KDE6 Wayland really great. I avoid ZFS, but use Linux native Btrfs. All runs from eMMC and/or NVMe. So my advise is, upgrade, maybe first try extra separate latest image from downloads, see if that boots OK. Then merge kernel+U-Boot from that into you non-working setup. That is manually copying things, but then likely no need to re-install everything.

My Rock3A was getting a bit further, so I could benefit from verbosity=7, although it got into trouble somewhere related to NPU (could not draw any conclusion from that anyway). I am looking for an extra RK3588 (not RK3588S) board, maybe OPi5, many options, need more study what is most effective w.r.t. 12V off-grid powering. After I looked into schematics of Rock3A it got more clear to me how I need and want powering. The Rock3A has on-board 5V 8A DC/DC converter, so as suggested somewhere, one can solder some power wires to a DIY USB-C male connector and connect those to something between 9V-20V. So no 'thin wire' problem at least. I should have looked at it before, as now extra RPI5 PSU is not needed now (but good as laptop/tablet charger etc).

I did a quick test based on my december 16th rock3a build tree: /local/s0/armbuild$ sudo btrfs subvolume snapshot rock3a orangepizero3 /local/s0/armbuild$ cd orangepizero3/build /local/s0/armbuild$ ./compile.sh BOARD=orangepizero3 BRANCH=edge kernel-config and also there in the kernel menuconfig Virtualization is not selected, also not the setting 1 level deeper. But when selected, the .config is as expected (like other 64-bit ARMs). My build-host is NanoPi-R6C (RK3588S) running Armbian Bookworm (beta repo, 6.12.6 kernel) where that armbuild folder is 30GB btrfs space on NVMe.

I see that for my 64-bit ARMs (rk3588 rockchip64/rk3568 bcm2711) the kernel configs have the following which allow me to use KVM/libvirtd/QEMU: /local/s0/armbuild/rock3a/build/config/kernel$ grep KVM linux-bcm2711-current.config CONFIG_HAVE_KVM=y CONFIG_HAVE_KVM_IRQCHIP=y CONFIG_HAVE_KVM_IRQFD=y CONFIG_HAVE_KVM_IRQ_ROUTING=y CONFIG_HAVE_KVM_DIRTY_RING=y CONFIG_HAVE_KVM_DIRTY_RING_ACQ_REL=y CONFIG_NEED_KVM_DIRTY_RING_WITH_BITMAP=y CONFIG_HAVE_KVM_EVENTFD=y CONFIG_KVM_MMIO=y CONFIG_HAVE_KVM_MSI=y CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y CONFIG_KVM_VFIO=y CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT=y CONFIG_HAVE_KVM_IRQ_BYPASS=y CONFIG_HAVE_KVM_VCPU_RUN_PID_CHANGE=y CONFIG_KVM_XFER_TO_GUEST_WORK=y CONFIG_KVM_GENERIC_HARDWARE_ENABLING=y CONFIG_KVM=y CONFIG_PTP_1588_CLOCK_KVM=y For 64-bit Allwinner (I only have 32-bit Allwinner SoCs): /local/s0/armbuild/rock3a/build/config/kernel$ grep KVM linux-sunxi64-current.config CONFIG_HAVE_KVM=y CONFIG_PTP_1588_CLOCK_KVM=m I do not know the details, but already KVM IRQ ROUTING needs to be there AFAIR, otherwise hardware accelerated virtualization won't work.

Do as Werner says I think, although setting verbosity=7 in armbianEnv.txt will likely show you where it fails

This is "Orange Pi Zero 3 is powered by Allwinner H618 quad-core Cortex-A53 processor: I am a bit surprised that you needed own actions to enable KVM. At least already Debian Bullseye aarch64 had this enabled by default. I used that on RPi3 although that one can run 32-bit kernel then it won't work. I use standard KVM/libvirt/QEMU, no proxmox.

There is Debian Bookworm image as well. That variant should have been there for more than a year. Ubuntu Noble is fairly new, so maybe some issues. Kernel is the same. But vanilla Ubuntu Noble is kernel 6.8, so in theory there might be issues. I use Armbian Debian (kernel 6.6) on my 32-bit NEOs. no issues. I could switch to Noble but is no priority. I use it on a new Rock3A, works fine there. If you feel you can't handle potential issues, use Bookworm.

It tuns out that the failing mmc1 DISCARD is related to the specific SD-card: Silicon Power 16GB CID=9f5449535043432010c464002f012c61 With mainline 6.12.6 kernel about daily this: [Dec27 00:13] mmc1: Card stuck being busy! __mmc_poll_for_busy [ +0.000526] I/O error, dev mmcblk1, sector 2107456 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 0 [ +0.001177] mmc_erase: group start error -110, status 0x800 [ +0.540862] dwmmc_rockchip fe2b0000.mmc: Busy; trying anyway [ +0.729908] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000) [ +0.020846] mmc_host mmc1: Bus speed (slot 0) = 375000Hz (slot req 400000Hz, actual 375000HZ div = 0) [ +0.447254] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 100000000Hz, actual 50000000HZ div = 0) [ +0.124915] dwmmc_rockchip fe2b0000.mmc: Successfully tuned phase to 0 No data corruption, btrfs scrub reported 0 errors. I did dd copy the card to a new 32GB Sandisk card, fixed GPT and now not this kind of errors anymore.

You might have the situation that your Pi sees/has 2x U-Boot, 2x boot.scr Or even more. boot.scr is generated from boot.cmd, look in there how scripting composes the name of your overlay files. Multiple copies and/or versions will create mystery. Take your time and see what is what and where. And connect serial console. It allows you to load dtbo manually, needs a lot of U-boot commands study, I also had to learn myself.

Indeed you need to hook up a 'serial console cable' for cases like this. Some call it 'serial debug cable' or you say 'RS232 logger'. It actually should not be RS232, that is serial but other higher voltage signal levels used for long wires, PCs in the past. It must be TTL level 0V en 3V3. Which pin you need is undocumented for your RockPiS ('Comming soon', cheap board so no good documentation...) https://radxa.com/products/rockpi/pis#techspec I guess you need to take the same pin numbers from the colored header as for RaspberryPi boards and almost all others like for my Rock3A. See what is Rx, Tx, GND. If you look in boot.cmd for your board you could derive what setting you need on the USB side of the cable(in your laptop or so). For Linux laptop controlling my Rock3A I use for example: sudo screen /dev/ttyUSB0 1500000

I see it is from 2021. So a typical case where the board vendor has left its customer. Still Debian10 where in half a year we will have Debian13 already. I also see there is an older version Debian9. So ASUS sold the boards, supplied it with some OS image, did 1 time an update, but that's it. It looks to me that they never made any profit from this SingleBoardComputers business, so not surprising that support ended, that is the hard truth. It is a pity as I remember when it was put on the market, I found it a promising alternative to RaspberryPi and I have several ASUS PC motherboards that already work for 10+ years. But of course people still pay Microsoft. This is more or less the base for expectation level what you can do with the board. You can make some mix of the old ASUS Debian10 image and a newly build more generic Armbian image, but that requires quite some Linux know-how and low-level tools to do. Otherwise, pull the powerplug after shutdown.

Yes thanks for mentioning this. I will need to keep an eye on this as my initial bring-up of the Rock3A also resulted in block errors after 2 days. Was another SD-card (new one). But I did many reboots/trials and 3 different U-Boot versions, 3 different kernel versions, also not to forget various powering options. So cannot really conclude anything from it. Note that I use Btrfs, so already the kernel detects block corruption. Usually that says enough. See also comments inside script: /usr/sbin/fsck.btrfs If a DISCARD command fails (I/O error), it should not corrupt used blocks, unless the SD-card internal firmware makes a total mess of things or due to some wrong administration in fstrim/kernel. I bought this Rock3A for its SPI flash and SATA, so I can put Btrfs+SATA enabled U-Boot in it, then the board itself can boot from Btrfs raid1 profile (SD-card+SATA-HDD), even with SD-card totally failing. So that I could use to detect issues with SD-card (anything, even A2 queing etc if that is the case, I haven't focused on it). And keep it running. But it is easier to raid1 an SD-card partition + an NBD image file on NAS (TFTP boot), I have done that before. Then no changes in default U-Boot needed.

This works.

Just now already I see also the DISCARD relted I/O error with 6.12.6: [ 141.741985] mmc1: Card stuck being busy! __mmc_poll_for_busy [ 141.742506] I/O error, dev mmcblk1, sector 2098136 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 0 So this needs more research. Maybe it is a card problem, but this SD-card has been working well in RaspberryPi4B, but tha is totally other HW+kernel ofcourse.

Kernel 6.1.84-vendor-rk35xx shows I/O failures related to fstrim: [Dec23 01:15] mmc1: Card stuck being busy! __mmc_poll_for_busy [ +0.000058] I/O error, dev mmcblk1, sector 2030536 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 2 [ +0.000354] mmc_erase: group start error -110, status 0x800 [ +0.500034] dwmmc_rockchip fe2b0000.mmc: Busy; trying anyway [ +0.500079] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000) [ +0.014028] mmc_host mmc1: Bus speed (slot 0) = 375000Hz (slot req 400000Hz, actual 375000HZ div = 0) [ +1.341988] mmc1: card never left busy state [ +0.000084] mmc1: tried to HW reset card, got error -110 [ +0.000017] I/O error, dev mmcblk1, sector 3153376 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 2 [ +0.001334] mmc_erase: group start error -110, status 0xff8000 [ +0.000044] I/O error, dev mmcblk1, sector 4546304 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 2 [ +0.001342] mmc_erase: group start error -110, status 0xff8000 [ +0.000043] I/O error, dev mmcblk1, sector 6361032 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 2 [ +0.001087] mmc_erase: group start error -110, status 0xff8000 [ +0.000015] I/O error, dev mmcblk1, sector 7495296 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 2 [ +0.001046] mmc_erase: group start error -110, status 0xff8000 [ +0.000043] I/O error, dev mmcblk1, sector 8552448 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 2 [ +0.001234] mmc_erase: group start error -110, status 0xff8000 [ +0.000025] I/O error, dev mmcblk1, sector 9830400 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 2 [ +0.001102] mmc_erase: group start error -110, status 0xff8000 [ +0.000012] I/O error, dev mmcblk1, sector 11254816 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 2 [ +0.001335] mmc_erase: group start error -110, status 0xff8000 [ +0.000049] I/O error, dev mmcblk1, sector 11698272 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 2 [ +0.001170] mmc_erase: group start error -110, status 0xff8000 [ +0.000018] I/O error, dev mmcblk1, sector 12132840 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 2 [ +0.000050] BTRFS warning (device mmcblk1p2): failed to trim 10 block group(s), last error -5 [ +0.000936] mmc_erase: group start error -110, status 0xff8000 [ +0.000035] BTRFS warning (device mmcblk1p2): failed to trim 1 device(s), last error -5 [ +0.005071] mmc_erase: group start error -110, status 0xff8000 [ +24.960198] mmc_host mmc1: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0) [ +0.087520] dwmmc_rockchip fe2b0000.mmc: Successfully tuned phase to 257 This one was triggered by fstrim.timer, but manual invocation of fstrim same errors. The filesystem scrubs OK though. The problem does not exist with mainline kernel 6.12.6 So a reason not use vendor kernel, although I tested transcoding HEVC->H264 and that went fine with about 62FPS. Regarding the main use-case (SATA HDD attached): I have no experience with creating DT overlays, but from what I understand and see is that in this case, rock-3a-sata.dtbo from vendor kernel should work with mainline. So I changed my [bootFAT]/extlinux/extlinux.conf to use that file for booting with 6.12 and that works. So again a reason less to use vendor kernel. So running is now (still the Radxa U-Boot from SD-card, SPI disabled): Operating System: Armbian 25.2.0-trunk.203 noble Kernel: Linux 6.12.6-edge-rockchip64 Then next step is remove jumper from SPI_CLK,GND and then start the board with the mainline U-boot and see if the SATA overlay still works.

I could run the image without doing any change to UUID in /boot/armbianEnv.txt and /etc/fstab. The big difference is of course that my test is another board+CPU+DTB. But on the other hand that makes it more strange. The 'Linux' OS part seems OK as it is able to run on a Rockchip 3568 SoC. But the fact that there is a core file in the root of the image means that something went wrong during generating the image. That can be anywhere. I have not checked in detail where the core file originates from.

This ending up in initramfs with recent build I recognize, although I had this on a Radxa ROCK 3A and root cause is still unknown but I can't reproduce the problem with newer kernel, newer U-Boot, other power supply, other SD-card. So I am still curious what the reason was. As this is 6.12, so mainline (kernel and uboot) and I would like to experience Cinnamon after a decade of not using/booting it, I did some thinking and downloaded the OPi5+ image you refer to and unpacked it onto a RPi4 free SD-card slot. Some string grep in the image shows: U-Boot SPL 2024.10-rc3-armbian-2024.10-rc3-Sd11a-Pa706-H80a2-Vd733-Bda0a-R448a-dirty (Nov 30 2024 - 09:30:48 +0000) Then mount /dev/mmcblk0p1 and I see there is a /core file, it seems a crash of the image generator tooling. anyway, I patched a vendor uboot for the Rock3a in the /dev/mmcblk0, set verbose=7 and set dtb not OPi5+ but for my RK3A, then unmount and put into my Rock3a and I could surf the web with FireFox ESR, even though Rock3A is RK3568 and the kernel version string contains 3588. (I have my SPI-flash disabled, so same as yours erased) Then patched a mainline uboot from my normal Rock3a roottree (Noble, beta updated) onto the SD-card: U-Boot SPL 2024.10-armbian-2024.10-Sf919-P35d0-Hba75-Vea36-Bdacf-R448a (Dec 09 2024 - 13:26:39 +0000) Rebooted and still all OK. The minimal 6.12 based image contains the same 2024.10-rc3-armbian-2024.10-rc3-Sd11a-Pa706-H80a2-Vd733-Bda0a-R448a-dirty U-boot, so it might be a power or SD-card issue, I don't know. Now maybe related to it, I have seen 1 or 2 times an I/O error with my Rock3a a few days ago, I have not really logged it as there are more important things to figure out first, but It might be a TRIM issue, a temporary busy stall or so. Anyway, I use/convert to Btrfs sooner or later as only then I can detect longterm (corruption) issues.

I marked the method of using a vendor kernel with also a vendor provided U-boot as solution, at least for my current trials with the Rock3a board. I am learning more about the Rock3a, that is what I need, a certain level of confidence in the HW/board (and Radxa), so that eventually it can be a (backup) NAS. W.r.t. potential power supply issues, the Rock3a seems to be the first SBC I got that can power my WD Elements directly from its USB3 connector without any externally powered USB3 hub. I now have soldered a 12V wire pair to a USB-C connector (Aliexpress modules targeted for DIY) and connected the other end to a 12V old car battery. So now the on-board DC/DC chip does its work (fixed 5V out, max 8A).

I found the reason for the crash: the 6.1.84-vendor-rk35xx doesn't work together with the 2024.10 mainline U-boot. Earlier the SPI-flash was empty and the Rock3a booted from SD-card, a U-boot version from 2017 (Armbian_24.11.1_Rock-3a_noble_current_6.6.62-kisak.img.xz). I put that image in 'beta' mode so I got the 6.1.84-vendor-rk35xx (+ rock-3a-sata.dtbo). That all still worked. I then put the 2024.10 mainline U-boot in SPI and wiped the sector range 34-32767 from the SD-card. Then I discovered that the 6.1.84-vendor-rk35xx always crashed, independent of SATA modules etc. I now disabled the SPI and took sector range 34-32767 from the official Radxa image (rock-3a_debian_bullseye_cli_b25.img.xz) and put that on the SD-card with the Armbian Noble (latest beta channel trunk.201) and rebooted. That does not crash and works same as with 6.12.6-edge-rockchip64 that I used before the reboot to write the sector range 34-32767. Version is: latest-2023.07.02-3-b1eb2bde-gb1eb2bde (Aug 29 2023 - 10:43:04 +0000) So I guess I need to look at differences in uboot configs and likely also uboot sources. The other thing is that If I want to be able to boot from a single SATA device with the Rockchip on-chip SATA, the uboot In the SPI-needs to default to SATA for M.2 E-key connector and not the default PCIe-2x1. Or wait till I got an extra NVME to put in the M.2 M-key connector and load rock-3a-sata.dtbo after uboot together with kernel. That is preferred I think looking at possible future use-cases.

It depends what has been corrupted. If you are lucky it is maybe 1 file and you figure it out fast. But if many, what is more likely, then it is a dead end.