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?

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?

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

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

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?

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?

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