eselarm

I do not have an easy solution. For a start and better understanding, you will need a serial console cable between the rockpi and a laptop or so. My way working is simply that I don't use SD-card anymore, just eMMC to boot an OS.

That is hard to say as every has likely their own google-specific account experience. And/or lots of ads loading in the background, that kills performance. More specific to what Youtube originally is (or was?) is playing a video. Now that is even harder to say something about, as resolution, frame-per-second and codec are an important factor. It is 4k60fps VP9 on a Soc with no working VP9 HW decoding for example. Or 720p30 h264 done SW decoding. Etc. So the DE might be light, if use-case is mostly webbrowser usage, that will determine the experience of slow or fast. But I do not know what your use case is. I use some basic local homeautomation webserver for example, so easy for a simple low-cost SoC.

I have used LXQT in the past (decade ago maybe) but I mostly use KDE nowadays. (currently KDE6 on N100-8GB and z8350-4GB). For my new ROCK3A I booted the KDE Neon Noble based desktop image on my ROCK3A (2GB RAM, older Sandisk 32GB SD-card). This is 2GHz RK3568 and was surprised how well that worked. I did buy the ROCK3A for SPI-flash, U-boot, SATA, server, KVM operation, but it is great that also KDE6 works on it. I was mainline based kernel 6.6.62, I might try again with 6.1.84, but that will mainly be to see how well I can get the video codecs to work (in browser, but also as server-like for jellyfin). Same for RK3588-8GB, that is also OK for 'heavy' YouTube etc.

I think a new U-boot is used now. At least I recognize this when I had updated the U-boot in my eMMC from original out-of-the-box (from FriendlyWRT, NanoPi-R6C) 2017.x to mainline based 2024.10.x I did this manually with dd myself after reading a lot about Rockchip booting etc. Your Rock-Pi-S may behave differently, it is not RK35xx (that should do Android originally). The new U-boot contains a lot of extra functionality, I don't know all features of course, but If you hit a key to stop at autoboot, then it is possible to do 'bootflow scan' and many more things. It will give you the option so select what is found to be working (eMMC, SD-card, BOOT/TFTP/PXE in my case). The normal scripting found in boot.cmd (and converted to boot.scr) just picks the usual obvious as far as I saw, so if U-boot comes from eMMC, eMMC is selected. That should be ROM determined AFAIK. I do not know the details (yet). At least I know that my ROCK3A had zeros in its SPI flash out-of-the-box. If the first 16MiB or so of the eMMC would all be zeros, the ROM can only go for SD-card. If you would only fill the U-boot area with zeros (from after the GPT till 1st partition), it still could go loading from eMMC as it finds maybe a valid (old) boot.scr and Image and uInitrd and DTB. I had that yesterday. So make sure you don't have double/old paths for booting. And check you UUIDs.

@ngrigoriev You need UAS transfermode enabled and also then in addition make sure trim is enabled. Many USB-to-SATA chips/adapters can't reliably do UAS, so you never get trim to work. AFAIK no USB2 only adaptor can do UAS (I have never seen it), USB3.0 is buggy, so are several SBCs with USB3.0. RaspberryPi4 is notorious, roughly half of the USB3-to-SATA won't work like a normal direct SATA connection. I had to buy a new/extra adaptor for my Pi4, (use only ASMedia based is the advice) and still needed a udev rule to enable trim. Only then it was acceptable, good server like performance for LVM thin volumes and Btrfs etc. Adaptors based on JMicron chips usually give trouble, this generally know by people who use them, sell them, etc. If I look at: idVendor 0xaabb idProduct 0x1122 my immediate thought is this is just some clone or even counterfeit. I haven't checked, I won't waste time on it anymore. The Pi4 troubles did cost me about 35 Euro in total extra for new USB stuff (and lots of time). There are various no-brand or whatever random brand new name adapters with JMicron chip inside that work good enough for old spinning magnetic HDD, but can turn into trouble or disaster for modern SSD that needs trim. I have 1 that only did UAS after firmware update, in an Intel PC, but still not working correctly with Pi4 USB3 port.

@Meestor_XMy 32-bit boards still use 24.8.3 according to /etc/armbian-release I see. There there the older armbian-config is installed and I see overlays are under System->Hardware. My new RK35xx boards all run beta/rolling/testing/trunk, so armbian-configng and I see no list there you can tick at the moment (configng is work-in-progress). There is an option to edit armbianEnv.txt. So that is what you need to do, same as I did and others in this topic. Make sure you understand this linux kernel DTB and overlays well enough I would say, else take older image.

It is the same for all kernels, I have installed and run 6.12.2 and 6.1.84. If it would be a PC motherboard you could swap PCI-E cards physically, but this SBCs is all soldered hardware. Extra sticker/labels on the case is maybe an option. Or FriendlyElec should have just numbered them eth0 eth1 eth2. Ubiquity routers have that. Or part of MAC address.

Yes I explicitly checked. I personally do not really care about the labels/names in the software, although I must know what is what. I look at the picture of the PCB mostly. Or '1G' and '2.5G' that make more sense in my case as I do not use it as a router. I have defined a software ethernet bridge br0 that includes both ports as I need that for virtualization anyway.

Note that for the NanoPi R6C it is correct. Although lan2 could be removed because PCI-E 0004 node contains my NVME SSD. EDIT: I see https://github.com/armbian/build/blob/main/config/boards/nanopi-r6c.csc is correct, no lan2. It is just that on my installation the rules file is not updated. It is from image older than a year.

For my ROCK3A (rockchip RK3568) using Armbian 24.11.x I enable SATA (beta 6.1.84 kernel). I need the file: /boot/dtb/rockchip/overlay/rock-3a-sata.dtbo, that exists. I see in armbianEnv overlay_prefix=rk35xx, but from boot.cmd there is now an extra option without applying overlay_prefix, which is needed in my case I see. I compared with and older NanoPi-NEO (allwinner sun8i/H3), how i did it there. So my statement added in armbianEnv.txt is: overlays=rock-3a-sata and that works. Note that I added it with a text editor to armbianEnv.txt myself, as I needed to change paths related to booting unusual things that armbian-config doesn't know.

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.

@AaronNGrayI have the 500G variant in my NanoPi-R6C: Model: "Samsung SSD 970 EVO Plus 500GB" FW Rev: 1B2QEXM7 You can use the tool 'nvme list' to see your details. This 970 EVO Plus series is well known, I don't expect it a source or trouble. A year ago a RaspberryPi engineer mentioned fantastic speed on a Pi5 (via some adaptor board that was available at that time). I think it was PCI-E v3 mode, that is not formally supported on a Pi5, but generally works. But that is just some side info. Your board is 4-lane PCI-E v3 formally supported by the RK3588. My RK3588S based NanoPi-R6C is only 1 lane PCi-E v2, I have not seen any issues in dmesg. Have you already booted/tested with 6.12.2 mainline or later? You don't need t build it, it is available via apt on the armbian beta repo. Make sure the correct files are in /boot (or where your U-boot looks for at poweron).

@AaronNGray As amazingfate hints, running a 6.12 mainline based kernel would likely get you further a bit faster in figuring out why the NVME/PCIe storage fails. It is a RK3588, so pretty standard. Then it might simply be that your specific type of NVME (and/or its internal firmware variant/version) might be the cause of the problems. I have been following many efforts getting a Pi5 running with NVME and not every NVME is guaranteed to work. Problem with Pi5 is that extra flatcable and interface board and powering that is well, this is N/A for RK3588 SBCs with M.2 M-key on-board. If you only need headless/server in the end, use that. An maybe not noble but bookworm based. I spend several hours yesterday to discover that my carefully prepared noble image for Rock3A is unstable w.r.t. SD-card at boot, but same kernel version with bookworm no issues. Is another topic, other board, but still maybe a hint. I currently have no clue (yet) why the noble install ran fine in a VM on RK3588S (pinned to 2x Cortex-A55) and not on the real RK3568 (4x Cortex-A55, many more HW peripherals). Seems like U-boot config/version or so.

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 update, basically marking this topic as obsolete (concerning myself, my use-cases), is that KDE worked well when using the KDE neon build based on ubuntu22 image for NanoPi-R6C. I won't try any further with KDE(Wayland)+bookworm+NanoPi-R6C. X11 works, but I use headless/CLI mostly. There is also now an ubuntu24 based image available with 6.12 mainline kernel, so if I want to use desktop again I will use that and likely merge my bookworm server-oriented functionality into that.

Btrfs can detect and even correct block errors when dup or raid1 profile is used, but from the dmesg kernel log you can see that the whole NVME storage device disappears. I use 'btop' CLI tool via ssh, shows temperature as well. It is no guarantee that with 6.1.84 it works. If it is {old) SW implementation in the vendor code for PCIe as igor hints, then mainline kernel might be a better test/try. If power issue then I don't know. I used 6.10.10 kernel with ubuntu 22 KDE neon image as test, very well working GPU accel operation. Now there is noble based I see in downloads, but I use headless and bookworm based(don't need GUI/HDMI).

Ii your first log with 6.1.75 kernel I see: [ 48.606684] nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10 [ 48.606692] nvme nvme0: Does your device have a faulty power saving mode enabled? [ 48.606694] nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off" and report a bug [ 48.643584] nvme0n1: I/O Cmd(0x2) @ LBA 0, 8 blocks, I/O Error (sct 0x3 / sc 0x71) [ 48.643602] I/O error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2 [ 48.666942] nvme 0000:01:00.0: enabling device (0000 -> 0002) [ 48.667012] nvme nvme0: Removing after probe failure status: -19 [ 48.680284] Buffer I/O error on dev nvme0n1, logical block 0, async page read [ 48.680286] nvme0n1: detected capacity change from 3907029168 to 0 I recognise 'aspm' from RPi5 related PCIe, but don't know more. But you might look into that. My NanoPi-R6C with alu casing goes to 76 degrees when room 20degres and kernel compile in armbian build. If I put metal can with water on it 47 degrees or so. No fan, Samsung 970 512G PCie 2 x1 NVME. U-boot, BootFAT is on eMMC. Only GMAC ethernet. I currently use 6.1.84 vendor, but if troubles I will boot with 6.12.2 mainline. I have no trouble with NVME or PCIE, only get reboots if I mess with power supply like adding meters or using cheap USB-C PB DC/DC from 12V car battery. Your NVME is PCIe3x4 I think, it is more demanding I think, I am not sure how PD operates on RK3588 boards. vendor and mainline might differ, My understanding is vendor can negotiate >5V, mainline not yet. But I am guessing now. You should put USB-C PD analyser on the powerline for actual status.

Check you powersupply I think. And run armbianmonitor -u and post the URL so we see what versions and so on you are running.

Besides the manual CLI running of VMs with tasksel, there is also a good/acceptable way-of-working when using virt-manager/libvirt/virsh. Problem is already old I see, also the workaround here: So in my case on a NanoPi-R6C, that I just did upgrade, so got kernels: -rw-r--r-- 1 root root 33792512 Dec 5 18:28 vmlinuz-6.12.2-current-rockchip-rk3588 -rw-r--r-- 1 root root 39705088 Dec 1 18:38 vmlinuz-6.1.84-vendor-rk35xx I replaced: <vcpu placement="static">2</vcpu> with: <vcpu placement='static' cpuset='2-3'>2</vcpu> meaning now my home automation VM runs on 2x Cortex-A55 and I rebooted using the 6.1.84-vendor-rk35xx kernel. So far so good. This is great as I want also to do some video transcoding HEVC->H264 in the backgound (live) and hopefully also RKNPU experiments.

Indeed not really a tutorial. Also ROCK 3A has SPI, which is a not the case for my BananaPi M1, NanoPi-NEO, NanoPi-R6C. I'll see what that brings. But the issue is generic Armbian, personally for me like 2+ years or so that I am trying to figure out the best way of working. For my 5x NanoPi-NEO I have simply cloned the first part of the SD-card long time ago, split/resized the root Ext4 into bootfs (Ext4) and rootfs (Btrfs), so standard Armbian/Debian kept working. I also tested with an EFI+GRUB layer (openSUSE) which then offers easy multi-kernel at boot via grub serial console, but I did not figure out how to enable S/P DIF and 1-wire and other GPIO's there.

As listed in the topic, this is my desired and actual partition table setup for a lot of my computers. The U-boot 'partition 0' is typically somewhere in sector 1 till where partition 1 starts and only for SoCs/boards that do not understand any filesystem, like Allwinner and Rockchip based platforms. Also old BIOS PCs actually. It can be MBR or GPT (+hybrid) if more than 4 partitions are needed, for multi-boot, like adding Linux to a new Win11 pre-installed PC. The FAT is ESP or just type 0x0c/0x0700. Now I am struggling a bit with the case where a preinstalled ROCK 3A (RK3568, board ordered, not delivered yet) image has FAT mounted in /boot. RaspberryPi and UEFI PC have 1st FAT mounted on /boot/firmware and /boot/efi usually. For fast and easy multi-kernel management, I want to have the kernel file/image to be there as vmlinuz-<version> on Btrfs as master/base and not as file "Image" on the FAT. For my NanoPi-R6C (RK3588s) I made and extra multi-OS capable script that copies files from Btrfs to FAT as I see no way the default Armbian methods can handle this correctly. Maybe I miss some info, but I needed to fix bootup several times as something related to boot.cmd and/or armbianEnv.txt was not correct. To not risk any actions from existing tools (on any OS) I use /boot/uboot to mount the FAT partition 1. I also have /boot/tftp and /boot/vfat, for other purposes and workarounds, but that is another story. By having an own hook script for dracut and/or initramfs, I could leave the out-of-the box FriendlyElec Android/OpenWRT u-boot loader (2017.x) in the first 32k sectors as is, without knowing much about Rockchip ROM loader and offsets etc. AFAIK, the default 24.10 U-boot config is to not have Btrfs included, so I kept it like this so far. I have build own U-boot with Btrfs, removed the FAT and made Btrfs partition 1 as test for 64-bit QEMU imagefile and 32-bit AllwinnerH3 SD-card. So then the symlinks for kernel, uInitrd, DTB are used without any further changes in Armbian scripts or so. However, that same OS image (whole SD-card or as image file) does not boot in a VM then (virt-manager, EFI needed). I normally add grub-efi etc so there is a /boot/efi/EFI/... to do a default UEFI boot with the same mainline based rockchip-rk3588 kernel. That is really great option to do some initial config and so on before writing SD-card (and going outside where the real board is / will be). So the question is now: How can I keep the desired partitioning scheme and filesystem formatting, but get rid of my own initramfs hook and double/extra boot.cmd ? My current own script (pseudo-code) does not use optional moves but always copies (see /etc/initramfs/post-update.d/99-uboot for original): # $1 is kernelversion string echo "update-initramfs: U-boot: copy DTBs to boot partition" >&2 rsync -ac /usr/lib/linux-image-$1/ /boot/uboot/dtb/ echo "update-initramfs: U-boot: copy kernel to boot partition" >&2 rsync -ac /boot/vmlinuz-$1 /boot/uboot/Image echo "update-initramfs: U-boot: copy uInitrd to boot partition" >&2 cp -a /boot/uInitrd-$1 /boot/uboot/uInitrd echo "update-initramfs: U-boot: done." >&2 U-boot by default does not scan all disks AFAIK, it only wants/sees boot.scr on partition 1. An workaround is to place the FAT after the rootfs, so partition number 2-128 (or 2-4 in case MBR). That works for UEFI based, but not for RaspberryPi3 and older. For RPi4 I am not sure.

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.