[widgetii]

Their firmware now ships the split NOR package beside the fixed-slot one (OpenIPC/firmware#2655, on OpenIPC/linux#131), and their OpenIPC/u-boot NOR build scans for it (OpenIPC/u-boot#48), so they join NOR_SPLIT_SOCS: one firmware.bin.<soc> at 0x50000, the rest of the chip erased. They already take u-boot-<soc>-nor.bin (PER_FLASH_TYPE_UBOOT).

hi3516ev300 stays on fixed slots: its uImage (2009K with the split options) fills the 2 MiB slot, over the 1983K a fixed-slot package beside a split one may use, so its firmware ships no split package. A test keeps it out even though its profile is an alias of hi3516ev200.

The split package appears with the next nightly. Until the U-Boot publish workflow runs again, the published u-boot-<soc>-nor.bin predates #48: the split image still boots under it (the kernel ignores its fixed mtdparts, checked in QEMU), but its scan and fwupd for the split image come with the republished build.

Not run on hardware; the firmware side was checked in qemu-hisilicon (hi3516ev200, hi3518ev300; 8 and 16 MB). pytest tests/ --ignore=tests/fuzz: 1084 passed. ruff and mypy are clean.

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

PR Summary by Qodo

Enable split NOR installs for three HiSilicon SoCs

✨ Enhancement 🧪 Tests 📝 Documentation 🕐 10-20 Minutes

AI Description

• Enable split NOR packages for hi3516ev200, hi3518ev300, and hi3516dv200.
• Keep hi3516ev300 on fixed slots because its kernel exceeds the compatible size limit.
• Test SoC eligibility and document the supported layouts.

Diagram

graph TD
  A["SoC profile"] --> B{"Split eligible?"} -->|Yes| C["Split NOR package"] --> D["NOR installer"] --> E["NOR flash"]
  B -->|ev300: no| F["Fixed-slot package"] --> D

Loading

High-Level Assessment

Extending the existing package-board eligibility set is the appropriate approach: the split installer and per-flash-type U-Boot selection already exist. Inferring eligibility from the shared profile would incorrectly admit hi3516ev300, so explicit exclusion is warranted.

Files changed (3) +7 / -2

Enhancement (1) +3 / -0

firmware.pyEnable split NOR eligibility for three SoCs +3/-0

Enable split NOR eligibility for three SoCs

• Adds hi3516ev200, hi3518ev300, and hi3516dv200 to NOR_SPLIT_SOCS. Leaves hi3516ev300 on fixed slots because its kernel fills the available slot.

src/defib/firmware.py

Tests (1) +2 / -1

test_install_nor_split.pyCover split NOR eligibility for the added SoCs +2/-1

Cover split NOR eligibility for the added SoCs

• Extends the eligibility assertion to all three SoCs. The existing assertion continues to guard against admitting hi3516ev300.

tests/test_install_nor_split.py

Documentation (1) +2 / -1

CLAUDE.mdDocument the expanded split NOR SoC list +2/-1

Document the expanded split NOR SoC list

• Adds the three supported SoCs to the layout guidance and explicitly notes that hi3516ev300 remains excluded.

CLAUDE.md

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

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Fixed-slot installs can use wrong partitions 🐞 Bug ≡ Correctness

Description

Adding these chips to NOR_SPLIT_SOCS also makes scanning_nor_uboot select env default -a for
fixed-slot packages, replacing the previous explicit mtdparts and bootcmd setup. When a NOR
U-Boot's defaults describe different slots from those selected for the detected flash size, the
installer still writes the selected slots but saves the mismatched defaults; this also affects
existing fixed-slot packages, not just the new split packages.

Code

src/defib/firmware.py[92]

+    "hi3516ev200", "hi3518ev300", "hi3516dv200",

Evidence

Membership now controls both split-package acceptance and the scanning-environment branch. That
branch resets defaults without setting partitions, while the former branch constructed mtdparts
from the detected NOR size. The repository defines different 8 MiB and 16 MiB fixed-slot offsets and
includes an 8 MiB fixed default in its generic boot-environment test; the repository does not
establish that every currently published NOR binary for the added chips supplies defaults matching
the installer-selected size.

src/defib/firmware.py[86-93]
src/defib/install/orchestrator.py[234-265]
src/defib/install/orchestrator.py[1760-1781]
src/defib/install/orchestrator.py[1810-1821]
src/defib/install/layout.py[15-34]
tests/test_ds_i203_final_contract.py[795-799]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Adding split-package support also changes how fixed-slot installs configure the boot environment. An older NOR U-Boot with fixed defaults can retain partition settings that disagree with the installer-selected flash layout.
## Fix Focus Areas
- src/defib/firmware.py[86-93]
- src/defib/install/orchestrator.py[234-265]
- src/defib/install/orchestrator.py[1760-1821]
## Recommended Fix
Decouple eligibility for a split firmware package from the decision to rely on a scanning U-Boot's default environment. Preserve or verify layout-matching environment settings for fixed-slot installs using a non-scanning NOR binary, and test the path with mismatched default and detected flash sizes.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can start a comment with 'qodo' or '@qodo' to chat about any finding

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

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

1. Fixed-slot installs can use wrong partitions 🐞 Bug ≡ Correctness

Adding these chips to NOR_SPLIT_SOCS also makes scanning_nor_uboot select env default -a for
fixed-slot packages, replacing the previous explicit mtdparts and bootcmd setup. When a NOR
U-Boot's defaults describe different slots from those selected for the detected flash size, the
installer still writes the selected slots but saves the mismatched defaults; this also affects
existing fixed-slot packages, not just the new split packages.

Agent Prompt

## Issue description
Adding split-package support also changes how fixed-slot installs configure the boot environment. An older NOR U-Boot with fixed defaults can retain partition settings that disagree with the installer-selected flash layout.

## Fix Focus Areas
- src/defib/firmware.py[86-93]
- src/defib/install/orchestrator.py[234-265]
- src/defib/install/orchestrator.py[1760-1821]

## Recommended Fix
Decouple eligibility for a split firmware package from the decision to rely on a scanning U-Boot's default environment. Preserve or verify layout-matching environment settings for fixed-slot installs using a non-scanning NOR binary, and test the path with mismatched default and detected flash sizes.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[widgetii]

Keeping this. The env default -a path runs only when the same install wrote the U-Boot ("uboot" in stage_set), and for these SoCs that is the published u-boot-<soc>-nor.bin: built by OpenIPC/u-boot openipc-hisilicon since u-boot-xmedia stopped publishing them, and it scans the layout on fixed slots too, so its defaults always match what is on the flash. In qemu-hisilicon, the published u-boot-hi3516ev200-nor.bin (2022.10-g862ab6b1) on fixed-slot images:

• 8 MB lite: Found RootFS at 0x00250000, mtdparts=...2048k(kernel),5120k(rootfs)..., root on 31:3;
• 16 MB ultimate: Found RootFS at 0x00350000, mtdparts=...3072k(kernel),10240k(rootfs)..., root on 31:3.

A hand-supplied non-scanning --uboot binary would hit the same assumption on the gk7205v200 family and hi3516cv300 already; deciding on the U-Boot rather than the SoC would be its own change across all split SoCs.