TWRP Build Issue - Realme C53 (RMX3760) Unisoc UMS9230 - Bootloop - ANDROID 15
TWRP Build Issue - Realme C53 (RMX3760) Unisoc UMS9230 - Bootloop - ANDROID 15
27-07-2026, 02:50 PM
Hello everyone!
I am currently working on building TWRP for Realme C53 (RMX3760) running Android 14/15 (Unisoc UMS9230) with Boot Header v4 (Virtual A/B).
My active slot is Slot B, so I generated the device tree using twrpgen based on the dumped vendor_boot_b.img, and synced it with boot_b.img (Kernel) and init_boot_b.img.
Bootloader & Security Status:
Bootloader Status: Unlocked.
DM-Verity / AVB: Tested both with AVB enabled and disabled (vbmeta patched/disabled), but the behavior remains identical.
The Problem:
Whenever I flash the compiled vendor_boot.img (via Fastboot or SPD_Dump) and attempt to boot into recovery:
It either gets stuck on the boot logo ("Powered by Android") / charger animation.
Or it ignores the TWRP ramdisk completely and boots into the Stock Recovery ("No Command" lying Android image).
Flashing Method Used:
fastboot flash vendor_boot_b vendor_boot.img
# Also tested writing directly via spd_dump FDL2:
# write_part vendor_boot_b vendor_boot.img
Relevant Technical Details & Resources:
Chipset: Unisoc UMS9230
Kernel: Prebuilt extracted from boot_b.img (Image)
DTB: Extracted from vendor_boot_b.img
Device Tree Repository & GitHub Workflows: https://github.com/arriRgb31/RMX3760
Stock Firmware Dump Source (GitLab): https://gitlab.com/rmx3760/RMX3760-Android15-Firmware
It seems like the bootloader is either failing to unpack the TWRP recovery ramdisk from the Header v4 vendor_boot structure or falling back to stock.
Any guidance on how to properly set up BoardConfig.mk for Unisoc Header v4 vendor_boot recovery ramdisk injection would be greatly appreciated!
Thank you in advance!
03-08-2026, 04:36 PM
(27-07-2026, 02:50 PM)arxC Hello everyone!
...
Thank you in advance!
Could be AVB still at play.
Have you tried our tool @ https://www.hovatek.com/twrpbuilder/ to confirm you encounter the same behaviour?
Learn MediaTek, Unisoc / Spreadtrum (SPD) and Qualcomm Software Repairs @ https://www.hovatek.com/training
Note!
We have a reply schedule for Forum Support. Please try Private Support if you can't wait.
09-08-2026, 01:23 PM
Device tree attempt (paused)
I built a device tree manually and hit repeated failures — mostly bootloops, and a few times a stuck "Powered by Android" screen where adb devices still showed recovery and I could get an adb shell, but no TWRP UI. The most consistent issue I could isolate was an android.hardware.boot@1.1.so symbol mismatch — versions 1.0 and 1.2 unpacked clean, but 1.1 kept causing linker errors. I couldn't pin down the exact source/commit before I had to pause this approach out of time.
Trying the web builder
After posting here out of frustration, one reply suggested AVB could be at play. I tested that theory with your tool at hovatek.com/twrpbuilder/ (boot.img + vendor_boot.img mode, Android 15, touch driver omnivision_tcm-modules.ko, 720x1600, full BoardConfig values attached below from my own stock dump analysis).
Unpacking the output with magiskboot showed no VBMETA line at all — the AVB footer is completely absent, while my stock vendor_boot has one (magiskboot flags it with an ASN.1 parse warning, but the footer is there). I don't think this is a bug in your tool specifically — any unpack/repack process (magiskboot, mkbootimg, etc.) won't regenerate an AVB footer unless there's an explicit signing step, so this is expected behavior, not a complaint.
What I tried to fix it (all failed):
Appended the raw stock AVB footer to the built image (misaligned, magiskboot couldn't parse it after — unknown/unsupported ASN.1 DER tag)
Recalculated a byte-precise AVB footer (correct offset/size per the AVB spec) using the stock vbmeta hash blob — magiskboot parsed it cleanly this time (same ASN.1 warning as stock, no corruption), but the hash still belongs to the stock ramdisk, not the TWRP one
Tried magiskboot sign (AOSP test key) — this failed outright with a malformed ASN.1 DER value for PrintableString error and produced no output; likely not compatible with vendor_boot header v4 (ramdisk table structure)
Manually patched the vbmeta FLAGS field (offset 0x30) from 0x00000000 to 0x00000003 (hashtree + verification disabled) and flashed via FDL2 — still resulted in a bootloop, even with vendor_boot untouched (still stock)
That last result is the one I can't explain. I confirmed via hex dump that my stock vbmeta_b has FLAGS=0x00000000, RSA4096 signing, and an explicit vendor_boot hash descriptor. So verification is clearly strict by default. But patching the flags directly still bootlooped, which makes me think the bootloader might be validating the vbmeta signature itself before it even reads the flags field — meaning the moment I touch any byte in vbmeta, its signature no longer matches and it's rejected outright, regardless of what the flags say.
I also tested via fastboot boot extensively before realizing that even a 100% stock, untouched vendor_boot_b.img doesn't survive fastboot boot on this device — it just falls back to system. So fastboot boot isn't a reliable test method here; only permanent fastboot flash (or FDL2 write) gives conclusive results, which obviously carries more risk per attempt.
Questions:
Is there anything in my BoardConfig values (attached) that looks off for this chipset/partition layout? I've cross-checked most of it against lpdump/stock dumps but wanted a second opinion.
For the web builder — should I only be uploading vendor_boot.img, or is providing boot.img alongside it actually required/used for anything beyond reading cmdline/kernel reference? I've been uploading both from slot B since that's my active slot.
If this really is AVB (specifically a strict OEM-signed vbmeta chain that also validates its own signature before reading flags), is there a known approach for Unisoc/Realme devices in this situation without OEM signing keys? Or is this possibly a Unisoc-specific secure boot layer (e.g. seccfg-style) sitting outside standard AVB that I should be looking at instead?
Attaching my BoardConfig values for reference
https://gist.github.com/arriRgb31/27166b...3c3e1b5d3a
11-08-2026, 11:50 AM
(09-08-2026, 01:23 PM)arxC ...
After posting here out of frustration, one reply suggested AVB could be at play. I tested that theory with your tool at hovatek.com/twrpbuilder/ (boot.img + vendor_boot.img mode, Android 15, touch driver omnivision_tcm-modules.ko, 720x1600, full BoardConfig values attached below from my own stock dump analysis).
Unpacking the output with magiskboot showed no VBMETA line at all — the AVB footer is completely absent, while my stock vendor_boot has one (magiskboot flags it with an ASN.1 parse warning, but the footer is there)....
Yes, we don't bother signing images as we don't have their private keys (except the default one, which isn't used by all devices).
It's possible to maintain the original image's AVB signature in our TWRP/OFRP build (we've tested this) but we've not yet implemented this.
Share your Work ID from our tool and a link to the stock vendor_boot.img. We'll send you a modified TWRP to test; this should at least give you a frame of reference.
Learn MediaTek, Unisoc / Spreadtrum (SPD) and Qualcomm Software Repairs @ https://www.hovatek.com/training
Note!
We have a reply schedule for Forum Support. Please try Private Support if you can't wait.
03-09-2026, 07:52 PM
Users browsing this thread:
1 Guest(s)
1 Guest(s)
Users browsing this thread:
1 Guest(s)
1 Guest(s)
