web: 65 frame-blast (PRESTEP0) chips are selectable but the web build never sends PRESTEP0

[widgetii]

The browser build's inline PROFILES blob has drifted from the CLI profile data: every chip in it has had PRESTEP0 stripped, including the 65 chips that require a frame-blast handshake. Those chips can still be picked from the dropdown, so the UI silently attempts the wrong handshake.

Evidence

web/index.html carries 109 profiles, none with PRESTEP0:

$ python3 -c "...json.loads(PROFILES)..."
web profiles WITH PRESTEP0 (0):

The CLI data has 66 such profiles, and 65 of them are selectable in the web UI:

66 CLI profiles use PRESTEP0; 65 of them are selectable in the web UI:
  hi3110ev500, hi3231v520, hi3251v500, hi3516a, hi3516av200, hi3516cv300,
  hi3516cv500, hi3516ev200, hi3518ev200, hi3519, hi3519v101, hi3520dv400,
  hi3521a, hi3531a, hi3536, hi3536dv100, hi3559av100, ... (+ ~45 STB parts)

PRESTEP0 is precisely what selects the frame-blast path — hisilicon_standard.py:96:

def uses_frame_blast_handshake(self) -> bool:
    return self._profile is not None and self._profile.prestep_data is not None

With it stripped, the web build's Standard path runs DDR step → SPL → U-Boot and never emits the pre-step frame. (The HEAD/AUX blast at web/index.html:394-402 is the V500 path, not this one.)

web/ is deployed verbatim by pages.yml and the blob is hand-maintained — there's no generator keeping it in sync with src/defib/profiles/data/, which is how the two drifted.

Why it matters

The affected list is not exotic — hi3516cv300, hi3516ev200, hi3518ev200 and hi3516av200 are common camera SoCs, and we are now actively pointing users at the web UI as the recommended way past a locked bootloader (OpenIPC/wiki#484, plus replies on OpenIPC/firmware#1494/#1532/#1674/#1827). Two long-standing reports in the retired burn repo are exactly these parts — OpenIPC/burn#21 (hi3518ev200) and OpenIPC/burn#18 (hi3516ev200).

A user on one of these chips gets a chip in the dropdown, a green "U-Boot downloaded, SHA-256 verified", and then a handshake that cannot succeed — with nothing indicating the tool was never going to work for their part.

Note this is a separate defect from #82. #82 is about frame-blast reliability in manual power-cycle mode when the sequence is being sent; here the sequence is never sent at all.

Not yet confirmed on hardware

This is a read of the data and the code path — I have not put a frame-blast chip in front of the web UI. Worth a hardware check before deciding on the fix, in case the plain handshake happens to be tolerated by some of these parts.

Options

1. Generate PROFILES from src/defib/profiles/data/ at build time, carrying PRESTEP0, and implement the frame-blast path in web/protocol.js. Fixes it properly, and stops the two copies drifting again.
2. Filter the dropdown to non-PRESTEP0 chips and show "this SoC needs the CLI" for the rest. Small, honest, shippable now.
3. At minimum, stop shipping stripped profiles silently — if the blob is going to stay hand-maintained, add a test that fails when a chip exists in both places with different fields.

I'd suggest 2 immediately and 1 as the real fix, given we're driving traffic at this page right now.

[widgetii]

Two corrections to the analysis above, both of which make this worse.

1. The affected set is 66, not 65 — and it includes hi3516ev300.

My original count read each chip's own profile file for a PRESTEP0. That's wrong, because profile lookup follows alias files and an alias contains nothing but a filename:

$ cat src/defib/profiles/data/hi3516ev300.json
hi3516ev200.json

Checking that file for PRESTEP0 finds none because it has no fields at all — which reads as "plain handshake" unless you resolve the alias first, exactly as load_profile() does. Resolving properly:

web dropdown chips: 109
of those, FRAME-BLAST (need PRESTEP0 the web never sends): 66
  -> plain/OK: 43

Camera-relevant affected parts: hi3516a, hi3516av200, hi3516cv300, hi3516cv500, hi3516ev200, hi3516ev300, hi3518ev200.

hi3516ev300 matters most — it's one of the most widely deployed SoCs we support, and I had recommended the browser tool for it on both firmware#1674 and firmware#1827. Both replies are now corrected, and OpenIPC/wiki#484 has been updated (it was using hi3516ev300 as its worked example).

2. It's not only the missing PRESTEP0 — the handshake itself differs.

I said the sequence was incomplete. It's actually wrong in two independent places. For frame-blast parts the CLI:

1. runs _send_frame_for_start() — an active 0xAA + HEAD(64, ddr_step_address) blast, retried for 30 s until ACK, and
2. then sends PRESTEP0 as HEAD+DATA+TAIL before DDRSTEP0.

standardHandshake() in the web build waits passively for five consecutive 0x20 bytes, and standardSendFirmware() goes straight to DDR → SPL → U-Boot. So neither the handshake nor the init sequence matches what these chips expect.

The CLI profile confirms both blocks are real and distinct:

name: hi3516ev200
PRESTEP0: <64 bytes>
DDRSTEP0: <64 bytes>
ADDRESS: ['0x04013000', '0x04010500', '0x41000000']

The web entry is that same profile with PRESTEP0 deleted — same addresses, same FILELEN/STEPLEN.

#122 implements option 2 (block them clearly) plus option 3 (a parity test that resolves aliases and fails on drift). Leaving this open for the real fix.