eselarm

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.