eselarm

Shame on me that I don't have a USB-A to USB-C cable. Only USB-C to USB-C (including powermeasuring in connector). Also have several USB3-A to microUSB3 for Samsung phone debugging (S5). Because the S5 needs USB3 for ADB, I think the same is for Rockchips which also are main business case Android I think. My NanoPi-R6C is promoted to 'production' so must run 24/7 UPS connected. I am looking to buy some other Rockchip based board so I have an option to play with 2-storage device/rootfs issues. I have an RK3066 (in MK808 Android stick) but that is stuck at Debian7 more or less and 32-bit. Maskrom works as expected there with USB2-A to mini-USB2 cable. I can read/write ranges from its 8GB MTDblock, so including some Linux kernel 3.0.36. The EDK2 UEFI RK3588 I know and tried, but it hides the eMMC, so only NVME is usable (with standard ARM64 UEFI kernels). Also no option if you want HW accelerated Wayland/X11/DRM/GUI. Modern U-boot can do/emulate EFI as well, so together with matching Linux kernel DTB that is a better option. The U-boot in my NanoPi-R6C in eMMC is now '2024.10-armbian-2024.10-Sf919-P485c-H3f52-V1bfa-Bda0a-R448a', verified that it comes from eMMC. Which also means I don't have a method to boot from SD-card, unless a watchdog or so would try SD-card in case eMMC boot area would be corrupted with random data. All zeros in eMMC would result in boot from SD-card I think. This is something different from the 2017 U-boot from OpenWRT pre-installed. So the worry is still there that I currently don't have an un-brick method I think, so will order some cable types that are needed.

Strange that this need to be changed. I see for mine: grep CONFIG_DISABLE_CONSOLE /usr/lib/u-boot/nanopi-r6c-rk3588s_defconfig # CONFIG_DISABLE_CONSOLE is not set

initramfs is re-run/updated whenever a tool or setting or package in initramfs is changed/updated. So for example, I don't use NTFS on Linux only boards, so when I remove the ntfs-3g package, initramfs is regenerated as the ntfs tooling is removed from initramfs.

The first question is: What U-boot binary blob is written to your storage? In my installation, the U-boot binary blob is not written during upgrade. I do this myself with dd. Was originally some 2017 version. I always had all text displayed. The loglevel in armbianEnv.txt is for kernel, although mine is at 7, but that should not matter for U-boot AFAIK. I have a NanoPi-R6C (is RK3588S) but also several other Armbians, did apt update && apt upgrade yesterday (current branch). Now kernel 6.12.1 and also a newer U-boot. The version is listed in: /usr/share/doc/linux-u-boot-nanopi-r6c-current/changelog.gz mine is: Similar path specific for your Rock 5B. Should come from package 'linux-u-boot-rock-5b-current/bookworm 25.2.0-trunk.100 arm64' or later. The use configuration used for compile is: /usr/lib/u-boot/nanopi-r6c-rk3588s_defconfig Again, similar path specific for your Rock 5B.

I have done a bit more trial-error and it turns out that the USB port where the A-A cable is inserted won't initialize/open. I can see that via strace and also upgrade_tool creates a log file in a hardcoded filefolderpath /root/upgrade_tool/log/ It looks like I need to buy an USB3 A-A cable if I want to know more. What for sure is not working is pressing maskrom button and hoping that the R6C boots from SD-card. When I don't press the maskrom button, so normal power on, then the "U-Boot 2024.10-armbian-2024.10-Sf919-Pbdc8-H3f52-V1bfa-Bda0a-R448a-dirty (Oct 22 2024 - 11:19:49 +0000)" also prints: rockchip_dnl_key_pressed: no saradc device found That is some sign to me although I vaguely know/guess that there is no DC level voltage detected indication what to do. Or more likely that the driver for SARADC is missing. Anyway, I can stop via keypress at autoboot via serial console and then do: => bootflow scan [...] => bootflow list Showing all bootflows Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- 0 efi_mgr ready (none) 0 <NULL> 1 script ready mmc 1 mmc@fe2e0000.bootdev.part /boot.scr 2 script ready mmc 1 mmc@fe2c0000.bootdev.part /boot/boot.scr 3 efi ready nvme 1 nvme#0.blk#1.bootdev.part /EFI/BOOT/BOOTAA64.EFI --- ----------- ------ -------- ---- ------------------------ ---------------- (4 bootflows, 4 valid) So this is with valid IP-address, SD-card with older know to work minimal Armbian Bookworm, eMMC with 1st FAT boot, NVME with openSUSE and a handful others. Number 0 is not clear to me, likely this is when there is some real UEFI somewhere in MTD or so like on x86 PCs. From number 1 and 2 I have to guess what is SD-card and eMMC, but that is do-able. I am not sure where the loaded U-boot comes from. I have to write an own/other one on eMMC I think, and just make sure I know the version already from the file written with dd, not only from the bootlog via serial console.

I see Allwinner A20 is a mix of sun4i and sun7i as drivers in dmesg. I have only temp sensors on Allwinner H3 that is sun8i, at least I see other pinctrl there. My BPI M1 must run for a week or more for figuring out another problem, but at some point I could connect a 1-wire temp sensor and see what happens. I used direct editing of armbianEnv.txt What is in yours?

I managed to build u-boot-2024.10 with Btrfs for 32-bit (using systemd-nspawn). See: https://docs.u-boot.org/en/latest/build/index.html It would be more easy to do for native aarch64, but that I already knew when building for 'machine' 'qemu-arm64'. As example for my NanoPi-NEO, all in extra separate src/build folder: dpkg -L linux-u-boot-nanopineo-current - add/change CONFIG_CMD_BTRFS=y CONFIG_FS_BTRFS=y in nanopi_neo_defconfig make menuconfig and save the .config make -j8 - see platform_install.sh how and where to write the newly build u-boot-sunxi-with-spl.bin (about 570kByte, so fits in my MBR partition starting at sector 2048) So after merging boot files from the mmcblk0p1 Ext4 partition to a folder /boot on mmcblk0p2 Btrfs rootfs, I started fdisk and made Btrfs rootfs p1 (using the same start-end sectors), so only 1 partition. Same as you actually have on standard Armbian images. And comment out the line in fstab for mount of separate boot partition (or add nofail option maybe). Then reboot and restarted without problems. I did actually all via remote ssh, although i also had serial USB console cable connected as I wanted to see the boot log, but was as expected. A remark I saw was that it could not write environment to FAT. That is something I need to think about. Do I gain something if that is possible. Currently not on single OS SBCs for me I guess. A bootFAT might be more convenient for people who rely more or only on a Windows/MacOS computer as their main desktop. I use Linux so no issue with fixing SD-cards in case of non-boot because I messed up something testing or so. What went wrong afterwards is my backup script via ssh. For SoCs that use binary blob bootloader, I copy/compare/backup the first sectors till p1 (usually 2048 or so, so a 1 MiB file). That size determination went wrong, it created a 257MiB file in /tmp, so fails with a 512MiB SBC. But learning more now after 10+ years SBCs, I think I should do that smarter, just re-use platform_install.sh or so. I think I will have to look at 1st boot resize script(s). It is max SD-card, so all space gone for Ext4. I really hate that. Even more when done on fixed/soldered eMMC or NVME. Ext4 cannot be shrunk in a running system later on. Btrfs can, so last hack I did on an Ext4 downloaded image (RPiOS64 Lite) was double the image file, max Ext4 on that image and then convert to Btrfs with btrfs-convert. It also need kernel cmdline and fstab change still, but that is more or less it.

I know Ext4 and 1st boot resize is used, but I have manually recreated rootfs to be Btrfs. On NanoPi-R6C it is u-boot code in first 16M of SD or eMMC, then a 256M FAT32 partition with Image uInitrd DTB overlays. I made an extra script for update-iniitramfs to copy those for a certain kernel version to the FAT partition. In a qemu VM, I use a custom enhanced u-boot that has Btrfs support, so no bootFAT needed anymore. This should also work on real HW, The advantage of Btrfs for root is that you can move the rootfs from SD to eMMC (or NVME) I a live running system (btrfs replace start ...) At finish, only dd with u-boot loader to eMMC is needed. Then take out SD-card and done, no reboot needed, same rootfs UUID. Creating partition on eMMC is still needed of course, but can be just max of eMMC. Btrfs can always be shrunk later on in live system. So that is what I did several times also to install other OS variants in other partitions of the eMMC (and mostly NVME as that is much faster). I haven't looked in armbiam-installer. I know when selecting Btrfs as rootfs in builder, you get Ext4 for boot and Btrfs for root. This is what I use on NanoPi-NEO and BananaPi-M1 (created manually long time ago). Those don't have eMMC or SPI-flash and it works fine. But tempting to write a Btrfs enabled u-boot to the proper place at the beginning of the SD-card and merge Ext4 /boot into rootfs. I am a bit unsure about building 32-bit u-boot but i think i can temporary used systemd-nspawn of a 32-biit rootfs on RK3588 so fast building.

I have been reading various info mostly last 2 years on RPi forum, maybe scan https://forums.raspberrypi.com/search.php?keywords=libgpiod Many people don't want change so most is about keeping it the old way. I saw a warning in dmesg for 6.12.0-current-rockchip-rk3588 on my NanoPi-R6C. I don't use it there for own code, but do on a NanoPi-NEO to toggle an ON/OFF power-switch. Works still there for 6.6.44, but might be that some small C-program is needed in future, haven't looked at it further yet.

I see you use or need some GPIO in order to have audio device enabled. In newer kernel versions GPIO numbering will be sort of random and AFAIK this sysfs method will disappear. So I think for future, extra code is needed to find the correct GPIO and then also treat it like a character device. So open, close etc. See libgpiod for more info.

@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.

I have another subtype (and likely older) E3372 device, and remember that after updating it firmware, it acted upon the defaults w.r.t. usb_modeswitch. But it needed newer usb_modeswitch. It was on RPi Debian Buster alike, but usb_modeswitch needed to be newer. Please report your versions.

Maybe this helps:

'Armbian_23.5.2_Nanopineo_bookworm_current_6.1.30_minimal.img' now works as expected. However, going to nightly again on my existing installation still the same hang with a kernel file named '6.1.30-sunxi' as well. So I did a brute-force overwrite of the relevant kernel files from the Armbian_23.5.2_Nanopineo_bookworm_current_6.1.30_minimal.img on the existing installation, then the boot succeeds with: [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 6.1.30-sunxi (armbian@next) (arm-linux-gnueabihf-gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #1 SMP Wed May 24 16:32:53 UTC 2023 and I have Bookworm with 6.1.x kernel on NanoPiNEO. That was the goal as I can use some new Btrfs features now and prepare for upgrade of a few other NanoPiNEOs. I will keep this one as is as an intermediate step. Once Debian Bookworm is released and some kernel >= 6.1.30 appears, I will go back to stable I think. The other NanoPiNEOs should not run beta at least. Although the build-date is before my report, I assume it lacks or fixes the issue with net-phy-Support-yt8531c.patch.

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

Also with verbosity=7 no extra output. Also 'Armbian_23.5.1_Nanopineo_jammy_current_6.1.30.img' same behavior; makes me think that the generated kernel file is maybe wrong/corrupt (I haven't checked if it is the same for Jammy and Bookworm). Or the U-boot firmware doesn't work together with the 6.1.30 binary. A 6.x kernel itself should not be a problem I think. Earlier this year I booted from an openSUSE Tumbleweed image, that went OK. AFAIR it was also 6.x kernel but very different U-boot at least; It had Btrfs build-in and resized to small GPT based layout in order to allow the Allwinner H3 to load from the hardcoded sector offset. I don't know how to continue, maybe wait for updates of the repo to final Bookworm after Debian release on the 10th of june.

The problem seems to be kernel version 6.1.30; Just writing image file 'Armbian_23.5.1_Nanopineo_bookworm_current_6.1.30_minimal.img' to SD-card gives the following output via serial console: U-Boot SPL 2022.04-armbian (May 27 2023 - 19:27:28 +0000) DRAM: 512 MiB Trying to boot from MMC1 U-Boot 2022.04-armbian (May 27 2023 - 19:27:28 +0000) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: FriendlyARM NanoPi NEO DRAM: 512 MiB Core: 33 devices, 12 uclasses, devicetree: separate WDT: Not starting watchdog@1c20ca0 MMC: mmc@1c0f000: 0, mmc@1c11000: 1 Loading Environment from FAT... Unable to use mmc 0:1... In: serial Out: serial Err: serial Net: phy interface0 Error: ethernet@1c30000 address not set. No ethernet found. starting USB... Bus usb@1c1a000: USB EHCI 1.00 Bus usb@1c1a400: USB OHCI 1.0 Bus usb@1c1d000: USB EHCI 1.00 Bus usb@1c1d400: USB OHCI 1.0 scanning bus usb@1c1a000 for devices... 1 USB Device(s) found scanning bus usb@1c1a400 for devices... 1 USB Device(s) found scanning bus usb@1c1d000 for devices... 1 USB Device(s) found scanning bus usb@1c1d400 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 4121 bytes read in 3 ms (1.3 MiB/s) ## Executing script at 43100000 U-boot loaded from SD Boot script loaded from mmc 182 bytes read in 2 ms (88.9 KiB/s) 10963883 bytes read in 456 ms (22.9 MiB/s) 8477464 bytes read in 354 ms (22.8 MiB/s) Found mainline kernel configuration 35417 bytes read in 7 ms (4.8 MiB/s) 504 bytes read in 5 ms (97.7 KiB/s) Applying kernel provided DT overlay sun8i-h3-usbhost1.dtbo 504 bytes read in 6 ms (82 KiB/s) Applying kernel provided DT overlay sun8i-h3-usbhost2.dtbo 4185 bytes read in 5 ms (817.4 KiB/s) Applying kernel provided DT fixup script (sun8i-h3-fixup.scr) ## Executing script at 45000000 Kernel image @ 0x42000000 [ 0x000000 - 0x815b18 ] ## Loading init Ramdisk from Legacy Image at 43400000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 10963819 Bytes = 10.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 EHCI failed to shut down host controller. Loading Ramdisk to 4958b000, end 49fffb6b ... OK Loading Device Tree to 4951a000, end 4958afff ... OK Starting kernel ... From here on it hangs. The board runs fine with kernel 5.15.93 and Bookworm userspace from its usual SD-card that I manually upgraded to Bookworm (edit sources lists and added armbian.gpg key). That dist-upgrade did not upgrade the kernel, still kept at 5.15.93. Also I saw no change in U-boot. As a trial, switched to nightly in armbian-config, that installed kernel 6.1.30, but also same hang as the official image. So I rolled-back that trial, and now the question is, why does this kernel 6.1.30 hang?