hi3518ev200 (PRESTEP0 frame-blast chip) not recoverable in manual power-cycle mode

[widgetii]

Summary

defib burn -c hi3518ev200 -p /dev/ttyUSBN -b cannot complete on real hardware when there is no programmatic power control (e.g. Wi-Fi-only cameras with no PoE). The chip's bootrom emission pattern doesn't reliably produce 5 consecutive 0x20 markers in defib's RX buffer the way other HiSi chips do, and the existing detection heuristic either misses the bootrom window or false-positives on U-Boot text padding.

Tested 2026-05-11 on a real hi3518ev200 board over /dev/ttyUSB2 (Prolific PL2303 USB-UART). Multiple attempts with different handshake strategies all failed.

Symptoms

• defib burn -c hi3518ev200 ... -b with the camera at U-Boot prompt: defib's --break flood is echoed back by U-Boot's character handler as a stream of 0x08 (backspace) bytes — confirmed via --debug: in one 60-second run, defib's RX buffer contained 31,746 × 0x08, 325 × 0x30, 194 × 0xAA, and ~60 × 0x20 markers scattered as singletons (not in any consecutive run ≥ 16).
• Existing 5-consecutive threshold either:
  • False-negative: misses the brief bootrom phase if defib's read loop misses the burst, or the burst arrives interleaved with 0xAA echoes.
  • False-positive: catches 5 consecutive ASCII spaces in U-Boot text like MMC/SDCard:\r\n MID: (5 spaces for column alignment). The chip is at U-Boot, not bootrom. The subsequent PRESTEP0 frame-blast gets a fake ACK on a random 0xAA in U-Boot's response, then the actual PRESTEP0 HEAD frame fails with 0x08 (backspace) responses.

What works for sibling chips today

• hi3516av200 (also PRESTEP0 frame-blast): with programmatic PoE control (RouterOS auto-cycle), full burn completes in ~27 s, U-Boot banner captured via PR cli: preserve U-Boot banner across --break -t so -t shows it #80's post_burn_buffer. Verified earlier today during the fleet survey.
• Same code path on hi3518ev200 should work in principle, but the chip's bootrom emission pattern appears different.

What was tried (all reverted, no PR landed)

1. Active probing — periodically write \r\n and watch for echo; flood only after several empty probes confirm chip is dead. Failed: U-Boot's idle prompt is also silent ⇒ false trigger ⇒ echo poisoning.
2. Continuous flood from t=0 for frame-blast chips — assumes operator started defib with chip off. Worked for hi3516av200; hi3518ev200 still misses the bootrom window (or never produces 16-consecutive 0x20s).
3. Raise BOOTMODE_COUNT from 5 to 16 — well below the documented 25-byte bootrom burst, well above U-Boot text padding. Didn't help hi3518ev200; the chip never produced 16 consecutive 0x20s in any observed run.

Root cause hypotheses (not yet verified)

1. hi3518ev200's bootrom emits a different marker pattern than the documented 25-byte burst seen on hi3516cv300. Maybe it emits short bursts (5-10) interleaved with CRLFs, or the bursts are spread across multiple kernel-buffer reads.
2. PL2303 USB-UART crosstalk / partial loopback — observed 194 × 0xAA reads in a run where defib was flooding 0xAA. Could be true loopback or just real chip echoes; can't distinguish without a scope.
3. Camera enters a boot loop when no kernel is flashed — chip cycles rapidly between bootrom, brief U-Boot, reset, repeat. defib's read cadence can't align with the brief bootrom phase of each cycle.

What would unblock a real fix

A logic-analyzer or cat /dev/ttyUSBx capture of hi3518ev200's UART during a clean power-up (from cold) up through autoboot. Specifically:

# Camera off. Power-cycle the USB-UART so the buffer is clean.
stty -F /dev/ttyUSB2 115200 raw -echo
timeout 10 cat /dev/ttyUSB2 > hi3518ev200-cold-boot.bin
# Power on the camera within those 10 seconds.
xxd hi3518ev200-cold-boot.bin | head -50

The first ~few thousand bytes would show the bootrom's actual emission pattern and any U-Boot transition. That tells us what BOOTMODE_COUNT should be for this chip family, or whether a different signal entirely is needed.

Workaround for affected users today

Use a board with programmatic PoE control if at all possible — defib's --power-cycle --poe-port etherN path is hardware-validated and reliable. For Wi-Fi-only PRESTEP0 chips, defib currently has no working manual-mode recovery.

Notes

Reverted from the session 2026-05-11: all attempted fixes were rolled back without landing because none of them actually fix this chip, and threshold-tuning risks regressions on chips that work today (hi3516av200/av300/ev300, gk7205v300, cv300 all verified during today's fleet survey). Filed instead of a misleading "fix" PR.

Logs and byte-frequency breakdowns preserved in kaeru (hi3518ev200-manual-mode-debug-2026-05-11).