Harleyyyu

Version 3.1.0 Has been released! I won't be going into details like last time, this build also includes the fixes for "known issues" from version 3 Alpha build. Bugs Found? Open a ticket in https://github.com/Harleythetech/openauto-rk3229-armbian/issues Download: Github: OpenAuto RK322x - oark322x-3.1.0-beta

@ArturHey Try flashing the TrustOS at 0x2000 since that's where your board is looking for TOS, then flash U-Boot at 0x4000. Basically swapping them out. if anything different happens, let us know.

@ArturHey I Happen to have a backup of multitool on my pc, I have uploaded it to my github page for everyone to download. https://github.com/Harleythetech/RK322x-multitool/releases/tag/rk322x-multitool if you don't need to backup your current operating system you can also just use RKDevelopTool to flash your armbian image to your board. https://github.com/rockchip-linux/rkdeveloptool

Version 3 Has been released! Complete UI Overhaul The entire user interface has been rebuilt from the ground up using Qt QML, delivering a modern automotive HMI experience optimized for touchscreen displays. New Home Screen - Large centered clock with configurable 12-hour/24-hour format - Gradient background (#00021A → #001D3F) - Swipe navigation to media player - Clean, minimal design with Readex Pro typography New Bottom Navigation Dock - 5-button dock: Home | Music | Android Auto | Volume | Settings - Always visible for quick access (except when running AA) - Icon-based navigation with visual feedback New Music Player - Album art display with track metadata - Playback controls (Previous, Play/Pause, Next) - Integrated with system media Redesigned Settings - Modern two-column layout with left sidebar navigation - 8 categories: General, Video, Audio, Input, Bluetooth, WiFi, System, About - Toggle switches, sliders, and radio buttons - Real-time system info (CPU temp, memory, frequency) - Live date/time display in header New Features - 12/24-Hour Time Toggle: Switch between time formats in Settings → General - Readex Pro Font: Variable weight font for consistent automotive typography - Modernized UI: The Original Crankshaft-NG was just not suitable for car use so i had to refresh it Technical Changes - Qt Widgets → QML Migration — Complete rewrite of UI layer - UIBackend Bridge — New C++ backend class exposing 50+ properties to QML - EGLFS Optimized — Designed for direct framebuffer rendering - No Animations — Instant transitions for 1GB RAM constraint - Centralized Theming — Theme.qml singleton for consistent styling Removed - GPIO settings (not applicable to TV Boxes) - DAC settings (using ALSA directly) - RTC settings (no CMOS battery, NTP only) - TSL2561 light sensor support (Pi-specific) - Camera module settings (Pi-specific) Bug Fixes - Fixed Cursor issue by utilizing Cursor plane (41, z-pos 2) - Fixed std::mutex missing include in RtAudioOutput - Fixed ColorOverlay import for Qt GraphicalEffects - Fixed time display showing 24hr with AM/PM suffix - Fixed buffer overflow warning in FFmpegDrmVideoOutput - Fixed QCursor conversion error in autoapp.cpp Known Issues: - Music player metadata not populated (requires media service integration, will be done in the next patch) - Volume popup not implemented (this require modifying the asound.conf before implementing) Issues? Open a ticket in https://github.com/Harleythetech/openauto-rk3229-armbian/issues Download https://github.com/Harleythetech/openauto-rk3229-armbian/releases/tag/oark322x-V3.0.0-alpha

Update: The reason i haven't released the cursor patch is because im working on the GUI. I managed to now use EGLFS with FFMPEG, so it feels right that we modernized the crankshaft-ng GUI to feel more modern and usable.

@jock Thank you for the information, I just updated the thread removing the requirement to use CMA=256. as per openauto it doesn't require cma to be set at 256. Will release the cursor patch with some adjustments to ffmpeg and some GUI changes (mostly settings adjustment)

@jock I figured out why the cursor doesn't show and it's not an armbian issue, the issue is more on how i implemented ffmpeg (previously Kmssink) on openauto and also the same reason why i can't use eglfs for the gui is that i had set ffmpeg to use plane 31 (primary plane, zpos 0) when streaming Android Auto. Since I am forcing the video stream directly onto the Primary Plane (Plane 31) via DRM, the hardware VOP (Video Output Processor) stops scanning out the Linux Framebuffer (/dev/fb0). This means that while Qt is still technically "running" and drawing the mouse cursor to the framebuffer in software, that buffer is simply never sent to the screen. The video stream completely overrides the UI layer. I did manage to fix it tho, since the RK322x SOCs support Tri-Plane, I had to patch ffmpeg to utilize the Cursor Plane (plane 41). Now when AA starts ffmpeg initializes the video on the Primary plane as usual, but simultaneously commits the ARGB cursor buffer to Plane 41 using the shared DRM file descriptor. This allows the VOP to hardware-composite the mouse cursor directly on top of the video stream, finally making it visible without breaking the zero-copy pipeline. As per CMA=256M, ffmpeg was throwing buffer allocation warnings. Interestingly, these warnings persist even with CMA set to 256MB—so the larger CMA didn't actually silence the logs as I initially thought. ffmpeg benchmarks actually run successfully on both 16MB and 256MB despite the warnings. However, I decided to keep the requirement at 256MB purely as a precaution. Given that a 1080p NV12 pipeline with multiple buffers can eat up memory quickly, leaving it at the default 16MB felt risky for long-term stability in a car environment, even if it 'technically' runs. PS: i haven't posted the build with the cursor patch

Inspired by the incredible work @jock and @ilmich have done to make the RK322x platform stable on mainline Linux, I decided to tackle the application side of things. My goal was to turn these "e-waste" TV boxes into fully functional, low-latency Android Auto head units for our cars. This fork of OpenAuto is built as one of my "Is it possible to turn this into that?" projects. It turned out to be one heck of a nightmare to pull off, but at the same time a lot of fun because I can see the potential of these TV Boxes as something you can actually put in your car and turn into a usable head unit! System Requirements Target Device: RK322x TV Box (e.g., MXQ Pro 4K). OS: Armbian Bookworm or Trixie (Kernel 6.1+ recommended). RAM: 1GB recommended. FFMPEG Installed: This build requires a specific build of ffmpeg that can be found here. Release: v2.0.0-alpha This release represents a major architectural overhaul. I have removed heavy dependencies (PulseAudio, QtAudio, GStreamer) in favor of a lean, direct-to-hardware pipeline using RtAudio (ALSA) and FFmpeg v4l2_request. Download: https://github.com/Harleythetech/openauto-rk3229-armbian/releases Technical Details Video Engine: Switched from GStreamer to a custom FFmpeg + V4L2-Request backend. Leverages the v4l2drmprime patch set for Zero-Copy rendering. Enables full hardware H.264 decoding on Rockchip stateless decoders. Result: Stable 1080p 60fps stream on a 1GB RAM device. Audio Overhaul: Replaced PulseAudio and QtAudio with RtAudio. This creates a direct, low-latency path to the ALSA hardware driver. Display: Targets linuxfb (Framebuffer) by default instead (eglfs and ffmpeg have issues when you run them together due to DRM master lock) Configuration This release requires a specific ALSA configuration to allow audio mixing (dmix) without PulseAudio. Create/Edit /etc/asound.conf: pcm.!default { type asym playback.pcm "dmix_hdmi" capture.pcm "plug_null" } ctl.!default { type hw card 0 } pcm.plug_null { type plug slave.pcm "null" } pcm.dmix_hdmi { type dmix ipc_key 1024 ipc_perm 0666 slave { pcm { type hw card 0 device 0 } format S16_LE rate 48000 channels 2 period_size 512 buffer_size 4096 } bindings { 0 0 1 1 } } Known Issues Invisible Cursor: The mouse cursor works but is currently invisible when the FFmpeg video backend is active (rendering layer order issue). Backend Fallback: In rare edge cases where DRM initialization fails, the app may incorrectly default to Qt software output. Probably more, i haven't tested it that much Development Status: Active & Seeking Contributors Currently, I am the sole maintainer focusing on the RK322x platform (specifically the RK3229). I am actively looking for developers interested in expanding support to other devices (such as RK3328, RK3399, or Allwinner H3/H6). If you have experience with C++, Qt, or V4L2/DRM and want to help turn these TV boxes into capable head units, contributions are highly welcome! Repository: https://github.com/Harleythetech/openauto-rk3229-armbian Credits: @jock and @ilmich for ffmpeg patches and the csc-armbian-for-rk322x-tv-box-boards opencardev for openauto and aasdk

Okay here's a huge update and a win for me: While i stopped playing with the kernel, i focused on improving openauto by replacing GStreamer with ffmpeg and utilizing the same RTAudio to Alsa Patch which achieved the following things: 720p 60 1080p 60 FPS Stream (cma set to 265) RTAudio to Alsa (Video and Audio are synced) Low Latency Touch or Mouse Response Now while there is still some bugs like when i disconnect my phone by pulling the usb cord results into a segment fault i'd say that's just a minor bug that can be fixed along the way. Huge thanks to the experimental ffmpeg patches and the guide @jock PS: hopefully someone can help me improve the code even more, i know this board is capable of being an android auto head unit for those who like to build it on their own: Github: Openauto-rk3229-armbian (requires you to compile aasdk)

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

Update 3: almost there! root@rk322x-box:~# dmesg | grep -i drm [ 6.738341] systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm... [ 6.912602] systemd[1]: modprobe@drm.service: Deactivated successfully. [ 6.914174] systemd[1]: Finished modprobe@drm.service - Load Kernel Module drm. [ 11.565138] [drm] Initialized lima 1.1.0 for 20000000.gpu on minor 0 root@rk322x-box:~# dmesg | grep -i rockchip [ 0.068016] rockchip-gpio 11110000.gpio: probed /pinctrl/gpio@11110000 [ 0.069475] rockchip-gpio 11120000.gpio: probed /pinctrl/gpio@11120000 [ 0.070736] rockchip-gpio 11130000.gpio: probed /pinctrl/gpio@11130000 [ 0.071810] rockchip-gpio 11140000.gpio: probed /pinctrl/gpio@11140000 [ 1.330865] rockchip-rga 20060000.rga: HW Version: 0x04.01 [ 1.339866] rockchip-rga 20060000.rga: Registered rockchip-rga as /dev/video0 [ 1.360435] dwmmc_rockchip 30000000.mmc: IDMAC supports 32-bit address mode. [ 1.360814] dwmmc_rockchip 30010000.mmc: IDMAC supports 32-bit address mode. [ 1.361387] dwmmc_rockchip 30020000.mmc: IDMAC supports 32-bit address mode. [ 1.371466] dwmmc_rockchip 30000000.mmc: Using internal DMA controller. [ 1.371502] dwmmc_rockchip 30000000.mmc: Version ID is 270a [ 1.371594] dwmmc_rockchip 30000000.mmc: DW MMC controller at irq 49,32 bit host data width,256 deep fifo [ 1.372013] dwmmc_rockchip 30000000.mmc: Got CD GPIO [ 1.395186] dwmmc_rockchip 30010000.mmc: Using internal DMA controller. [ 1.395237] dwmmc_rockchip 30010000.mmc: Version ID is 270a [ 1.395356] dwmmc_rockchip 30010000.mmc: DW MMC controller at irq 50,32 bit host data width,256 deep fifo [ 1.395646] dwmmc_rockchip 30010000.mmc: allocated mmc-pwrseq [ 1.402395] dwmmc_rockchip 30020000.mmc: Using internal DMA controller. [ 1.402458] dwmmc_rockchip 30020000.mmc: Version ID is 270a [ 1.402603] dwmmc_rockchip 30020000.mmc: DW MMC controller at irq 51,32 bit host data width,256 deep fifo [ 11.719472] hantro-vpu 20020000.video-codec: registered rockchip,rk3399-vpu-enc as /dev/video2 [ 11.723548] hantro-vpu 20020000.video-codec: registered rockchip,rk3399-vpu-dec as /dev/video3 [ 25.632131] rk_gmac-dwmac 30200000.ethernet end0: PHY [stmmac-0:00] driver [Rockchip integrated EPHY] (irq=POLL) root@rk322x-box:~# dmesg | grep -i hdmi [ 0.055584] /vop@20050000: Fixed dependency cycle(s) with /hdmi@200a0000 [ 0.055722] /hdmi@200a0000: Fixed dependency cycle(s) with /vop@20050000 [ 22.293730] platform 200a0000.hdmi: deferred probe pending: (reason unknown) [ 22.293761] platform hdmi-sound: deferred probe pending: asoc-simple-card: parse error root@rk322x-box:~# ls -l /dev/dri total 0 drwxr-xr-x 2 root root 80 Jan 28 11:49 by-path crw-rw---- 1 root video 226, 0 Jan 28 11:49 card0 crw-rw---- 1 root render 226, 128 Jan 28 11:49 renderD128

So here's the weird thing, whenever i apply my user overlay it refuses to boot (red light stuck). But when i only run the build with the new kernel and stock dtb it works fine?? /dts-v1/; /plugin/; / { compatible = "rockchip,rk3229"; /* Wake up the Projector */ fragment@0 { target-path = "/vop@20050000"; __overlay__ { status = "okay"; }; }; /* Wake up the Cable Port */ fragment@1 { target-path = "/hdmi@200a0000"; __overlay__ { status = "okay"; }; }; /* Wake up the Display Guard */ fragment@2 { target-path = "/iommu@20053f00"; __overlay__ { status = "okay"; }; }; }; Does anyone have a clue why this is happening?

Update 2: 6.16-rc1 works with issues.. Good news: It Loads and registers the rga, vpu [ 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 Issues: swap file is gone HDMI output not working probably more, not sure

Progress update: I managed to boot 6.6.22 with applied hantro and rkdevc drivers in the kernel, I'm not sure if this was already discovered but i found something on the 6.6.22 kernel. Hantro and some Rockchip drivers are found in the Device Drivers -> Multimedia Support -> Media Platform Devices Rockchip Raster 2D Graphic Acceleration Unit Rockchip Image Signal Processing v1 Unit Rockchip Video Decoder (on 6.6.22 this can be found in staging drivers) Hantro VPU Driver Use Reference Frame Compression for HEVC Hantro VPU Rockchip support Hantro VPU Allwinner support Current issues: No Display working, but i got ssh working enough to tell me probably what's wrong with the kernel, Now I'm going to try and do the same but this time with the 6.16-rc1 patches found in Github: Kwiboo/linux-rockchip just to see if that would work also.

@Dangrain Glad to see its working now. please do a guide on it, not only will it help other people it will also help you how to do it again in-case you forgot how to do it haha!

I'm currently trying to build my own kernel for armbian bookworm, using this Github Linux-rockchip: linuxtv-rkdevc-hevc-v2 (6.16-rc1) Goal is to try and make hantro work with native mainline V4L2-Request-API to achieve zero-copy decoding and bypass the legacy Rockchip MPP. i just want to experiment the OS and the VPU it self at this point

@Dangrain If there’s no HDMI, no LEDs, and nothing at all after power-on, that usually means the SoC isn’t even loading u-boot from eMCP. In that state there are no logs to collect yet it’s failing before the kernel starts. Since the same image boots from SD, the issue is almost certainly bootloader placement or compatibility on eMCP, not the OS itself. boot using the sd-card first then try directly flashing the U-Boot to the EMCP and see if that makes it boot 🤷 dd if=u-boot.bin of=/dev/mmcblk1 bs=512 seek=64 sync (device/offset may vary by board)

is there any way to increase the gpu memory? as of right now it's just sitting at 16MiB, i want to set it at 128MiB. I tried doing cma=128M but after rebooting the device it kinda softbricked it. It does boot upto the tty screen but i can't login directly using usb keyboard or ssh. Edit: i was dumb, the reason it bricked it self was due to coherent_memory being set to 128M as well, cma is fine.

@Dangrain The problem might be from the U-Boot, I'm not sure though. It's hard to debug something that doesn't have logs to read

@jock your armbian build (Bookworm) plus my modified version of openauto works now, its done by using kmssink for drm overlay plane for video (Added to codebase) and RTAudio patched to use ALSA. Youtube: OpenAuto - RK322x Test run with Hardware Acceleration if you want to try it here's a prebuilt version of it, armhf compiled. Github: OpenAuto RK322x Armbian, openauto-rk322x-v1 i would love to make it run better on our hardware

@Dangrain ohhh that makes sense now. If SD boot works, you can just clone the SD card into a raw .img. dd if=/dev/sdX of=working_sd.img bs=4M status=progress (assuming you use linux, ubuntu recommended. Also make sure to check your sdcard path) That image already contains the correct bootloader, partitions, and rootfs. Multitool should be able to flash it to eMCP directly.

@Dangrain for you to be able to flash your "frankenstein'd Image" you need to combine those pieces into one, I don't know how you will do that though. Tell me, What's the purpose of your img? like what are you trying to achieve?

To anyone with and an mxq pro 4k v4.0 that has an eMCP memory module in it, If you ever you manage to soft brick your board to the point the maskrom button behind the AV port doesn't work here's the contact points for forcing it to enter maskrom mode. Note: After soldering to the pad indicated in the photo you can connect it to a 5V pad and do the same process and connect it to pc. Remove the connection once you detect that it entered maskrom mode (you might break the eMCP if you keep supplying 5V to it for a long time)

@Dangrain To flash in an eMCP board you can either use the Multiboot image or flash via rkdevtool in linux. eMCP is basically just emmc memory and ram packaged into one chip so the process is almost the same with emmc flash guide and Multiboot flash guide (sd card flash) PS: i have the same type of memory and almost manage to brick it (thankfully i managed to find the eMCP pads to force it to maskrom mode)