eselarm

It is here https://www.armbian.com/nanopi-neo-2/ But I don't know the details of the NAS Hat. Maybe post an URL. It is AllwinnerH5 I see, so 64-bit and if NAS HAT is basically a JMicron USB-SATA chip, it should work more or less out of the box. For get about that old Friendlyelec image I would say.

It is good that you mention 'Ubuntu' as that differs of course from Debian (what I use for my armhf boards). I have always done in-place full/dist-upgrade, the boards work fine, for years already with Armbian (Bookworm now). What I do in such cases is download a minimal latest/working image and loop mount it somewhere and look what is in the files there. But it also can simply be some internet routing issue or something not in sync or so. Or maybe prepare for transition to noble, that is a bit guessing, but maybe that gets more care now.

It is indeed super easy to work with the concept of: 1 version of an OS = 1 SD-card or 1 storage device However, there have been bootmanagers like GRUB or just in UEFI BIOS hitting DEL or F8 key that enable you to have/install multiple OSses on 1 storage device. Small/cheap/embedded devices like SBCs or routers or TVboxes usually are strictly 1 OS, already because of the special HW and chips need a dedicated firmware/kernel. So only the OS of the HW vendor is used in principle. But Armbian and most other Linux distros are complete Desktop capable OSses like Windows or MacOS. There is a lot of SW functionality available to have multiple versions/distros installed. You can have up to 128 partitions, I usually keep the first 4 for Windows, then add another 4 or so for various Linux OSses/variants. The trick is you need to know how to shrink partitions, then you can add multiple yourself with a partition manager tool (fdisk, gdisk, parted, etc). I format the extra Linux partitions not with Ext4 but with Btrfs. That allows me to resize them online, so the OS itself is running from it when resizing is happening. So no need to take out the storage device (SD-card) and do that on a laptop or so. In addition, Btrfs supports snapshots, so within 1 partition/filesystem one can easily make a read-only copy(=snapshot) of the working installation and then from there install new beta or testing packages. If that turns out not to work or complete mess up things, it is rather easy to go back to the snapshot copy (the working installation). This might sound like magic, but Opensuse Linux offers this already for almost a decade and it is done at startup of the PC. Of-course that assumes HDMI/keyboard perfectly working, that cannot be assumed for many embedded systems where Armbian is running on. So to interact at startup time, you need a serial console cable (cost 2 dollar), then there is also the option to have some menu selection (just text, selecting a number or so). The new U-boot can offer that as far as I can see, but it is not something Armbian can easily have as default. It cannot know what other OSses are wished/installed/running. The Armbian build system just generates 1 bootable image for a certain HW board. You can select to use Btrfs for the rootfs, so then it is some btrfs commands to transfer that online from the image somewhere on a NAS to the eMMC or NVME of the SBC. The OS or partition selection at boot-up/power-on can all be put in a script. Sofar, I just edit only armbianEnv.txt (the rootdev= line) and make sure the correct files are on the FAT-formatted boot partition. If that works for you also depends how much special HW I/O (overlays etc) you use.

8x 1404.10 MB/sec = 11232.8 Mbit/sec = 11.2328 Gbit/sec I don't know if you mix bits and Bytes. If not, how many lanes and at what speed are used ?

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.