[widgetii]

Adds build-xm.yml for the new openipc-xm branch (#13), the same shape as build-hisilicon.yml:

• Jobs: resolve → build (xm510/xm530/xm550, NOR fit check ≤ 256 KiB) → qemu → qemu_smoke → release / publish. Release and publish run on dispatch only.
• No hold: every SoC has a qemu-hisilicon machine, so every image is smoke-tested and gated.
• Smoke test: each NOR image boots in place from an 8 MiB flash image, twice, with the part powering up under the per-block protection Xiongmai bootloaders leave on (xm-sfc.wps, qemu-hisilicon#150).
  • It passes on Hit Ctrl-C.
  • It fails if the second boot finds a bad env CRC. That would mean the first boot's saveenv was dropped because the driver didn't clear the protection.
• Release and publish:
  • release uploads to a new xiongmai tag.
  • publish uploads to OpenIPC/firmware latest (no u-boot-xm* names there today) and reports --source uboot to openipc.org with a uboot-xm-… build id, sharing hisilicon's concurrency group.
  • openipc.org keeps the newest uboot build per file name, so the two workflows don't displace each other.
• Trigger: pull_request runs only when this workflow file changes, so other openipc PRs don't start the xiongmai matrix.
• Docs: README and CLAUDE.md describe the branch and the workflow.

Checked locally: the smoke script as written passes on all three SoCs against qemu-hisilicon master. This PR's own run builds the current openipc-xm.

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

PR Summary by Qodo

Build, smoke-test, and publish Xiongmai U-Boot images

✨ Enhancement ⚙️ Configuration changes 📝 Documentation 🕐 40+ Minutes

AI Description

• Add CI builds and 256 KiB NOR fit checks for XM510, XM530, and XM550.
• Gate releases on two protected-flash QEMU boots that verify saved environment persistence.
• Document the Xiongmai branch and add dispatch-only release and publishing paths.

Diagram

graph TD
  R["Resolve revision"] --> B["Build NOR images"] --> S["QEMU smoke gate"] --> P["Publish images"] --> F[("Firmware latest")]
  Q["Build QEMU"] --> S
  S --> L[("Xiongmai release")]
  P --> W[("openipc.org records")]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Parameterize the existing HiSilicon workflow

• ➕ Keeps common build, artifact, and publishing logic in one place.
• ➖ Adds family-specific branches to a mature workflow and increases regression risk for HiSilicon releases.

2. Pin the QEMU revision

• ➕ Makes the protected-flash smoke test reproducible across runs.
• ➖ Requires deliberate updates to receive machine-model fixes.

Recommendation: Keep the separate Xiongmai workflow: its three-SoC, two-boot gate differs enough to justify family isolation. Consider extracting shared publishing logic later if duplication grows, and pin a tested QEMU revision once the required WPS support is available.

Files changed (3) +423 / -0

Documentation (2) +71 / -0

CLAUDE.mdDocument Xiongmai branch and CI invariants +24/-0

Document Xiongmai branch and CI invariants

• Describes the openipc-xm branch, workflow triggers, two-boot smoke-test criterion, and release and publishing behavior.

CLAUDE.md

README.mdAdd Xiongmai build and workflow guidance +47/-0

Add Xiongmai build and workflow guidance

• Adds a workflow badge, branch listing, supported SoCs, build instructions, and CI and release guidance. Explains run-in-place NOR boot and the flash-protection behavior covered by smoke testing.

README.md

Other (1) +352 / -0

build-xm.ymlAdd gated Xiongmai build and publishing workflow +352/-0

Add gated Xiongmai build and publishing workflow

• Adds revision-pinned NOR builds for three SoCs with partition-fit checks, then smoke-tests each image twice in QEMU with flash protection enabled. Dispatch-only jobs upload gated artifacts to the Xiongmai release or OpenIPC/firmware and report the published build to openipc.org.

.github/workflows/build-xm.yml

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

Code Review by Qodo

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

1. Smoke tests stop before QEMU boots ✓ Resolved

Description

The flash-creation command pipes an infinite tr stream into head, which closes the pipe after 8
MiB and causes tr to exit with SIGPIPE. In the smoke step’s default Bash error-handling mode, that
nonzero pipeline result stops every SoC leg before the image is copied into flash or QEMU starts.

Code

.github/workflows/build-xm.yml[214]

+          tr '\0' '\377' < /dev/zero | head -c 8388608 > /tmp/flash.bin

Evidence

The finite head consumer follows an infinite producer, and flash creation precedes both the image
overlay and QEMU launch. The existing HiSilicon smoke test uses dd rather than a truncated
producer pipeline.

.github/workflows/build-xm.yml[208-225]
.github/workflows/build-hisilicon.yml[290-300]

Agent prompt

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

## Issue description
The infinite `tr` producer receives SIGPIPE when `head` has written 8 MiB, making the smoke step fail before booting QEMU.
## Fix Focus Areas
- .github/workflows/build-xm.yml[213-215]
## Recommended Fix
Create an exactly 8 MiB erased flash file without an infinite-producer pipeline that fails under `pipefail`, then retain the U-Boot image overlay.

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

---

2. Oversized NOR images pass the fit gate ✓ Resolved

Description

check_kind divides the image’s byte count by 1024 before comparing it with the 256 KiB partition
limit, discarding any remainder. An image between 262,145 and 263,167 bytes therefore passes the
check despite extending beyond the boot partition into the environment area.

Code

.github/workflows/build-xm.yml[R115-117]

+              size_kb=$(( $(stat -c %s "$f") / 1024 ))
+              echo "- $f: [${size_kb}KB/${limit_kb}KB]"
+              if [ "$size_kb" -gt "$limit_kb" ]; then

Evidence

The workflow states that NOR boot ends at 256 KiB, but integer division makes every image from one
to 1,023 bytes above that boundary compare as 256 KiB.

.github/workflows/build-xm.yml[98-124]
CLAUDE.md[75-79]

Agent prompt

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

## Issue description
Rounding image sizes down to whole KiB lets slightly oversized NOR images pass the partition-fit gate.
## Fix Focus Areas
- .github/workflows/build-xm.yml[107-120]
## Recommended Fix
Compare the raw `stat` byte count against `limit_kb * 1024`; round only values displayed in diagnostic messages.

ⓘ 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 see how risky a PR is at a glance with blast radius labels

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗