Jump to content

ArturHey

Members
  • Posts

    7
  • Joined

  • Last visited

Posts posted by ArturHey

  1. 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?

      

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

     

  3. [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 @fabiobassamanually 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. 

  4. 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?

  5. 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? 

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

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines