eselarm

Maybe have a look again: The NanoPi-R6S has 2x 2.5Gb eth and 1x 1Gb eth and soldered eMMC and a openWRT variant pre-installed. Can be ordered with all metal fanless case. I ordered the C variant as I wanted an M.2 M-key for my already Samsung 970plus 500GB NVMe SSD. Idle is about 1.5 Watt with Armbian vendor kernel but it runs various other distros as well with a Armbian rockchip64 kernel. As indicated, I use mine as a generic compact computing box currently, but I can imagin people use the S variant as router as is.

I did this: sed -i 's/buster/bookworm/g' armbian-image-release sed -i 's/21.05.1/25.2.3/g' armbian-image-release But I have motd stuff all muted as all is CLI/remote/ssh/unattended only. It is only for the case that in 1 or 2 years from now I don't get confused by 'buster' again. But I think this file gets orphaned for people doing in-place upgrades (not wiping SD with new image at least. I use it only to see when and how I got the new SBC and architecture/SoC running first time when not knowing much about a platform. For the 5 NanoPi-NEOs, they are all copied/cloned from just the first one I bought and got working and modified so it is a partition structure (Btrfs for root at least) that fits my regeneration-from-backup-NAS script for all Linux clients. After the clone action, the package tooling (and sources.list* contents) determine versions. What matters for me is MACaddress essentially (and some other keys and UUIDs). I only use os-release to see what distro flavor it is. And sometimes 'hostnamectl status' to see what is running.

On my NanoPi-NEOs I have seen this several times/years /etc# grep -d skip buster * armbian-distribution-status:buster=eos;upgrade=bullseye,bookworm,trixie,testing armbian-image-release:DISTRIBUTION_CODENAME=buster mime.types:application/rpki-ghostbusters gbr grep: motd: No such file or directory So I guess those files need some other text

works for me using wget in Linux terminal

I have been using 64-bit x86-64 and aarch64 virtual machines as router since 2016, in combination with a simple managed switch that separates and/or combines VLANs depending on ISP and physical connection (ADSL, 4G, fiber). Currently RPi4 where the router VM is 2 cores and 768MiB and connects to 'LAN' and 'WAN' VLAN/bridges. I can still max download at 350Mbps which is my max fiberspeed. I also have a NanoPi-R6C that can replace the RPi4 eventually, it currently serves as faster clone/backup/development, like routing everything via 4G smartphone for example.

I think you might need to have Secure Boot disabled. It might be enabled by default in newer UEFI firmware.

Yeah what version... You need to be more precise, but I guess you don't have a serial console/debug cable connected so you can show at least yourself what the board is doing. This way, at least I can't help you. Also you can interrupt U-Boot and via commands (see U-Boot help on various websites) check for existence of storage interfaces/devices. It is before the kernel is loaded.

So SPI flash is not all zeros, you have it filled with that U-Boot version. In the log I see mmc0, but I might be that this old U-Boot in SPI flash somehow hides it. I would make sure you boot a mainline U-Boot. You need a serial console cable to check which U-Boot from which device is loaded and used.

I assume 'without success' refers to: all zeros in 'SPI flash chip'. There could be other effects as well. All Armbian Rockchip kernels have eMMC (just '/dev/mmcblk*' essentially) fixed/builtin in the kernel so in vmlinuz, no initrd or overlays needed. I don't know OP5+ HW, but note that you can have 3 bootable storage devices on a Rockchip based SBC where U-Boot can be loaded from. So besides SPI, also eMMC and/or SD-card can contain a U-Boot bootloader (see first 16MiB of those devices). If so, then the question is what version of U-Boot? Besides lacking a mmcblk dev, like is the case for example if I use an old version of EDK2 UEFI on my NanoPi-R6C (RK3588s) on the eMMC(!), It might be that a mainline U-Boot version does not work with vendor kernel. I had that for my Rock3A for example (kernel crash).

If your userspace is also still Bullseye, you have to provide more info or just figure out yourself. I updated my BananaPi-M1 earlier this week, but runs Bookworm. I need to look-up what U-Boot I have installed, but I have a serial console cable permanently connected to another SBC, so in case it does not come online (no IP connection), I look at what the serial console port spits out. That is what you also need to do I guess. Kernel 6.6.75-current-sunxi work fine for me, was unattended upgrade+reboot.

At least the Armbian U-Boot .deb packages and also what is written in the image bootsection between partition table and 1st partition is not capable of reading Btrfs. So If you want Btrfs for root filesystem, you need 2 partitions: a first small one formatted FAT or Ext4 for boot files (kernel, initrd, DTB, overlays) and then 2nd for rootfs Btrfs formatted. I constructed this manually for my old 32-bit NanoPi-NEOs, in the past, but if you do a custom Armbian compile/build selecting Btrfs for rootfs (also with additional Zstd compression) it gets all done out-out-of-the-box. If you want a single partition, build U-Boot yourself, with BTRFS enabled. It are 2 settings you need to set to YES. Then write that binary to the bootsection and it can read boot.scr (and armbianEnv.txt. etc) from that 1 single Btrfs partition. I can lookup some old topics here on the forum, I currently keep a 2 partition scheme as I use various U-Boot blobs (also from Radxa) so an extra FAT partition is a bit more failsafe when all there is a serial console cable. It also is then the same as a UEFI system, that also needs a FAT formatted partition where a bootloader and/or bootmanager is located.

Ran a build, it packs overlays: [🌱] Packaging linux-dtb [ rockchip64 linux-rockchip64-edge ] [🔨] [ 21M] /local/s0/armbuild/rock-3a/build/.tmp/work-efccbebe-0297-4492-8451-549f4047d14e/kernel_dest_install_dir-w5E9G/dtbs [🔨] └── [ 21M] rockchip [🔨] ├── [ 75K] overlay [🔨] │ ├── [1.9K] hinlink-h88k-240x135-lcd.dtbo [🔨] │ ├── [7.2K] README.rockchip-overlays [🔨] │ ├── [ 459] rk3308-b@1.3ghz.dtbo etc. /local/s0/armbuild/rock-3a/build/output/debs# dpkg --contents linux-image-edge-rockchip64_25.05.0-trunk_arm64__6.14.0-S38fe-D0000-P6158-C3a01H3d80-HK01ba-Vc222-B9bbb-R448a.deb | grep "rockchip/overlay" | grep README -rw-r--r-- root/root 7355 2025-03-30 11:34 ./usr/lib/linux-image-6.14.0-edge-rockchip64/rockchip/overlay/README.rockchip-overlays So my local build is fine; seems something wrong in the 'Armbian build cloud infrastucture', I don't know anything about that.

Indeed they are copied or symlinked there from .deb package: linux-dtb-edge-rockchip64 But also that package does not include any overlays. I (re-)installed this linux-dtb-edge-rockchip64 package again now (trunk.313 instead of trunk.311 yesterday) and also that package lacks overlays. E.g. check with: dpkg -L linux-dtb-edge-rockchip64 | grep "rockchip/overlay" So even that there are 2 Armbian packages containing the same set of dtb+dtbo files, none of those 2 edge packages contains overlay files. So it seems something wrong in Armbian build, maybe only packaging, maybe even they are not build/compiled. This is actually a test for my Rock3A (or new/extra RK35xx still not purchased) to see if I can work with mainline kernels instead of vendor (6.1.99). Note that for 'vendor' the overlays are there. 'current' I don't know, I do not use it at the moment.

I did upgrade my NanoPi-R6C and see that there are no overlays in the linux-image-6.14.0-edge-rockchip64 Debian package; they were there in 6.14.0-rc4-edge-rockchip64 So there is no folder: /usr/lib/linux-image-6.14.0-edge-rockchip64/rockchip/overlay Is this on purpose or some mistake?

It all depends on that specific SBC and lowlevel init code. I don't know your board and maybe you changed U-Boot. But a high-level mitgation is to makes sure you set a MAC address in a NetworkManager connection file, see /etc/NetworkManager/system-connections

OK, this is great, sounds logical that KMS somehow needs to be used but I did not realize. A quick test on my NanoPi-R6C dumping to a .ts file (format mpegts) with ffmpeg from the jellyfin ffmpeg7 Debian package works fine, that is: I use multi-user.target, so CLI only, therefore only clear screen with Armbian bash login prompt with blinking cursor. CPU load is almost 0, CPU clock 408Mhz. The Armbian installation is Bookworm with beta repo enabled, and I know it runs KDE Plasma as well since some months (with both latest vendor and latest mainline kernels). I have not looked at panfrost, I probably did half a year ago, but will need to look at my notes. So it is mainly an out-of-the-box action, except the installation of external jellyfin ffmpeg7 which has rkmpp included. There might indeed be performance issues, but that is not really a surprise to me; An RK3566 is a cost-cut, lowest cost RK35xx, only (lower clocked) 4x Cortex-A55, you cannot expect too much of it compared to 4x Cortex-A55 + 4x Cortex-A76 + faster DRAM, etc found in RK3588. It all depends on what else it running, e.g. libreoffice slideshow or a heavy game.

I am sorry, there is a fatal typo in my sentence; the word 'no' is missing of course. It is like a Faraday cage of course; will edit the sentence

The idea is, at least mine, that you do not use the hole to srcew/fix the antenne, but just use the hole to put a uFL connector pigtail wire from outside to inside the casing. How and what you do with that wire outside I see as trivial issue. The main key point is that there is a no way to have whatever antenna inside the metal casing. A good enough WiFi antenna is just a piece of PCB with the correct metal structures on a tiny coaxial wire with a uFL on the other end that you click on the (M.2 E-Key) WiFi card. Many plastic casings for N100 or so have that PCB just inside with a bit of hot glue. So for metal casing glue it outside somewhere. It is not a matter of 'modern' or 'ancient', it is more that people let themselves fool in thinking that you need those 'modern' things. Indeed you can move the 3D spacial diversity position better in a consumer product, but that assumes that the end-users does better than (MIMO) algorithms in the chipset. There was a time that people only wanted a mobile phone with an 'antenna sticking out'. Even dummy plastic stick/extension worked for higher sales.

I can post some piece of test shell script that I used to test live-transcoding DVB-T2, ran on rk3568 and rk3588s with vendor kernel 6.1.x. The input in my case is TVheadend, is a sort of generic HTTP streaming Have a good look at ffmpeg comandline options (on ffmpeg docs website ) I would say, it is overwhelming, but take your time to tune and understand it. ffmpeg chooses mpegts as container format if the output file extension is .ts, but I added it now explicitly for you. If you want a RTMP server as output ( e.g. NGINX rtmp://vserv ... ) , use -f flv Note that all containers have options, advantages, restrictions. For this test example, 2x HW coding is used, that was my goal, so up to 60fps 1080p works fine on rk3568 and way more/higher on rk3588s. The CPU has almost nothing to do, only the audio is done in CPU. So you first need to make sure HW codec, not CPU, is used by ffmpeg. Then it still might be that the grabbing of screen is a bottleneck. I have no experiene with sway, wayland doing that on low-end ARM soc. Works OK on fast Intel PC X11 some years ago I used that.

See https://wiki.odroid.com/odroid-hc4/odroid-hc4 Odroid HC4 is - Amlogic, not Rockchip - S905X3 has not on-chip SATA, so the HC4 has to use external PCIe connected SATA chip (ASM1061). So completely different system, DTB, kernel. It could be of course that the driver for ASM1061 is missing in a (newer) U-Boot and/or kernel. But you need to provide detailed logs or figure out yourself. Was it working and how ?

I took a closer look at my R6C https://wiki.friendlyelec.com/wiki/index.php/File:NanoPi_R6C_02.jpg The round thing above the USB-C PD is plastic lid/cover that can be pulled out and that leaves a hole of about 5.85 mm, so 6 mm I guess as I could not measure it well. So you can guess that one can stick a uFL connector through it. I don't see how that can be used for R6C, but at least your question answers mine a bit as well as it seems that hole is good for some (random) GPIO wires as well.

On https://docs.lizardbyte.dev/projects/sunshine/latest/ I see: so there is no Rockchip rkmpp, not even ARM. As I indicated, jellyfin has ffmpeg binaries that can use HW encoders in Rockchips https://jellyfin.org/docs/general/administration/hardware-acceleration/rockchip https://repo.jellyfin.org/?path=/ffmpeg/debian/latest-7.x/arm64 Those provide you a core method to grab screen as input and encoded h264 wih e certain container protocol as output. I think output is mostly FLV, RTMP for gaming. I use it for RPi cameras and/with NGINX. Screen/display as input, see ffmpeg docs or see OBS as example. I have no clue what protocol etc sunshine uses. Maybe you configure software encoding but with a script hook somehow with ffmpeg. See how that can be done with MediaMTX for example.

I see from:https://wiki.friendlyelec.com/wiki/index.php/NanoPi_M6 M.2 Connectors one M.2 M-Key connector with PCIe 2.1 x1 for SSDs one M.2 E-key connector with PCIe 2.1 x1 and USB2.0 Host for Wi-Fi&BT So any E-Key WiFi 2230 sized card should work if it has the correct and needed signals. Of course there must be the correct kernel driver modules. I have a NanoPi-R6C, sofar I only unscrewed the bottom plate to put a 2280 M-key NVMe SSD in it. But I might drill a hole somewhere for a GPIO 1-wire or so later this year.

Show U-Boot + kernel version. and maybe much more. My M1 is unused at the moment, I will connect some SATA disk soon, but I don't know If I still have working composite video, that is a problem. I don't have a TV, maybe a USB recording device with composite imput I have somewhere in a paperbox can be use.

Can you maybe tell us what your (end-user) use case is? It might be simply that some feature in HW codec is not supported. What do you feed the encoder and how? And what is your base working method if SW encoding ? Maybe that must be done non-real-time and is that the reason you want HW? How can others reproduce? Also that github is 9 years old. I see some V4L2, but the whole issue is that Rockchip is not V4L2. They have their own rkmpp standard. Same but worse and/or un-usable stuff from Allwinner. Amlogic I don't know. Qualcomm and RPi are V4L2 and also new Radxa Orion O6 SoC AFAIK.