profiles: cap hi3516cv200's SPL upload at its 16 KB SRAM ceiling

[openipc-ai]

Follow-up to #126, which fixed the same defect on hi3518ev200.

Why cv200 has it too

The two profiles are the same silicon window — only PRESTEP0 differs:

	hi3518ev200	hi3516cv200
ADDRESS	0x04013000 / 0x04010500 / 0x81000000	identical
FILELEN	0x0040 / 0x3b00	identical
SRAM ceiling	0x04010500 + 0x3B00 = 0x04014000	identical
shipped image	135452 B, LZMA at 0x4BB0 → detects 0x4800	135432 B, LZMA at 0x4BB0 → detects 0x4800
overrun	3328 B	3328 B

Both are built by the same build.sh in OpenIPC/u-boot-hi3516cv200 (SOCS="hi3518ev200 hi3516cv200").

Evidence

The ev200 half was confirmed on real hardware in OpenIPC/firmware#2299 — chunks 1-14 ACK on
attempt 1/32, chunk 15 targets 0x04013D00..0x04014100, the bootrom stops answering and all 32
retries time out. With #126's cap the same board completes both stages with no retries at all.

cv200 puts identical numbers through the identical code path. I have no cv200 to burn, so that
inference plus the profile diff is the evidence here.

What this does and doesn't fix

Does: stops defib writing past the bootrom's stack mid-upload.

Doesn't: make cv200 recoverable. The prelude these builds produce is 19376 B against a 15104 B
window, so even a correctly-capped SPL is missing 4272 bytes of live code and won't execute —
tracked upstream as OpenIPC/u-boot-hi3516cv200#5. This is the difference between a clean failure
and a wedged chip.

Test plan

• pytest — 734 passed, 2 skipped
• Regression test asserting spl_sram_limit == 0x3B00 and spl_address + limit == 0x04014000
• cv200 hardware — none available; ev200 sibling verified in firmware#2299

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Cap hi3516cv200 SPL uploads at SRAM ceiling

🐞 Bug fix 🧪 Tests 🕐 Less than 10 minutes

AI Description

• Caps hi3516cv200 SPL uploads at the 15,104-byte SRAM window.
• Prevents detected OpenIPC images from overwriting boot ROM memory and wedging devices.
• Adds regression coverage for the configured cap and absolute SRAM ceiling.

Diagram

graph TD
  A["cv200 Profile"] --> B["Profile Loader"] --> C["SPL Detection"] --> D["BootROM Upload"]
  E["Regression Test"] -.-> A

Loading

High-Level Assessment

Using the existing optional SRAMLIMIT profile field is the best approach because the defect is chip-profile-specific and the shared detection/upload path already enforces this cap. Changing global detection behavior would risk unrelated profiles, while hard-coding the chip in protocol logic would duplicate profile knowledge.

Files changed (2) +12 / -1

Bug fix (1) +1 / -1

hi3516cv200.jsonSet hi3516cv200 SPL SRAM upload limit +1/-1

Set hi3516cv200 SPL SRAM upload limit

• Adds a 0x3B00 SRAMLIMIT so detected SPL boundaries cannot extend beyond the 0x04014000 SRAM ceiling. This prevents the uploader from writing into boot ROM working memory when OpenIPC image detection returns 0x4800.

src/defib/profiles/data/hi3516cv200.json

Tests (1) +11 / -0

test_protocol_standard.pyVerify hi3516cv200 SRAM limit wiring +11/-0

Verify hi3516cv200 SRAM limit wiring

• Adds a regression test that loads the hi3516cv200 profile and confirms both the 0x3B00 parsed cap and the computed 0x04014000 ceiling.

tests/test_protocol_standard.py

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can switch off images and animations for a plain-text comment

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗