eselarm

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.

A quick look at the shell code makes me think that it is a different purpose compared to how I use virtualization. I use only HW accelerated based virtualization, so -enable-kvm flag is missing, but might be added by virt-install. Also mostly Arm on Arm although I also use x86 on x86 as well. I do not use qcow2, but just flat images or a physical SD-card or NBD or LVM.
 
Before I got my Rock3A, I downloaded the Armbian Noble image for it (was 6.6.62) but put a 6.12 *rk3588 kernel on it as well. With the default Armbian U-Boot for QEMU I could then prepare everything and already 'run' my Rock3A as a VM on NanoPi-R6C like this:
taskset --cpu-list 0-3 qemu-system-aarch64 \ -M virt -cpu host -enable-kvm -m 2048 -smp 4 \ -bios u-boot.bin \ -drive if=none,file=rock3a.img,format=raw,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -netdev bridge,id=hn1 -device virtio-net,netdev=hn1,mac=xx:xx:xx:xx:xx:xx \ -nographic The taskset is needed if host runs 6.1.x  vendor kernel and also makes it more realistic w.r.t. speed as then the VM gets 4x Cortex-A55, same as real Rock3A.
The 6.12/rk3588 kernel (inside the VM) was needed as that one has all included w.r.t. machine virt (same as vanilla Debian Bookworm kernel).
 
A note is that I later on added Btrfs support to a custom build u-boot for QEMU and converted Ext4 in rock3a.img into Btrfs, but principle is the same. Btrfs offers online shrink and differential snapshots that I use for remote backups. And with a MAC-address equal to the real Rock3A, it is easy flipping between real and VM.
 
Also note is that the following file needs to be created on the host, assuming it uses br0 as base for network I/O:
# cat /etc/qemu/bridge.conf allow br0  
To use full graphics in VM and for multi-year running VM on my RPi4B, I also use virsh and UEFI. But usually only CLI is needed.

It does work. The issue I referred to relates to the rsync bug. Seems solution is to update rsync and update for 22.04 was just released: https://bugs.launchpad.net/bugs/2095004

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

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.

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.

e2fsck checks only the metadata, it cannot know if data inside your files is corrupted or not. So I would use the old backup and think hard about what files could be needed and are newer from the corrupted image. Can be timeconsuming.
It might be that the SD-card was in some blocked state doing wearleveling or whatever, so maybe the image you made later is maybe correct. You could try to write it back and see if it boots.
But to prevent such issues, use Btrfs as rootfs. It has checksums for all data blocks and would have listed you in this case where which files the corruption is. It also also allows you fast incremental online backups, so every hour or so, what you want. And because Copy on Write, no problems with sudden powerloss, assuming it is not a bad or half-dead SD-card.

I am almost sure now that the reason I saw: 'Running /scripts/local-premount ... Scanning for Btrfs filesystems' is power supply or circuitry related.
 
What exactly is a question still. If I want to know, I have to go back to the situation on the day before yesterday when I tried to boot the new ROCK3A v1.31 with the original downloaded noble 6.2.62 based images.
Radxa wiki mentions 5V/2A is needed, so I took a known-to-work PSU (used for diskless RPi4B) rated 5V/2.4A, added my https://www.fnirsi.com/products/fnb48s and with HDMI, serial console, RJ45 connected as well.
 
The FNB48S displayed values well below 5V/2A. What worries me is that several strange things happened:
- with 2 different brand SD-cards, the board went in a low-power state, stalled. Disconnect and then reconnect USB-c power cable made it boot further mostly, until 1 time full success
- the HDMI monitor sometimes shows a shaky flash. That is the most strange; I suspect a loop in cabling somehow, but it isn't there (in theory). The workaround is to make sure no loops, so no HDMI, serial console connected laptop on batteries
- around kernel/systemd messaging about NPU power also something changed, either stall or success.
 
In the end, as stated already, Radxa Debian11 CLI image worked. But also the Armbian Bookworm minimal IoT image with kernel 6.6.62. So I used the latter one to set up some basic things like ssh access and keys and correct MAC/IP address (networkd fails somehow with DNS in my homelan, so purged netplan and (re-)installed NM). And the converted the whole rootfs of-line to Btrfs with btrfs-convert, put SD-card back in and it still worked.
 
Yesterday, the day after, I swapped the 5V/2.4A+FNB48S for just a new RaspberryPi 5V/5A PSU (not that the 5A matters) but was new/unused and also got 2 the other already setup noble rootfs systems onto extra partitions on the same SD-card. No issues, although now it is kernel 6.6.63 or 6.6.64 already as I put it on the beta repo.
 
My use-case was replacing an old  dead Intel Asrock server board handling a large SATA HDD, so I needed the 6.1.84 vendor kernel which now includes a SATA overlay and that works (kernel sees it at least).
So my guess is I have/had some (GND)loop or whatever. I always can run the whole setup via an off-grid standalone 12V car-battery, in case I want some 'proof'. it was late in the evening, too tired as well I guess.
 

There is an issue with SD-card interfacing in the 'noble_current_6.6.62' images I think. I see the same:
   Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems
and is is because after the kernel is loaded and starting to run (doing scripts from initramfs etc), the SD-card/MMC interfacing get flaky or so. That endless wait is just that initrd can't find the rootfs. It also happened in an earlier phase that communication with the SD-card gets into trouble. Then many block I/O errors. It seems on older slower card 1 out of 4 powercycles it works, and then also no problem at all. The successful run I managed to setup the full system KDE neon desktop. But now it always fails, so I took a complete image of the SD-card and will try later.
 
In my case it is a ROCK3A so different SoC. A Radxa Debian11 CLI image gives no problems. I will make an own topic later when I know more.
 

Another try: 'Armbian_23.5.0-trunk.275_Nanopineo_bookworm_edge_6.2.16_minimal.img' works!
So filesystem resize, account creation, reboot, power cycle. U-Boot reports: 2022.04-armbian (May 25 2023 - 19:26:34 +0000) Allwinner Technology