Fix boot hang on real CV610 silicon: update GSL (DDR training) blob - #6
Open
snokvist wants to merge 1 commit into
Open
Fix boot hang on real CV610 silicon: update GSL (DDR training) blob#6snokvist wants to merge 1 commit into
snokvist wants to merge 1 commit into
Conversation
The vendored gsl.bin (pre-u-boot stage: DDR training + handoff loader, packed at 0xC00 of the boot image) hangs on real Hi3516CV610 hardware right after printing the DDR boot table. U-boot itself is fine: grafting a working GSL under the unmodified OpenIPC u-boot boots to Linux. Replace it with the newer GSL build from a production CV610 device (ddr param version 20250416; the current blob is older). Same size, same layout, byte-identical 0x90-byte header; drop-in for image_tool. Verified on a K662C6S camera module (Hi3516CV610 + IMX662, 128 MB DDR3, 20s variant): oem_quick_build.py with this blob + stock u-boot + 20s reginfo reproduces, byte-for-byte apart from the reginfo timestamp string, an image that was flashed and boots to Linux userspace. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
snokvist
added a commit
to snokvist/u-boot-hi3516cv6xx
that referenced
this pull request
Jul 30, 2026
Upstream: OpenIPC/u-boot-hi3516cv6xx PR OpenIPC#6 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Member
|
Thanks, the admins will look into it in the morning. |
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
3 participants
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.
Symptom
The published
boot-hi3516cv610-*-nor.binprebuilts hang on real silicon immediately after the DDR boot-table print — noSystem startup, no u-boot banner. This is the failure reported in #4 and #5.Root cause
The fault is confined to
image_tool/input/gsl.bin— the vendored HiSilicon pre-u-boot stage (DDR training + handoff loader) thatoem_quick_build.pypacks at offset 0xC00 of every boot image. Its DDR training code hangs on real chips; it appears to have only ever been exercised by the QEMU smoke gate, which bypasses the DDR stage entirely.Everything else is already correct: the reginfo tables, the image_tool packing, and u-boot itself. Proven by grafting a known-good GSL under the unmodified OpenIPC u-boot from the current prebuilt — the result boots all the way to Linux userspace.
Fix
Replace
gsl.binwith the newer GSL build extracted from the factory flash of a production CV610 device (ddr param version 20250416; the current blob is an older build carrying error paths the newer one no longer has). It is the same kind of vendored HiSilicon blob the tree already ships — same size (19,320 bytes), same layout, byte-identical 0x90-byte header — a drop-in for image_tool.Verification
Hardware-verified specifically on a K662C6S IP-camera module (Hi3516CV610 + IMX662, 128 MB DDR3,
20svariant) — this PR claims that configuration only, not a universal fix for every CV610 board:oem_quick_build.pywith this blob + the u-boot from the current20sprebuilt + the in-tree20sreginfo reproduces, byte-for-byte apart from the reginfo build-timestamp string, an image that was flashed to the module and boots to Linux userspace.Other binnings (
10b/00s/00g) repack cleanly but are untested on hardware. The cv608 failure in #5 is plausibly the same defect, also unverified.Fixes #4. Likely related: #5.
🤖 Generated with Claude Code