eselarm

@DantesWhen I still had the original 2017 U-boot on the eMMC (from the OpenWRT that came pre-installed), inserting an SD-card with some recent Armbian image booted always from the SD-card. So in serial/debug console I had full control of the eMMC (and also an NVME in the M.2 slot). So that is also how I recently wrote a new/latest 2024 U-boot from the current-branch Armbian to the eMMC with dd. But that 2024 U-boot is more flexible and I needed quite some time to and figure out what was what (after stop autoboot prompt): 1 - SD-card with a known good simple basic Armbian Bookworm 2 - eMMC where the custom kernel did not work 3 - NVME with an EFI boot partition with grub.efi and some variant of openSUSE and some Debian flavor After reading U-boot command docs like 'bootflow', I somehow booted from NMVE. Fine but I want also operation with no NVME in the M.2 slot inserted. So eMMC and SD-card can be selected in U-boot but was a bit guessing as I had to rely on some addresses, so 3rd try or so I started the good simple basic Armbian Bookworm from SD-card and from there I could put a working kernel Image/uInitrd/DTB on the eMMC again. But what will happen if the somehow the U-boot on eMMC is corrupt? That has not happened, but when it would, will it then always somehow re-init and try SD-card? That is my point, that is why I thought I should also get to know USB loading, like I know from Android smartphones with fastboot tool. But you state: "Boot from sdcard with maskrom", that I had not thought of. Does that skip eMMC always? And scp? You mean the ethernet port(s) is/are up and running then? Or something over serial cable downloading what is known from simple old processor boards?

On my NanoPi-R6C I have been doing several U-boot updates (writes with dd to areas in 1st 32k) and so far so good. But behavior has changed w.r.t. eMMC v.s. SD-card. I want to do some U-boot build config changes, so the risk it that something might go wrong and I would need USB MASKROM mode to do writes to eMMC I think. The NanoPi-R6C wiki is not very clear with 'connect USB', but it turn out that this should be a connection via type-A to type-A and it does not work in the USB2 port. I have a USB2-only type-A to type-A cable and used that. The NanoPi-R6C appears in the USB device list ('lsusb') and also the tool is seeing the device: /tmp/upgrade_tool_v2.30_for_linux/upgrade_tool LD Using /tmp/upgrade_tool_v2.30_for_linux/config.ini List of rockusb connected(1) DevNo=1 Vid=0x2207,Pid=0x350b,LocationID=12 Mode=Maskrom SerialNo= However, as soon as I want to read blocks from eMMC for example or try any other commands, connection is lost. Now I think that maybe for actual data transfer, USB3 wires in the cable are needed, so the question is: Will it work when I buy/use an USB3 type-A to type-A cable?

qemu-system-aarch64 -M virt -cpu host -enable-kvm ... only works reliably when 1 CPU core ( -smp 1). When a VM has 2 cores, it randomly worked I experienced. If virt-manager pick 2 equal cores, VM UEFI/BIOS/kernel runs OK, but if a Cortex-A76 and Cortex-A55, all sorts of exceptions are shown or just lockup 2x or 1x 100% usage. In order to still be able to use KVM, start qemu-system-aarch64 as follows: taskset --cpu-list 4-7 qemu-system-aarch64 -M virt -cpu host -enable-kvm -smp 4 ... or taskset --cpu-list 0-3 qemu-system-aarch64 -M virt -cpu host -enable-kvm -smp 4 ... Mainline kernel 6.8.x or later does not have this problem. It can transparently use all 8 cores. Userspace is Debian Bookworm based.

This happens with 6.11.2-current-rockchip-rk3588 kernel for me as well. Actually with 3 OSses. There must be some corruption for this kernel, my first guess is somewhere in the onboard ethernet. There might be other download corruptions is well (haven't noticed), but I rebooted with new kernel to other OS/distro and then first thing I did was upgrade and that failed with hash differences like this. So after some trying/switching, doing the same with my last-known-good kernel 6.10.10-current-rockchip-rk3588 worked fine. I haven't looked into it further, maybe when using the the 2.5Gbps port it works (just a guess now). Another try/issue is maybe that I still have a bit older U-boot written to the boot area of the eMMC, so not the old 2017 one but beta 24.10. I'll have to check current version(s) I think.

An update to this topic: All newer mainline kernels (latest I have tested 6.10.0-rc3-edge-rockchip-rk3588) have the same problem as the 6.8.4 one. Change is that KVM now works with vendor kernel 6.1.75-vendor-rk35xx and default libvirt that comes with Debian12; it fails with newer libvirt.

I do not use quotas, so the fix for this issue is: https://github.com/openSUSE/snapper/issues/894#issuecomment-2054220427

When I reboot with kernel 6.8.4 (edge) installed by apt upgrade, I noticed my scripts that uses snapper for remove differential backups. It turns out that, if no cleanup algorithm option is used, snapshot is created. Before the reboot, with kernel 6.8.1 version, there was no issue. I on Armbian Bookworm, but also with other Debian Bookworm based OS running those same kernel binaries. Same failure with 6.8.5 Currently I don't know any more, I could run this faulty kernel in a VM as the .config is such that it also boots on virt hardware (virt-7.2 as Bookworm uses). EDIT: Also in a VM, the problem is there: root@armbian64:/tmp# snapper create -d cleantest --cleanup-algorithm number Creating snapshot failed. root@armbian64:/tmp# snapper create -d cleantest root@armbian64:/tmp# uname -a Linux armbian64 6.8.4-edge-rockchip-rk3588 #1 SMP PREEMPT Thu Apr 4 18:25:06 UTC 2024 aarch64 GNU/Linux

I upgraded from my own-compiled Armbian kernel 6.8.0-rc5 to 6.8.4 and there are now very annoying stall when for example I drag a KDE Konsole window. Also when I play a 1080p50 HEVC video, as son as a move the mouse, the whole video stalls. Besides 6.8.0-rc5, the normal apt provide 6.8.1-edge-rockchip-rk3588 also works OK. 6.8.5 has the same issue as 6.8.4. As indicated, I use KDE, X11, compositor disabled. Enabled makes no difference. OS base is Armbian Bookworm, but I have also used kernels 6.8.1 and 6.8.4 with a rootfs copied from an RaspberryPiOS and Opensuse-Tumbleweed. RPiOs is also Debian Bookworm, Tumbleweed is latest, KDE6. So it is not KDE6. KDE Wayland leaves black screen still (doesn't work), but that is not a showstopper. Is anyone else experiencing the same? PS: I run mainline as the vendor kernel 6.1.43 fails on running KVM (some tag of the Cortex-A55 is unknown) so qemu-KVM don't work/start and running VMs is a key use-case I bought the NanoPi-R6C for.