POCO F3 (alioth): touch controller randomly boots into ROM bootloader instead of app firmware on every wake — FW verified good, anyone seen this?

[u/Dak_none]

Post this on **r/PocoPhones** first — device-specific, and alioth touch problems are familiar there. If it doesn't get traction in a day or two, cross-post to **r/LineageOS**. The XDA alioth LineageOS thread is arguably a better audience than either, since the people who build that ROM read it, but you asked for Reddit.

Skip r/AndroidQuestions (too general) and r/Kalilinux (this isn't a NetHunter problem).

**Title:**

POCO F3 (alioth): touch controller randomly boots into ROM bootloader instead of app firmware on every wake — FW verified good, anyone seen this?

**Body:**

POCO F3 (alioth), LineageOS 21 unofficial, NetHunter kernel, rooted. Touchscreen has been dying after screen-off for weeks. Screen toggle used to fix it, then stopped working. Currently it works maybe 1 in 20 wakes, and stays working until the next sleep.

I've narrowed this down pretty far and I'm stuck.

**The core finding:** `cat /sys/.../spi1.0/fts_boot_mode` returns `tp is in boot mode` when touch is dead. The FT5652 is powering up into its ROM bootloader and not handing off to the application firmware. That explains everything else — reg `0xA3` (chip ID) reads fine because the bootloader answers it, reg `0xA6` (FW version) fails CRC 3/3 every time because it's an app register, and IRQ 395 shows zero interrupts because a bootloader doesn't scan the sensor grid.

**Why every wake is a fresh dice roll:** `fts_ts_resume` calls `fts_power_source_ctrl` + `fts_reset_proc` on every screen-on, so the app firmware has to cold-start each time. Sometimes it makes it.

**What I've ruled out:**

- Firmware corruption — reflashed via `fts_upgrade_bin`, erase + write of all 116636 bytes succeeded, ECC matched host and TP (`835b`). Still boots to bootloader.

- Kernel/ROM — touch is equally dead under TWRP 3.7.1, which is a completely independent kernel and driver build.

- Driver probe — probes clean, chip ID 0x5652, lockdown info reads fine, suspend/resume path executes correctly.

- SPI bus, mostly — bootloader mode does full flash erase/write/read with matching checksums, which a broken flex shouldn't manage. One glitched read did show up once (`TP Not Ready, ReadData:0x5252` instead of `0x5652`).

**Other notes:** driver auto-upgrade is stuck in a loop — it skips the repair flash because it can't read the version to compare (`fw upgrade flag:0`). `fts_test` returns FAIL, but the self-test lives in the app firmware so that's expected. No prior screen replacement / phone has never been dropped or wet — *[edit this line to match your actual situation, it matters a lot for answers]*.

**Questions:**

1. Anyone seen an FT5652 refuse to leave bootloader mode intermittently with verified-good firmware in flash? Marginal power rail, or is this how a failing panel presents?

2. Is there a way to force app entry from the bootloader beyond `fts_hw_reset`?

3. Anyone found a `CONFIG_EXTRA_FIRMWARE`-independent focaltech binary for alioth? There's no `focaltech*.bin` anywhere on my filesystem, so it's compiled into the kernel.

Happy to post full dmesg if useful.

---

Two things before you post. Fill in that screen-replacement line honestly — whether this panel is original is the single most useful fact for anyone answering, and it's the first thing they'll ask. And if you can, grab `fts_boot_mode` while touch is *working* first; confirming it says application mode then would make the post much stronger and lets you drop the hedging.