hisilicon: boot the GSL-signed Hi3519DV500 u-boot from a full NOR image - #127
Merged
Conversation
PR #126 booted the raw self-extracting u-boot-z placed at flash offset 0, but the *published* dv500 NOR images (openipc-hi3519dv500-{dmeb,dmebpro}-nor-ultimate.bin) put the GSL-signed boot image first: a GSL/DDR header at offset 0 with the u-boot-z payload embedded deeper (~0x11200). The aarch64 flash-boot path blindly loaded the file from offset 0 to the DDR link address and started CPU0 there, so it executed the non-executable GSL header and hung right after the FMC load. Locate the u-boot-z block before loading: both the raw image (offset 0) and the GSL image open the payload with an aarch64 reset branch (b, opcode 0x14......) immediately followed by a run of 0xdeadbeef self-descriptor markers. Scan the first 256 KiB for that signature and load from there. Verified booting the published GSL-signed images end-to-end (U-Boot 2022.07 -> kernel -> squashfs -> "Welcome to OpenIPC" -> login), both binnings, deterministic across runs, zero Oops. Completes the dv500 NOR boot started in #126 so QEMU runs the actual released image, not just a raw u-boot. 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 #126. That PR booted the raw self-extracting
u-boot-zplaced at flash offset 0, but the published dv500 NOR images (openipc-hi3519dv500-{dmeb,dmebpro}-nor-ultimate.bin, from OpenIPC/firmware#2211) put the GSL-signed boot image first: a GSL/DDR header at offset 0 with theu-boot-zpayload embedded deeper (~0x11200).The aarch64 flash-boot path loaded the file from offset 0 to the DDR link address and started CPU0 there, so it executed the non-executable GSL header and hung right after the FMC load (no U-Boot banner).
Fix
Locate the
u-boot-zblock before loading. Both layouts open the payload with an aarch64 reset branch (b, opcode0x14......) immediately followed by a run of0xdeadbeefself-descriptor markers — raw image at offset 0, GSL image at ~0x11200. Scan the first 256 KiB for that signature androm_add_blob_fixedfrom there.Verification
Booting the actual published GSL-signed images (
-M hi3519dv500,flash-file=openipc-hi3519dv500-<binning>-nor-ultimate.bin), both binnings, 2/2 runs each:Zero Oops/panics, deterministic. With this, QEMU boots the released dv500 image verbatim — not just a raw u-boot — closing the loop on OpenIPC/firmware#2208.
🤖 Generated with Claude Code