Commit a39e0e2
authored
install: fix two CV6xx bugs blocking OpenIPC flash on hi3516cv608 (#112)
## Summary
Two bugs that together stopped `defib install -c hi3516cv608 -p
rfc2217://… --power-cycle` from running on a Vectis-bridged CV6xx
camera. Both were verified end-to-end by flashing OpenIPC's
`openipc.hi3516cv6xx-nor-lite.tgz` onto a live hi3516cv608 — install now
reaches `Welcome to OpenIPC` / `openipc-hi3516cv6xx login:`.
### 1. `firmware.py`: register `hi3516cv608` / `hi3516cv610` as
available
`has_firmware(chip)` returned `False` because neither chip was in
`AVAILABLE_FIRMWARE`. The pre-install gate at `cli/app.py:2297` then
bails with `No OpenIPC U-Boot for 'hi3516cv608'` *before opening the
transport*. Add both chips to the set; users seed the U-Boot blob in
`~/.cache/defib/firmware/u-boot-{chip}-universal.bin` (the dimerr /
`OpenIPC/u-boot-hi3516cv6xx` fork ships it as
`boot-hi3516cv608-nor.bin`; the main `OpenIPC/firmware` releases
manifest doesn't carry it yet).
### 2. `cli/app.py`: attach `Rfc2217Transport` to `VectisController` on
install
The install path's Vectis attach check only matched `SocketTransport`:
```python
if isinstance(power_controller, VectisController) and isinstance(
transport, SocketTransport
):
power_controller.attach_transport(transport)
```
But Vectis exposes itself as `rfc2217://…` (binary-safe path that `defib
burn` already uses), so on install the controller never received the
live transport — it fell back to the standalone path which opens a
**second** TCP connection. Vectis only allows one client at a time, so
the new connection evicted the recovery session's, killing its reader
thread mid-flow with:
```
SerialException: connection failed (reader thread died)
```
Burn already does the right thing (`cli/app.py:196`: matches
`(Rfc2217Transport, SocketTransport)`). Install now mirrors that, with a
comment explaining the one-client constraint.
## Test plan
- [x] `uv run pytest tests/test_recovery_session.py
tests/test_handshake_resilience.py tests/test_agent_protocol.py -x -v` —
60/60 pass
- [x] `uv run ruff check src/defib/cli/app.py src/defib/firmware.py`
clean
- [x] `uv run mypy src/defib/cli/app.py src/defib/firmware.py
--ignore-missing-imports` clean
- [x] End-to-end live install on hi3516cv608 over Vectis
(`rfc2217://127.0.0.1:35240`):
- CV6xx fastboot → OpenIPC U-Boot in RAM (27 s)
- TFTP transfers + `sf write` for U-Boot @ 0x000000, kernel @ 0x050000,
rootfs @ 0x350000 — all flash-CRC verified
- Camera reboots and reaches `Linux 5.10.221 … #1 SMP Thu Jun 4 00:17:45
UTC 2026` / `Welcome to OpenIPC` / `openipc-hi3516cv6xx login:`
## Out of scope (filed upstream)
`defib install`'s `setenv bootcmd ${bootcmdnor}` works for
cv500/ev-class but on dimerr's CV6xx U-Boot `bootcmdnor` is undefined,
leaving `bootcmd` empty. Also the default `osmem=32M` is too tight for
OpenIPC's CV6xx kernel (silent hang). Both are U-Boot-side env defaults
— filed against the upstream U-Boot port at
OpenIPC/u-boot-hi3516cv6xx#1. Doesn't block this PR; users currently
need to set `bootcmd` / `bootargs` by hand after install on CV6xx.
Co-authored-by: Dmitry Ilyin <widgetii@users.noreply.github.com>1 parent 7e0f31f commit a39e0e2
2 files changed
Lines changed: 8 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
2381 | 2381 | | |
2382 | 2382 | | |
2383 | 2383 | | |
2384 | | - | |
| 2384 | + | |
| 2385 | + | |
| 2386 | + | |
| 2387 | + | |
| 2388 | + | |
2385 | 2389 | | |
2386 | 2390 | | |
| 2391 | + | |
2387 | 2392 | | |
2388 | 2393 | | |
2389 | | - | |
| 2394 | + | |
2390 | 2395 | | |
2391 | 2396 | | |
2392 | 2397 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
26 | 26 | | |
27 | 27 | | |
28 | 28 | | |
| 29 | + | |
29 | 30 | | |
30 | 31 | | |
31 | 32 | | |
| |||
0 commit comments