ci: publish a DDR3 u-boot for hi3518ev200 boards that have DDR3 - #9
Conversation
hi3518ev200's register table programs the memory controller for DDR2: DMC_CFG_DDRMODE (0x20111050) is 0x15, and DMC_CFG_DRAM_TYPE_MASK in drivers/ddr/ddr_ddrc_v500.h reads [2:0] as 101=DDR2, 110=DDR3, 111=DDR4. Boards of this SoC built with DDR3 therefore have no working memory: the SPL runs from SRAM, programs the controller for the wrong device, and dies the moment it touches DRAM. From the outside the camera looks bricked -- flashing succeeds, nothing boots, and a UART recovery upload ACKs every chunk and then goes silent on the jump. OpenIPC/firmware#2299 is one such board. Its Nanya NT5CC128M16IP-DI is a 2 Gbit DDR3L part, its running vendor bootloader reports "md.l 0x20111050 1 -> 00000016", and the 4 KB register block lifted out of that bootloader is byte-for-byte reg_info_hi3516cv200.bin. Splicing that table into u-boot-hi3518ev200-recovery.bin at offset 64 and uploading it over UART boots to a U-Boot prompt on the reporter's hardware. So the DDR3 table for this silicon already exists in the tree and is already validated -- hi3518ev200 simply has no build that uses it. The mini-boot link step dd's the table in at a fixed offset with no checksum over it, so the variant is a table swap and nothing else: same config, same sources, same image size. The matrix therefore separates what was one field into three: `name` is the published artifact, `config` the u-boot board config, and `reg` the table. reg_info_hi3516cv200.bin is referenced rather than copied to a second filename, so the two builds cannot drift apart silently. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
PR Summary by QodoPublish DDR3 U-Boot images for hi3518ev200 boards
AI Description
Diagram
High-Level Assessment
Files changed (1)
|
Code Review by Qodo
1. DDR3 selection remains undocumented
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
| # is shared rather than copied. | ||
| include: | ||
| - { name: hi3518ev200, config: hi3518ev200, reg: reg_info_hi3518ev200.bin } | ||
| - { name: hi3518ev200-ddr3, config: hi3518ev200, reg: reg_info_hi3516cv200.bin } |
There was a problem hiding this comment.
1. Ddr3 selection remains undocumented 📎 Requirement gap ⚙ Maintainability
The PR publishes a new hi3518ev200-ddr3 artifact but adds no installation guidance for checking 0x20111050 or choosing DDR2 versus DDR3 images. Users can therefore flash the wrong DRAM variant and leave the device unable to boot.
Agent Prompt
## Issue description
The newly published `hi3518ev200-ddr3` variant lacks user-facing installation guidance for determining the board's DRAM type and selecting the matching image.
## Issue Context
Document running `md.l 0x20111050 1` from a working HiSilicon U-Boot, explain that a final hexadecimal digit of `5` means DDR2 and `6` means DDR3, and map those results to the standard and `-ddr3` artifacts respectively.
## Fix Focus Areas
- README[24-31]
- .github/workflows/build.yml[15-27]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Publishing a -ddr3 variant creates a hazard that did not exist while there was only one image: a DDR2 board flashed with the DDR3 image fails in exactly the same way the DDR3 boards have been failing, and the failure looks like a bad flash rather than a wrong choice. So document the pre-flight check next to the download table. `md.l 0x20111050 1` from any working HiSilicon U-Boot -- the vendor's own bootloader will do -- reads DMC_CFG_DDRMODE, whose last hex digit is the DRAM type per DMC_CFG_DRAM_TYPE_MASK in drivers/ddr/ddr_ddrc_v500.h: 5 is DDR2, 6 is DDR3. The repository's front page was upstream U-Boot's stock README, which says nothing about which of these artifacts to use or what the -recovery images are for. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
Addressing the Qodo review. Requirement gap — "DDR3 selection remains undocumented": valid, fixed in 42a5e77. The concern is right and it is the one real hazard this PR introduces: The suggested location was not right, though: Two things I did not take from the suggestion, both because I could not
The wiki's |
|
Correction to my note above: I said the wiki side was tracked in #8, but |
1 participant
Closes #8. Field case: OpenIPC/firmware#2299.
Symptom
A hi3518ev200 camera that flashes cleanly and then boots nothing. The
bootloader partition verifies byte-for-byte after writing, the vendor
bootloader written back the same way boots fine, and a UART recovery
upload ACKs every chunk and then produces only
0x20bootmode markerswhere the jump should be. It reads as a bad flash or a bad upload. It is
neither.
Cause
reg_info_hi3518ev200.binsetsDMC_CFG_DDRMODE(0x20111050) to0x15. Fromdrivers/ddr/ddr_ddrc_v500.h:0x15is DDR2. On a board populated with DDR3 there is no workingmemory at all, so the SPL runs out of SRAM, misprograms the controller
and faults on the first DRAM access — before anything can print.
0x20111050reg_info_hi3518ev200.bin0x00000015reg_info_hi3518ev201.bin0x00000015reg_info_hi3516cv200.bin0x00000016hi3516cv200 is the same DDRC v500 and the same PHY S40, and it already
ships a validated DDR3 table. hi3518ev200 just has no build that uses
one.
Evidence from the affected board
Nanya
NT5CC128M16IP-DI, a 2 Gbit DDR3L part, read off the package.Its running vendor bootloader:
md.l 0x20111050 1→00000016.The 4 KB register block extracted from that vendor bootloader is
byte-for-byte identical to
reg_info_hi3516cv200.bin(3584 bytesof table, remainder zero padding). The table this PR selects is
literally the one the board's own vendor firmware uses.
Splicing it into the published
u-boot-hi3518ev200-recovery.binatoffset 64 and uploading over UART boots to a prompt:
Change
mini-boot.binis assembled as 64 B vectors + a 4096 B register table +code + LZMA payload, with no checksum over the table region. The table is
dd'd in withbs=4096 conv=sync, so swapping it is size-neutralregardless of which table file is used — a DDR3 variant needs no code
change and no config change.
The build matrix splits its one field into three:
name(publishedartifact),
config(u-boot board config),reg(register table).reg_info_hi3516cv200.binis referenced rather than copied to a secondfilename so the two builds cannot drift apart silently.
New artifacts:
u-boot-hi3518ev200-ddr3-universal.binandu-boot-hi3518ev200-ddr3-recovery.bin. Thehi3518ev200andhi3516cv200jobs build from exactly the config and table they builtfrom before, so no DDR2 board changes behaviour.
Verification of the CI artifacts
Every artifact from this run, checked against the table it should carry
and the DRAM type that table encodes:
On the sizes not matching: they differ by 8 bytes between the
hi3518ev200 and hi3518ev200-ddr3 jobs, and this is not the table. The
build is not reproducible —
Makefile:488generatesU_BOOT_DATE/U_BOOT_TIMEfromdateon every build, so the LZMApayload changes length slightly run to run and the linked addresses ahead
of it shift with it. The same effect shows up between this run's
u-boot-hi3518ev200-universal.binand the currently published one: same133443 bytes, 18164 differing bytes inside the payload, identical source.
Worth fixing on its own, but it is pre-existing and orthogonal to this
change.
Test plan
actionlintclean (two SC2046 warnings, both pre-existing onmaster).Known limitation, not addressed here
hi3518ev200.hsetsCFG_DDR_SIZEto 64 MB, anddetect_memory()probes with
get_ram_size(base, CFG_DDR_SIZE)— so it cannot reportmore than 64 MB, and
totalmemis whatload_hisiliconuses to sizeMMZ. The board in #2299 has 128 MB (its vendor kernel maps to
0x88000000), so it will boot correctly but see half its RAM. That is aseparate change with its own blast radius on existing DDR2 boards, and I
would rather land the fix that turns a brick into a booting camera
first.