eselarm

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.

This isn't something specific Armbian, so I even would say it is good that armbian contributors don't waste time on it to have it in armbian-config. You just type: 'How to change default window manager' in your favorite search engine and then pick what is listed for Ubuntu or Debian.

What I did for both NanoPi-R6C and Rock3A is install linux-image-vendor-rk35xx and jellyfin-ffmpeg7 The Zero 3W is rk3566 and should have upto 1080p60 H264 real-time encoding speed if you use h264_rkmpp as output codec. Note that this is only CLI and file and/or stream based transcoding. I have no clue if it works in a webbrowser with camera and/or videoconferencing.

Not even building, just adding/installing the edge kernel to a working/running Rock3A image.

While updating/upgrading my NanoPi-R6C, I see there is now: /usr/lib/linux-image-6.13.2-edge-rockchip64/rockchip/rk3568-rock-3b.dtb I do not know if the earlier mentioned patch is included, but at least that DTB file is different from the rk3568-rock-3a.dtb one. So if you add or switch to the beta repo, you can simply install the edge kernel. And as already mentioned in other post, check U-Boot version. If you want generic headless ARM64 computing, use mainline U-Boot and mainline kernel. You can't use a few things like HEVC, H264 (trans)coding, but overall it works fine. I ran even full desktop KDE neon on my Rock3A, it is good Wayland GUI speed. I got my Rock3A 1st week of december 2024, so that was in transition from legacy U-Boot to mainline U-Boot and also 6.6.x to 6.12+ kernel. 6.12+ (the rk3588 or now rockchip64) has several great features enabled/included by default like was already always default in vanilla Debian AMD64/ARM64 kernels, so easy to get things working like for PC/AMD64.

Various things can be wrong; Yours might have an other cause then the one from @ff255. In the posted U-Boot log I also see JMicron; that brand is notorious for failing UAS and trim, although one should see errors (from U-Boot). Also the U-Boot shown is older and not Armbian originated I see. Also compression type for initramfs might be the failure reason. For my RK3688s and RK3568 SBCs, it really makes a differences what U-Boot I use. For mainline U-Boot, general Linux might/can work better, but some HW support might go wrong. So look what your objective is, what is the use-case of the SBC. You can make sure newer U-Boot is used, I don't know if it is available for rock64 family. Ultimately, those 6.12+ mainline kernels support EFI and virt virtual machines, so the whole image content except the bootloader should work in an aarch64 virtual machine; there you could see if kernel + generated initramfs is the problem, or just rock64 DTB, U-Boot on your board. Or as said the storage chain. I have seen endless issues with RaspberryPi(4) that are not a Linux issue, but just some HW/firmware issues originating from RPI platform. Can be similar for other brands boards.

I got 302.87 MB/sec with an older SATA SSD on the "01:00.0 SATA controller: JMicron Technology Corp. JMB58x AHCI SATA controller". That was with a 4T HDD on the second port of that controller. Have not used SATA SSD with native/on-SoC SATA controller. The fear is that when using this dual-port JMB for SSD+HDD and later 2.5Gbps ethernet, that the pcie2x1 will be the bottleneck (when Rock5B or so). An SSD caching a HDD involves more traffic on the busses than just a JBOD setup. I have had such a bottleneck in the past (for Intel motherboard, 6x SATA3). I'll have to do detailed calculations if this is the case now for Rockchip SBC. With NVMe, pcie3x2 one can see/assume there will be no bottleneck and future is NVMe, I likely won't buy new HDD's. Advantage for native SATA is likely not real for many people. But I like as much as possible on the same SoC, for various reasons. I know many people will buy an RPi5 or so and some USB3 enclosure for HDD, but I have had enough of such a setup (issues with USB3). Count the amount of extra entities you will need drivers etc for. As I indicated earlier, it is comparing Intel solution with something Arm (Rockchip in this case), not adding extra foreign interface chips. For JMicron, always the question if features like trim work. Current quick test (2017.09-armbian (legacy package) U-Boot, armbian vendor kernel 6.1.99😞 root@rock3a:/local/s0/tmp# dd if=/dev/nvme0n1p12 iflag=direct bs=4M of=/dev/null count=10k status=progress 42253418496 bytes (42 GB, 39 GiB) copied, 31 s, 1.4 GB/s root@rock3a:/local/s0/tmp# time dd if=/dev/zero of=dummyfile oflag=direct bs=4M count=1k 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 7.71642 s, 557 MB/s root@rock3a:/local/s0/tmp# hdparm -t --direct /dev/nvme0n1p12 /dev/nvme0n1p12: Timing O_DIRECT disk reads: 3082 MB in 3.00 seconds = 1026.81 MB/sec root@rock3a:/local/s0/tmp# time dd of=/dev/null if=dummyfile iflag=direct bs=4M 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 4.09936 s, 1.0 GB/s root@rock3a:/local/s0/tmp# hdparm -t --direct /dev/sda /dev/sda: Timing O_DIRECT disk reads: 580 MB in 3.01 seconds = 192.95 MB/sec Another note now is that system idle powerconsumption is 3.74 Watt. I use another HDD now, but I think it is the NVMe that is not going in powersave, aim is about 2W idle. So more research, measurements, etc is needed. But I still have not done/enabled the actual caching setup. That is a critical thing as any disturbance in the uptime and relation between NVMe and HDD will ruin the 8T filesystem badly. So first will see if that works for a month or so, when rsync, scrub, differential send|receive, power cut, etc.

I have copied/merged the latest Radxa rk356x kernel from the official latest Radxa Bullseye CLI image into Armbian Bookworm that runs on my Rock3A and I see there is the file: /usr/lib/linux-image-5.10.160-39-rk356x/rockchip/rk3568-rock-3b.dtb Same .DTB file is not in Armbian vendor (6.1.99) or mainline/current (6.12.13), which means no Armbian support for Rock3b. But if you use a current Rock3A image as base and copy that old 5.10 kernel into the image and also put the 'rk3568-rock-3b.dtb' in the armbianEnv.txt, I guess it will boot and recognize all Rock3B hardware. Rock3A images use an extra FAT boot partition, so make sure you understand which files and under which names you need to copy. I mount the bootFAT in a own custom folder /boot/uboot, so I keep multiple kernels in /boot (which is rootfs) and copy a particular one to the bootFAT.

That is weird; 'ssd-sata' is not nvme. And it is a rk3588s, so which multiPHY is then put in SATA mode? Not the one operating (connected to) the NVMe device one would assume. I do not know HW architecture of OPi5, maybe you lost USB3 function now? And where did you get that overlay from? I don't see it: /usr/lib/linux-image-6.1.99-vendor-rk35xx# find . -name "*sata*" ./rockchip/overlay/mixtile-blade3-sata2.dtbo ./rockchip/overlay/orangepi-5-plus-sata2.dtbo ./rockchip/overlay/orangepi-5-sata.dtbo ./rockchip/overlay/radxa-cm5-io-sata.dtbo ./rockchip/overlay/rk3566-roc-pc-sata2.dtbo ./rockchip/overlay/rk3588s-roc-pc-sata0.dtbo ./rockchip/overlay/rock-3a-sata.dtbo ./rockchip/overlay/rock-5a-sata.dtbo ./rockchip/overlay/rock-5b-sata.dtbo ./rockchip/overlay/turing-rk1-sata2.dtbo ./rockchip/overlay/yy3568-sata2.dtbo Or is it renamed 'orangepi-5-sata' ? Are you sure it is actually loaded?

Another trial: I put the legacy rock-3a u-boot in the SPI, which is: U-Boot SPL 2017.09-armbian (May 20 2024 - 00:46:51) Then, with kernel 6.1.99-vendor-rk35xx, both NVMe and SATA are available when using the 'rock-3a-sata.dtbo' overlay. It failed to see/boot from SD-card, but TFTP and NVMe work. The newer/mainline kernels still only SATA if overlay used. If no overlay used, only NVMe. MAC address is changed and several other issues, but with this SW combination, I can test the HW/system performance w.r.t. 'caching' NAS I think.

you need to do: sudo apt install virt-manager Then it should also have installed qemu-system-arm package which contains the core virtualization program for 32-bit and 64-bit Virtual machines that you can create and run with/via virt-manager GUI. Note tha you run vendor 6.1.x kernel on big-LITTLE rk3588 SoC, it will fail/crash any VM if more than 1 core allocated or not fixed the CPU types in the VM (xml code). So best to just use 1 core. Otherwhise switch to mainline/current 6.12+ kernel, there the bug/problem is fixed.

That I consider a workaround. There are 3 SATA capable SERDES ports available on RK3568, similar for other Rockchips. What I see is that idle powerconsumpution went up by 2 Watt when using an extra JMB PCIe-SATA chip, I have not look in detail why that is. I am aiming for battery powered as well, so when I see that Rock3A itself is roughly 2W idle (with mainline kernel), doubling that would make an other platform/SoC more or less a better solution. SoC powerconsumption does not really matter if the 3.5 inch HDD spins all the time, but that is not the case/plan. Also a SATA SSD is an option for connecting. I do not have a RK3588 (but have a RK3588S), I indeed guessed that SPI+NVMe+SATA will work on Rock5B when using 'rock-5b-sata.dtbo'. Or do you use a different overlay with edge kernel? Kernel 6.1 has a problem that it does not allow seamless moving of virtual machines (between A76 and A55). Mainline (6.8+ etc) does not have that problem. There must be some (longterm) benefit for using Arm platform instead of continuing Intel (like N100, that is the alternative I keep in mind). So maybe Rock5B 16GB I should buy, that would be a good successor of my current Intel based NAS (and VM host as well every now and then).

I have currently this on SD-card: root@rock3a:~# ls -1 /boot/vmlinuz-* /boot/vmlinuz-5.10.160-39-rk356x /boot/vmlinuz-6.12.12-current-rockchip64 /boot/vmlinuz-6.13.1-edge-rockchip64 /boot/vmlinuz-6.1.99-vendor-rk35xx Only with the 5.10 kernel from Radxa, I get both NVMe and SATA when I use the overlay 'rock-3a-sata.dtbo'. With 6.12 and 6.13, there is only SATA, no NVMe. 6.1 lets the kernel/board crash, I have not further looked into that. So I can reliably use the SATA HDD, also hd-idle spindown works, I monitor the powerconsumption per day on 12V level and it is great. So as a slow clone/backup NAS it works and is acceptable. But ultimate plan is to make it a fast/main NAS, using the NVMe as cache and also for OS, so only SPI+NVMe+SATA. 5.10 kernel lacks various Btrfs features, so that is a no-go. I need at least 6.1, although I know weird virtualization tricks to get it to work on a functional level, but then also, I might hit issues with KVM on the Radxa rk356x kernel. I got the kernel from: https://radxa-repo.github.io/bookworm/files.list Regarding power, I now use 12V as base (common GND), feed 12V into the Rock3A USB-C connector and 3.5inch 12V pin on HDD and tap 5V from Rock3A GPIO and that feeds the 5V pin of the HDD. As said, that works very nice and stable. So it still looks like the 'rock-3a-sata.dtbo' overlay 'hides/disables all PCIe', where it should not do anything with the PCIe3x2 where the NVMe is on. I saw this: https://patchwork.kernel.org/project/linux-rockchip/patch/20250106100001.1344418-2-amadeus@jmu.edu.cn/ but not sure if it is related.