@Harleyyyu my 2 cents thought ..... We are talking about a 10 dollars soc . Is already a great milestone it is " just working" Anyway.. If you achieve any good result let's us know

For now i just went back to 6.6.22 version and ill focus on applying ffmpeg patches instead to openauto. Not gonna lie, it was fun seeing even just a small result from trying to build a kernel with hantro vpu working.

@jock thanks for the information! The reason I was experimenting with the kernel is because I’m testing OpenAuto (Android Auto) on top of Armbian-minimal. While MPV works fine with hardware decoding, I noticed that using things like kmssink to process the Android feed (720p, 30/60fps) introduces significant latency between touch input and screen response. For example, in today’s test I tried decoding a 720p 60fps H.264 stream using GStreamer with this command: gst-launch-1.0 filesrc location=test.h264 ! \ h264parse ! v4l2h264dec capture-io-mode=dmabuf ! \ queue max-size-buffers=2 leaky=downstream ! kmssink sync=false While the pipeline runs, the latency is too high for Android Auto responsiveness clicks and touch inputs visibly lag behind the video output. This is why I also tried patching Armbian to kernel 6.16-rc1, which gave me the following devices: [ 1.340230] rockchip-rga 20060000.rga: Registered rockchip-rga as /dev/video0 [ 1.345260] hantro-vpu 20020000.video-codec: registered rockchip,rk3399-vpu-enc as /dev/video2 [ 1.345656] hantro-vpu 20020000.video-codec: registered rockchip,rk3399-vpu-dec as /dev/video3 …but unfortunately, HDMI output stopped working completely, so that approach wasn’t usable for my setup. The goal is still to achieve smooth, low-latency video decoding that can keep up with real-time Android Auto interaction, which is why I’m exploring alternatives like the FFmpeg v4l2-request interface, even if it requires patching OpenAuto. PS: i also just like to explore how the rk322x works, so yeah I've been testing a lot for a few days now. Another thing is i plan to make a DIY head unit with this unused rk3229 box i have

Armbian 25.11.2 Noble XFCE (BSP Kernel: 6.1.115) + PanVk - mesa 26.0 (https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco) + Box64 arm64 v0.4.1 3ec5de03c (https://ryanfortner.github.io/box64-debs/) + proton-10.0-3-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/download/proton-10.0-3/wine-proton-10.0-3-amd64-wow64.tar.xz) + dgVoodoo2 (https://github.com/dege-diosg/dgVoodoo2/releases) + DXVK-stripped v1.7.1 50~60fps@720p (medium/high settings) box64 environment variables: F.E.A.R. Platinum Collection

@shexplorer, connect it to the internal serial port using a USB-to-serial adapter. If you don’t have one, they’re very cheap—search for CH340G on Amazon. Quick safety guide on serial adapters: 1 - Your device has 3.3v serial , check the jumper on the CH340G to make sure its on 3.3v and not 5v 2 - DO NOT CONNECT VCC/3.3v/5v Pin!!! Only connect: ground RX TX 3 - Connect ground from to ground from device Connect RX from usb to TX from device Connect TX from usb to RX from device Let us know if you are having issues with the bound rate or the pinout on your serial header in your device (send us a picture, in that case) Once you get serial, you should see the boot looping endlessly, holding control + c should stop the loop. Then you get an uboot console. there you can chainload your usb or external mmc uboot. With something similar to(ask chatgpt to help you in case of issues): usb start # starts usb devices usb tree # lists devices and partitions usb info # shows USB device info ls usb 0:1 / # lists files on partition 1 of usb 0 fatload usb 0:1 0x82000000 u-boot.bin # 0x82000000 is an example that may work. if it does not, ask chatgpt for other values # u-boot.bin is the usb uboot you want to chanload, might have another name.... ls usb 0:1 will help you find other files # go 0x82000000 # chainloads what you loaded into 0x82000000 memory address. if you change this on the previous line, change it here also. Besides trying to chainload uboot, you can also load linux kernel + initrd + dbt files directly. Again, chatgpt will help you with those commands. But i found chainloading usb uboot easier. It you reach linux console, remember that once you reboot, everything will loop again. So you need to fix what you did to the emmc before rebooting. You have 3 options to fix: 1 - Restore your full backup. -> you get manufactorer android back 2 - Restore 10MB of your backup or johlnx's backup -> you should be able to boot again from usb or external mmc 3 - You can calculate exacly what you need to copy, to maintain your emmc linux but also recover uboot. There should be some space between the partition table data and the 1st partition. Lets imagine, GPT uses 1MB and 1st partition starts at 10MB, you can copy the data between 1MB and 10MB from your backup into the space between 1MB and 10MB of your EMMC. (this is not trivial to do, but again chatgpt can help) This way, you still have a linux on the EMMC, but you have recovered the Uboot env.