CSC Armbian for RK322x TV box boards

[fabiobassa]

@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

[Harleyyyu]

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)

Edited January 30 by Harleyyyu

[fabiobassa]

@Harleyyyu

Your project could be interesting , I would suggest to open a dedicated 3ad on It own so people can contribute.

 

As you have already realized by yourself quite all  hardware and drivers aspects of this rk322x soc have bene investigated by @jockand/or @ilmich

 

But if you achieve any progress on GENERAL drivers and performance that isn't already been discussed or achieved you can came back here to share

 

Thanks

[Dangrain]

Hey just checking in.

I haven't forgotten about this yet, I want to make sure everything is repeatable and possible to do on multiple versions of armbian before I write a guide and confuse a lot of people.

Noticing that mpv doesn't work, I tried to do what jock suggested to Harleyyyu and update to a newer kernel version.

So far... no luck. Seems like the problem boils down to having to write u-boot.bin to the eMCP before burning the actual OS onto it. 

I'll write again if anything goes.

Edited January 31 by Dangrain
Add additional content

[ArturHey]

Issue booting Multitool on RK322x Box (Kingston eMCP) - Red IR Light Only

Hi everyone,

First of all, thank you for this incredible project. Bringing new life to these generic boxes is vital work.
 

I am struggling to boot the Multitool on an "RPC Plus" TV Box. Here are my hardware specs and the steps I’ve taken so far:

 

Hardware Specs:

• SoC: Rockchip RK3228A.
• Storage/RAM: 8GB Kingston eMCP (Chip ID: O8EMCP08-ELSCV100).
• SD Card: 16GB Lexar microSD (Class 10).
• Board LEDs: POWER, NET, and IR.

Since the official download links for the Multitool are currently down (I get a 404 error idk why), I had to compile it myself on a Debian machine using the https://github.com/paolosabatino/armbian-build?tab=readme-ov-file repo and the ./create_image.sh rk322x script. I flashed the 500MB image to a 16GB Lexar card using BalenaEtcher and placed the Armbian minimal forky (6.18.7) image inside the /images folder (file name Armbian_community_26.2.0-trunk.357_Rk322x-box_forky_current_6.18.7_minimal.img.xz).

 

The problem is that the box just won't boot from the SD card. When I hold the reset button and plug the power, the only thing I get is a static red light on the IR LED—no HDMI signal, no activity on the Power or Net LEDs, nothing. Android still boots fine if I pull the card out, so the hardware is okay, but it seems the boot process is hanging.

I've tried both the reset and update buttons with different timings but no luck so far. I’m attaching pictures of the board and the chip. Any help to get this thing past the red light would be great. I'm putting the pictures of the board here in case it helps.

Thanks!

IMG_6826.HEIC IMG_6827.HEIC

Edited Wednesday at 08:18 PM by ArturHey

[Harleyyyu]

@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

Edited Tuesday at 01:25 PM by Harleyyyu

[ArturHey]

Hi, @Harleyyyu, thanks for the copy of multitool. Sadly it behaves just like before. When turning on with the SD card inserted I only get a red LED. 

I saw some people saying they had luck booting from LibreELEC, but I get the exact same behavior.

I do want to keep a backup of my current OS. Any next steps for debugging it? Maybe it needs a shittier SD Card? 

[ArturHey]

UPDATE: Serial Logs and GPT Signature Error on RK3229 (Kingston eMCP)

 

Hi everyone,

Following up on my previous post about the "Red LED" issue with my RK3228A (Kingston eMCP) box. I managed to hook up an ESP32-S3 as a USB-to-Serial bridge to see what’s happening under the hood.

 

The box is communicating at 1,500,000 baud.

 

Here is the log I captured when trying to boot the Multitool from the SD card:

 

Secure read PBA: 0xc04
Secure read PBA: 0x1004
Secure read PBA: 0x1404
Secure read PBA: 0x1804
Secure read PBA: 0x1c04
SecureInit ret = 0, SecureMode = 0
atags_set_bootdev: ret:(0)
GPT 0x631442f0 signature is wrong
recovery gpt...
GPT 0x631442f0 signature is wrong
recovery gpt fail!
LOADER Check OK! 0x2000, 735748
TOS    Check OK! 0x4000, 804945
Enter Trust OS
INF [0x0] TEE-CORE:init_primary_helper:377: Initializing (1.1.0-333-gc9d95d1 #2 2018年 08月 17日 星期五 03:32:22 UTC arm)
INF [0x0] TEE-CORE:init_primary_helper:378: Release version: 2.0
INF [0x0] TEE-CORE:init_primary_helper:379: Next entry point address: 0x61000000

 

 

It seems the bootloader initializes the RAM and Trust OS correctly, but then it hits a GPT signature is wrong error and the recovery fails. This happens right before the kernel should start loading. I have already tried two different SD cards (16GB Lexar and 8GB Generic) with the same result.

 

Given these logs, what should be my next steps?

Edited Wednesday at 08:18 PM by ArturHey

[ArturHey]

[UPDATE] Manual Partition Strategy on RK322x (Kingston eMCP) - GPT Signature Error & TOS Anomaly

 

Hi everyone, 

Following up on my struggle with the "Red LED" issue on this RK3228A box (Kingston eMCP). Since the Multitool wouldn't boot from the SD, I moved to a more aggressive approach using rkdeveloptool on macOS to flash Armbian images and the Multitool components directly to the internal storage.

 

• The Loader Struggle (Samsung vs. Kingston)

I compiled rkdeveloptool on macOS and tested multiple loaders to initialize the RAM/Flash:
• rk322x_loader_v1.10.256.bin
• rk322x_loader_v1.11.253.bin
• rk322x_loader_v1.10.238_256.bin

None of them solved the SD boot issue. Interestingly, they identify my flash as SAMSUNG, even though the physical chip is Kingston:

Flash Info:
Manufacturer: SAMSUNG, value=00
Flash Size: 7216 MB | Block Size: 512 KB | Page Size: 2 KB

 

 

• Tested Images & Offsets (Direct Flashing via rkdeveloptool)

• Armbian Community (6.1.62/Minimal 6.18.7): Tested 0x0 and 0x8000.

• LibreELEC (10.0, 11 and 12): Tested 0x0 and 0x8000.

• Multitool (v1.11 & Standard): Tested 0x0 and 0x2000.
• Educabox (Legacy 4.4.194 / NAND): Tested 0x0.

 

All attempts resulted in "GPT signature wrong", likely because the Secure Boot/Trust OS expects the Android rkparameter structure instead of a standard GPT. When I then changed the GPT table in parameters.txt, it sometimes wouldn't even give me a signal via serial. 

 

• The Strategy: Manual Image Construction (Partition Replacement)

Since full image flashing failed, I followed the "Partition Replacement" strategy to manually construct the layout. I read about it in a post titled long story LINUX on rk3229 rockchip by @fabiobassa: manually constructing the partition layout to satisfy the Bootrom's legacy requirements while injecting Armbian components into specific offsets.
 

The parameter.txt Modification (The Key Step):

The root cause of the "GPT signature wrong" error was the mismatch between the Android partition table expected by the device's Secure Boot/Trust OS and the standard GPT layout of Linux images.

 

Original State: The stock parameter.txt defined over 12 Android-specific partitions (cache, recovery, kpanic, metadata, etc.), complicating the boot process.

 

Modified State: I manually edited parameter.txt to consolidate all user partitions into a simplified Linux layout. I removed the Android clutter and defined a single large system partition for the RootFS.

 

New Layout Definition: mtdparts=rk29xxnand:0x00002000@0x00002000(uboot),0x00004000@0x00004000(trust),0x00007800@0x0000A800(resource),0x00006000@0x00012000(kernel),0x00006000@0x00018000(boot),-@0x00028000(system)

 

Component Preparation (Where the files came from)

I did not use generic loaders for the boot partition. Instead, I extracted and repackaged each component on macOS to fit this new map:

 

• U-Boot (uboot @ 0x2000): I extracted the original bootloader from my device backup using dd to preserve compatibility. Command: dd if=backup_original.img of=uboot_extraido.img skip=8192 count=8192

 

• System/RootFS (system @ 0x28000): I extracted the raw EXT4 Linux partition from the Armbian image. Command: dd if=Armbian...minimal.img of=particao_linux.ext4 skip=8192 count=2269184

 

• Kernel (kernel @ 0x12000): Extracted vmlinuz-6.18.7-rockchip from the Armbian image and wrapped it with Rockchip headers using mkimage. Command: mkimage -A arm -O linux -T kernel -C none -a 0x60408000 -e 0x60408000 -n "Linux" -d vmlinuz... kernel.img

 

• Ramdisk (boot @ 0x18000): Extracted uInitrd from Armbian and wrapped it as a ramdisk image. Command: mkimage -A arm -O linux -T ramdisk ... -d uInitrd... boot.img

 

• Resource/DTB (resource @ 0xA800): I used the specific Device Tree Blob for this box (rk322x-box.dtb) extracted from the Armbian build and renamed it to resource.img. Afterwards, I tested with resource-linux which was linked in the original discussion, but still did not have success.
   

The Flashing Sequence & Current Anomaly With the files prepared and the partition map redefined, I flashed the components using rkdeveloptool.
 

The Sequence:

Initialize: db rk322x_loader_v1.10.238_256.bin

Partition Map: prm parameter.txt (Injecting the simplified layout).

Flash Images:

wl 0x2000 uboot_extraido.img (My extracted U-Boot)

wl 0x4000 trust_with_ta_ga4fd2d1.img

wl 0xA800 resources-linux.img (The DTB)

wl 0x12000 kernel.img

wl 0x18000 boot.img

wl 0x28000 particao_linux.ext4 (The Armbian RootFS)
 

The Result (The "TOS" Anomaly): The write process returns 100% Success, but the device fails to boot. The serial log (1.5Mbps) reveals a loop with a specific error:

 

GPT 0x63337df8 signature is wrong recovery gpt fail! tag:LOADER error,addr:0x2000 hdr 633377e0 + 0x0:0x20534f54,0x20202020...
 

The Anomaly: The error points to address 0x2000. The header read back is 0x20534f54, which is ASCII for "TOS " (Trust OS). It seems the Bootrom or the initial loader is hardcoded to expect the Trust Image at 0x2000, but my parameter.txt (and the standard Rockchip layout) places U-Boot at 0x2000 and Trust at 0x4000. Even when I flash my extracted U-Boot there, the system seems to be looking for a Trust signature.

 

At this point, I don't know what I'm doing anymore and have spent around 20 hours in this project testing things.   

Any guidance on how to proceed from more experienced devs such as @fabiobassa, @Harleyyyu and @jock would be greatly appreciated to save my sleepless nights. Thanks for reading.