firmware: resolve CV6xx boot images by their real asset names - #117
Merged
Conversation
hi3516cv608 and hi3516cv610 were registered in AVAILABLE_FIRMWARE, which
made firmware_url() build a u-boot-{chip}-universal.bin URL. No such
asset has ever existed for any CV6xx SoC, so every auto-download 404'd.
#112 added them anyway to get past the install gate at cli/app.py:2297,
noting that "the main OpenIPC/firmware releases manifest doesn't carry
it yet" and telling users to hand-seed the cache instead. That caveat is
now stale: the release does publish these images, as
boot-{chip}[-{variant}]-nor.bin — the composite GSL + DDR tables +
U-Boot blob the CV6xx bootrom expects, which is the same content #112
had users seed by hand.
Resolution now goes through asset_name(), which picks the naming scheme
per SoC family. Verified against the live release: every chip the module
claims to support resolves to an asset that returns HTTP 200, and the
downloaded hi3516cv608 image matches the release SHA-256 and parses
cleanly via parse_cv6xx_boot (gsl=22528B, uboot=204800B).
CV6xx variants are board-specific and cannot be guessed. Across the five
hi3516cv610 images the GSL is identical, but each ships a different
U-Boot and the DDR table differs by the numeric prefix (00g/00s share
one, 10b another, 20g/20s a third). Nothing in the recovery handshake
identifies the board, so flashing a guessed variant risks the wrong DDR
config. Chips with multiple images therefore require an explicit
"chip:variant" and otherwise fail early with a message listing the
options, rather than mid-flow on a 404.
Hand-seeded caches from #112 keep working: get_cached_path() still reads
the historic u-boot-{chip}-universal.bin name, and has_firmware() now
also returns True when only a cached blob exists, so the install gate
still opens for chips with no published build.
Also adds hi3520dv200, hi3536cv100 and hi3536dv100, which ship
u-boot-*-universal.bin assets the set had never listed.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to a latent bug spotted while working on #113.
The bug
hi3516cv608andhi3516cv610were listed inAVAILABLE_FIRMWARE, sofirmware_url()built:No
u-boot-*-universal.binhas ever existed for any CV6xx SoC (cv608, cv610, cv613, dv500, dv500), sodefibauto-download for those chips always failed.This wasn't an oversight — #112 added them deliberately to get past the install gate at
cli/app.py:2297, noting "the main OpenIPC/firmware releases manifest doesn't carry it yet" and instructing users to hand-seed~/.cache/defib/firmware/. That caveat is now stale. The release does publish these images, under a different naming scheme:These are the composite GSL + DDR tables + U-Boot blobs the CV6xx bootrom expects — i.e. the same content #112 had users seed by hand, just fetchable now.
The fix
Resolution goes through a new
asset_name()that selects the naming scheme per SoC family. Verified against the live release — every chip the module claims to support now resolves to an asset returning HTTP 200:has_firmwarehi3516cv608boot-hi3516cv608-nor.bin(200)hi3516cv610hi3516cv610:00gboot-hi3516cv610-00g-nor.bin(200)hi3519dv500:dmebproboot-hi3519dv500-dmebpro-nor.bin(200)hi3516cv613,hi3516dv500hi3516ev300,hi3516ev300:emmcu-boot-hi3516ev300-universal.bin(200) — unchangedThe downloaded
hi3516cv608image matches the release SHA-256 (12c697d1…) and parses cleanly throughparse_cv6xx_boot(gsl=22528B uboot=204800B tables=1).Why variants must be explicit
I compared all five cv610 images. The GSL is byte-identical, but each ships a different U-Boot, and the DDR table differs by the numeric prefix —
00g/00sshare one,10banother,20g/20sa third. Nothing in the CV6xx handshake identifies the board, so a guessed variant risks flashing the wrong DDR configuration. Chips with multiple images now requirechip:variant(reusing defib's existing suffix convention) and otherwise fail early with:Previously this passed the gate and then died mid-flow on a 404.
No regression for #112 users
get_cached_path()still reads the historicu-boot-{chip}-universal.binname, andhas_firmware()now also returns True when only a cached blob exists — so hand-seeded caches keep opening the install gate even for chips with no published build. Covered by tests, including one run with an adversarially seeded cache.Also
Adds
hi3520dv200,hi3536cv100,hi3536dv100— they shipu-boot-*-universal.binassets the set never listed (same staleness fixed web-side in #115).Test plan
ruff checkandmypycleanhi3516cv608🤖 Generated with Claude Code