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. 

[Harleyyyu]

@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.

[jock]

@ArturHey you did a lot of experimentation, but actually I think you are stuck on something different. GPT partition error message is something you can totally ignore, either because stock firmware usually don't provide a GPT partition, and armbian images neither do.

 

The rockchip miniloader supports GPT partition table, but it is not mandatory to work. If there's a GPT partition, the miniloader searches for "uboot" and "trust" partitions to use them as hints for the base addresses. If there's no GPT partition, it will just use default base addresses and look for the LOADER and TRUST signatures.

 

Anyway, armbian does not use anything from that: there is no rockchip miniloader, neither are GPT partitions or other proprietary code, except for the Trust OS, which is embedded into u-boot. The boot process is totally different on armbian.

 

Now, the issue you have with flash not being recognized by rkdeveloptool makes me think about three possibile situations:

• a bug in rkdeveloptool
• you are still in maskrom mode and did not upload the usbplug firmware with rkdeveloptool db (ie: the board is not yet initialized)
• a broken flash in the eMCP part

 

You can, for example, refer to the procedure Installation (without SD card, board with eMMC) described in the first post of this thread if you want to write a raw image in the flash memory but I always suggest to erase the flash memory and test the image via sdcard first, rather than installing the image immediately, because you can softbrick the board.

 

About the non-booting multitool, you should post some logs from the serial uart, but probably the main issue is related to the trust os which freezes the board after few seconds.

[ArturHey]

@Harleyyyu, I tried swapping uboot and trust offsets as you suggested. I performed a full erase, injected the parameter, and flashed them at 0x2000 (Trust) and 0x4000 (U-Boot).

 

Here is the log of the process:

./rkdeveloptool ld

DevNo=1 Vid=0x2207,Pid=0x320b,LocationID=101 Maskrom


./rkdeveloptool db rk322x_loader_v1.10.238_256.bin

Downloading bootloader succeeded.


./rkdeveloptool ef

Erasing flash complete.


./rkdeveloptool rfi

Flash Info:

Manufacturer: SAMSUNG, value=00
Flash Size: 7216 MB
Flash Size: 14778368 Sectors
Block Size: 512 KB
Page Size: 2 KB
ECC Bits: 0
Access Time: 40
Flash CS: Flash<0>


./rkdeveloptool ul rk322x_loader_v1.10.238_256.bin

Upgrading loader succeeded.


./rkdeveloptool prm parameter.txt

Writing parameter succeeded.


./rkdeveloptool ppt

**********Partition Info(parameter)**********

NO  LBA       Name
00  00002000  uboot
01  00004000  trust
02  0000A800  resource
03  00012000  kernel
04  00018000  boot
05  00028000  system


./rkdeveloptool wl 0x2000 BBtrust_with_ta_ga4fd2d1.img

Write LBA from file (100%)


./rkdeveloptool wl 0x4000 AAuboot_extraido.img

Write LBA from file (100%)


./rkdeveloptool wl 0xA800 CCresources-linux.img

Write LBA from file (100%)


./rkdeveloptool wl 0x12000 DDkernel.img

Write LBA from file (100%)


./rkdeveloptool wl 0x18000 EEboot.img

Write LBA from file (100%)


./rkdeveloptool wl 0x28000 FFparticao_linux.ext4

Write LBA from file (100%)


./rkdeveloptool rd

Reset Device OK.

 

Resulting Boot Log (Swapped Offsets):

Still fails with the signature error. Interestingly, at addr:0x2000, the header now reads 0x4d524150 (ASCII for "PARM"), meaning the Bootrom is seeing the parameter/GPT signature where it expected a loader component.

 

DDR Version V1.10 20190926

In

ID:0xFFF

300MHz

LPDDR3

Bus Width=32 Col=11 Bank=8 Row=14 CS=1 Die Bus-Width=32 Size=1024MB

mach:4

OUT

Boot1 Release Time: May 13 2019 17:02:59, version: 2.56

ChipType = 0xc, 421

mmc2:cmd19,100

SdmmcInit=2 0

BootCapSize=2000

UserCapSize=7216MB

FwPartOffset=2000 , 2000

SdmmcInit=0 NOT PRESENT

StorageInit ok = 163350

SecureMode = 0

SecureInit ret = 0, SecureMode = 0

atags_set_bootdev: ret:(0)

GPT 0x63337df8 signature is wrong

recovery gpt...

GPT 0x63337df8 signature is wrong

recovery gpt fail!

tag:LOADER error,addr:0x2000

hdr 633377e0 + 0x0:0x4d524150,0x000002f8,0x4d524946,0x45524157,

tag:LOADER error,addr:0x4000

hdr 633377e0 + 0x0:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,57,

tag:LOADER error,addr:0x4800

hdr 633377e0 + 0x0:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00x00000000,0x00000000,0x00000000,0x00000000,

tag:LOADER error,addr:0x6000

hdr 633377e0 + 0x0:0x00,0x00,0x00,0x00,0x00,ag:LOADER error,addr:0x5800

hdr 633377e0 + 0x0:0x00000000,0x00000000,0x00000000,0x00000000,

tag:LOADER error,addr:0x780000000,0x00000000,0x00000000,0x00000000,

tag:TOS    error,addr:0x6800

hdr 633377e0 + 0x0:0x00,0x00,0x00,0x00,0x00,0x0TOS    error,addr:0x6000

hdr 633377e0 + 0x0:0x00000000,0x00000000,0x00000000,0x00000000,

tag:TOS    error,addr:0x8000

0000,0x00000000,0x00000000,0x00000000,

tag:TOS    error,addr:0x9000

hdr 633377e0 + 0x0:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,



UsbHook ...251116

powerOn 772192

 

 

@jock, the flash chip is definitely healthy as it was working perfectly with the stock Android firmware yesterday. I am following the guides strictly and initializing with the db command every time.

 

To give you a clear reference, here is what happens when I follow your "Installation without SD card" (flashing the raw image to eMMC) after a full ef (erase flash):

 

./rkdeveloptool ld

DevNo=1 Vid=0x2207,Pid=0x320b,LocationID=101 Maskrom


./rkdeveloptool rd 3

Reset Device failed!


./rkdeveloptool db rk322x_loader_v1.10.238_256.bin

Downloading bootloader succeeded.


./rkdeveloptool ef

Erasing flash complete.


./rkdeveloptool wl 0x0 Armbian_community_26.2.0-trunk.357_Rk322x-box_forky_current_6.18.7_minimal.img

Write LBA from file (100%)

 

Result: Absolute silence. No LED, no UART output.

 

Finally, if I try to boot Multitool from the SD Card after zeroing the internal flash, I get the specific Trust OS freeze I mentioned before. The serial output confirms that TEE-CORE starts but hangs right after:

Internal flash zeroing process:
 

./rkdeveloptool ld

DevNo=1 Vid=0x2207,Pid=0x320b,LocationID=101 Maskrom


./rkdeveloptool db rk322x_loader_v1.10.238_256.bin

Downloading bootloader succeeded.


./rkdeveloptool ppt

Not found any partition table!


./rkdeveloptool ppt

Not found any partition table!


./rkdeveloptool ef

Erasing flash complete.

 

Result:

□□DDR Version V1.11 20200910_dbg
In
ID:0xFFF
300MHz
LPDDR3
Bus Width=32 Col=11 Bank=8 Row=14 CS=1 Die Bus-Width=32 Size=1024MB
mach:4
OUT
Boot1 Release Time: May 13 2019 17:02:59, version: 2.56
ChipType = 0xc, 423
mmc2:cmd19,100
SdmmcInit=2 0
BootCapSize=2000
UserCapSize=7216MB
FwPartOffset=2000 , 2000
mmc0:cmd5,20
SdmmcInit=0 0
BootCapSize=0
UserCapSize=7604MB
FwPartOffset=2000 , 0
StorageInit ok = 179763
SecureMode = 0
SecureInit ret = 0, SecureMode = 0
atags_set_bootdev: ret:(0)
GPT 0x63337df8 signature is wrong
recovery gpt...
GPT 0x63337df8 signature is wrong
recovery gpt fail!
LOADER Check OK! 0x61000000, 290821
TOS    Check OK! 0x68400000, 359530
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


[2accGZ3G��غ��ؾeػؼ

 

The device is identified as SAMSUNG by the loader, but it's physically a Kingston eMCP (O8EMCP08). Could this manufacturer ID mismatch be causing the Trust OS to misconfigure the RAM timings and freeze? Is there a patched loader or a specific trust.img for these Kingston eMCP variants?

 

[jock]

 

52 minutes ago, ArturHey said:

Result: Absolute silence. No LED, no UART output.

Perhaps you need to set the UART baud rate to 115200bps. Original stock firmware and binaries uses 1.5Mbps, armbian bootloader is set to 115200bps for broader compatibility.

You should at least get the ddr initialization messages, there are no chances you get no uart output with armbian unless the image is invalid itself.

[ArturHey]

Hi, @jock, thanks for the suggestion. I changed the baud rate to 115200bps and indeed it is sending things. This is what I got:

 

DDR Version V1.11 20200910_dbg

In

ID:0xFFF

333MHz

LPDDR3

Bus Width=32 Col=11 Bank=8 Row=14 CS=1 Die Bus-Width=32 Size=1024MB

mach:4

OUT

 

U-Boot SPL 2025.10-rc5_armbian-2025.10-rc5-S2f2a-P4b2d-Hcd62-Vd309-B2eb2-R448a (Jan 28 2026 - 04:12:44 +0000)

Trying to boot from MMC2

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

 

[2accGZ3G��غ��ؾeػؼ

Since the SPL is alive, it proves the internal flash is readable. Does this specific freeze point suggest a DTB issue or something related to the op-tee/trust partition? Should I try a different v_sel (voltage selector) or a specific u-boot branch for this board?

  

Edited 12 hours ago by ArturHey
add info

[jock]

Just now, ArturHey said:

Any suggestions?

The issues are definitely related to the Trust OS, as you already noticed in your experiments.

You need a build with a different bootloader that contains a different Trust OS or the Opensource TEE, which has no issues so far. An old rk322x_tee.bin file can be found in this old commit, if you want to build an armbian image/bootloader by yourself: substitute it with the existing rk322x_tee.bin and try building an image.

[ArturHey]

@jock THAT WORKED!!! 

I have no idea why, or how, but that worked. Thanks for all the help. Do you think I'll have any problems in the future when updating the OS? 

Edited 9 hours ago by ArturHey

[jock]

8 hours ago, ArturHey said:

I have no idea why, or how, but that worked. Thanks for all the help. Do you think I'll have any problems in the future when updating the OS? 

Me neither have any clue about. Surely the problem lays in the closed source proprietary binary Trust OS. It does or expects something and then locks the system with that typical string [2accGZ3... which is probably known only to rockchip engineers.

Unfortunately I don't have any board here that exhibit the same behaviour, so the issue is hard to study.

 

To avoid issues with updates, you may want to put the u-boot package on hold using apt-mark hold, so in case of updates, the bootloader won't get updated and you'll be fine.