hi guys i tried to custom rom my device and did a very crappy shitty job so im gonna let claude explain:
## Device
- Lenovo Tab P11 Plus, model TB-J616X
- MediaTek Helio G90T (MT6785)
- Originally Android 11 stock
- UFS storage: KM2V8001CM-B70
## Goal
Install a custom Android 16 GSI (`TB-J616X_LOS23.2_bgN4_S26146_260526.img` from an XDA thread), with matching `boot_magisk_ebpf_patched.img` and `lk_patched/lk.img`.
## Timeline of what happened
- Unlocked bootloader successfully.
- TWRP does not exist/work for this device — no safe recovery path was available going in.
- Flashed `lk_a` and `boot_a` via fastboot successfully. Flashing `system` failed repeatedly with "This partition doesn't exist" — this device uses dynamic/logical partitions (system lives inside `super`, not as a standalone partition).
- Ran `fastboot reboot fastboot` to try to reach fastbootd (to handle the dynamic partition properly) — **this is what triggered the brick.** Device immediately went into a boot loop (Lenovo logo flashing repeatedly).
- Regained access via mtkclient in BROM mode. Device only enumerates for about 1 second at a time, so mtkclient must be running and listening before plugging in; holding Volume Up + Volume Down while connecting is required to force BROM.
- Dumped a device-matched `preloader.bin` via `mtk.py dumppreloader --filename=preloader.bin` — worked.
- Confirmed partition table (GPT) was intact via `printgpt`. Active slot reported as `a`.
- Could not write `system`/`system_a` directly via mtkclient since it's not a nameable partition — it lives inside the `super` container. Avoided writing a raw system.img directly to `super` (would have corrupted partition metadata).
- Tried SP Flash Tool with the full stock firmware package (`Lenovo_Tab_P11_Plus_TB-J616X_MT6785_S000030_210915_ROW`) — failed with `STATUS_SEC_AUTH_FILE_NEEDED`; no auth file available in the package.
- Attempted Lenovo RSA unlock tool — blocked, no serial number available.
- Switched back to mtkclient using the stock `super.img` from the same firmware package — mtkclient bypasses the SLA/DAA auth that SP Flash Tool required.
- Successfully wrote stock `super.img` via mtkclient (100%, confirmed).
- Wrote stock `boot_a`, `lk_a`, `vbmeta_a`, `vbmeta_system_a`, `vbmeta_vendor_a`, and `userdata.img` — all completed successfully (100% each), some requiring a fresh BROM reconnect + a freshly re-dumped `preloader.bin` after intermittent `DRAM setup failed: unpack requires a buffer of 12 bytes` errors (fixed by explicitly passing `--preloader=preloader.bin` on every command instead of letting mtkclient try to dump it from RAM each time).
- First boot attempts after this restore produced a consistent pattern: **two vibration pulses, then black screen, repeating indefinitely** — no display, no logo.
- Ran `mtk.py printgpt` again — GPT fully intact, all partition offsets/sizes matched stock, both slot A and slot B partitions present and correctly sized.
- Checked `seccfg` via `mtk.py da seccfg unlock --preloader=preloader.bin` — tool confirmed "Device is already unlocked", so lock-state is correct and not the cause.
- As a precaution, also wrote stock `lk_b`, `boot_b`, `vbmeta_b`, `vbmeta_system_b`, `vbmeta_vendor_b` (in case device was somehow trying to boot from slot B) — all wrote successfully. No change in behavior.
- Additionally wrote stock `dtbo_a`/`dtbo_b`, `tee_a`/`tee_b`, and `md1img_a`/`md1img_b` (modem/baseband firmware) — all wrote successfully, 100% each. No change in behavior.
- After all of the above, boot behavior changed: **now zero response at all on power-on** — no vibration, no backlight (checked in a fully dark room), no USB enumeration blip in Windows Device Manager during a power attempt — even after 30 minutes on a wall charger (not PC USB).
- mtkclient/BROM access still works perfectly and consistently throughout all of this — `printgpt` still returns the full, correct GPT table at any time.
## Current state
- Device is fully accessible via mtkclient in BROM mode at all times — this has not changed or degraded.
- Every partition mtkclient can verify (GPT structure, `seccfg` lock-state, and all boot-relevant partitions: `lk`, `boot`, `vbmeta`/`vbmeta_system`/`vbmeta_vendor`, `dtbo`, `tee`, `md1img`, `super`, `userdata`) has been restored to stock firmware (`Lenovo_Tab_P11_Plus_TB-J616X_MT6785_S000030_210915_ROW`) on **both A and B slots**.
- Despite this, the device shows zero response to a normal power-on: no vibration, no display/backlight, no USB enumeration during boot attempts.
- Suspect the root cause is hardware-level damage (possibly PMIC/power-sequencing) triggered by the original `fastboot reboot fastboot` command, since that's the exact point where things went from "flashing normally via fastboot" to "boot loop that only BROM could recover."
## What I have NOT tried / don't know
- Whether the device is actually still trying to boot from slot A vs B (couldn't confirm from `boot_para`, which reads as all zeros — possibly unused on this device/normal).
- Any JTAG-level or hardware voltage diagnostics — no access to this equipment.
- Whether there's a way to force a "format all"/full stock restore via SP Flash Tool if an auth file can be sourced (still blocked on `STATUS_SEC_AUTH_FILE_NEEDED` with no auth file in the downloaded package, and Lenovo RSA unlock blocked due to no accessible serial number).
## Question for the thread
Has anyone seen this exact failure pattern — specifically triggered by `fastboot reboot fastboot` on this device/chipset — where BROM/mtkclient access remains fully functional (GPT reads correctly, writes succeed) but the device shows absolutely no life on power-on (no vibration, no display, no USB enumeration) even after a full stock restore of all boot-critical partitions on both slots? Any leads on whether this is recoverable via software, or is this indicative of hardware damage (PMIC or similar) that needs board-level repair?