Add CI matrix rows for hi3516cv200_neo + hi3516av100_neo (qemu-boot smoke)

[widgetii]

Context

PR #2122 lands two new firmware targets (hi3516cv200_neo, hi3516av100_neo) that build cleanly and pass a local QEMU smoke (login + DHCP + ping). But the PR explicitly does not add CI matrix rows because the existing cv500/cv300 qemu-smoke jobs were already gated allow-failure: true for unrelated firmware-side bugs, and adding rows mid-merge tends to cause re-runs that mask real regressions.

What to add

In .github/workflows/... (the build matrix that drives the openhisilicon-side qemu-boot job is in OpenIPC/openhisilicon/.github/workflows/build.yml; firmware-side artifact production is in this repo).

openhisilicon-side qemu-boot matrix

Add two rows to the existing qemu-boot: job in OpenIPC/openhisilicon/.github/workflows/build.yml:

- machine: hi3516cv200
  firmware: hi3516cv200  # or hi3516cv200-neo if we ship neo artifacts to a separate tarball
  mem: 64M
  variant: neo
  append: "console=ttyAMA0,115200 mem=32M root=/dev/ram0 rootfstype=squashfs"

- machine: hi3516av100
  firmware: hi3516av100
  mem: 256M
  variant: neo
  append: "console=ttyAMA0,115200 mem=32M root=/dev/ram0 rootfstype=squashfs"

The firmware field drives which nightly tarball to download. Today the firmware repo only publishes openipc.hi3516cv200-nor-lite.tgz style names. Two paths:

1. Tag-suffix the neo tarballs: openipc.hi3516cv200-nor-neo.tgz, etc., in the release-publish step. The build already produces these (the local build that landed PR hi3516cv200_neo + hi3516av100_neo: V2/V2A modern-kernel firmware targets #2122 produces exactly this filename).
2. Per-row firmware filename override: extend the matrix schema with an explicit tarball: field.

Firmware-side artifact production

Confirm that the nightly release publishes both -nor-lite.tgz and -nor-neo.tgz for cv200 + av100 once PR #2122 lands. Check the build-and-publish workflow's variant loop.

DoD for the new rows

Same as cv300_neo / ev300_neo today:

• Boot under qemu-hisilicon
• Reach openipc-<chip> login: prompt
• S99lsmodprobe runs and emits ===CI:HISI_MOD_COUNT===N=== for N >= 5 (or whatever threshold suits — V2/V2A loads fewer modules than V4)
• No Oops:, panic:, BUG:, Call Trace, Unable to handle in serial console

cv200_neo + av100_neo can start allow-failure: true (mirroring cv300_neo today) since the firmware-side load_hisilicon path is still wired to 4.9 kernel paths. Once that lands, drop allow-failure.

Why not in PR #2122

Per the merge guideline established for cv300_neo: introduce neo artifact paths and CI rows in separate PRs so regressions in one don't gate the other. PR #2122 lands the build path; this issue tracks the CI row addition.

Related

• hi3516cv200_neo + hi3516av100_neo: V2/V2A modern-kernel firmware targets #2122 (cv200_neo + av100_neo bring-up)
• kernel/osal_v2_shim,osal_v2a_shim: cover the full V2/V2A blob-symbol set openhisilicon#170, Profiler patch #171 (V2/V2A OSAL shim landings)
• arm: hisilicon: add hi3516av100 SoC support (CRG + DT + higmac driver) linux#44 (hi3516av100 mainline SoC support)

[widgetii]

Resolved by OpenIPC/openhisilicon#174 (merged as 2c83781e).

Two new rows added to the qemu-boot matrix:

• QEMU boot (hi3516cv200_neo) — mem 64M
• QEMU boot (hi3516av100_neo) — mem 256M

Both gated allow-failure: true until:

1. Next nightly publishes openipc.*-nor-neo.tgz for cv200 + av100 (firmware-side artifact loop iterates defconfigs so happens automatically post-hi3516cv200_neo + hi3516av100_neo: V2/V2A modern-kernel firmware targets #2122).
2. Firmware-side load_hisilicon learns the kernel 7.0 module path (separate follow-up in this repo).

[widgetii]

Reopened — the row-addition PR (openhisilicon#174) is being reverted via openhisilicon#175 because the nightly hasn't published openipc.*-nor-neo.tgz for cv200 + av100 yet (firmware#2122 only just landed). Will re-open the row addition once the firmware artifact loop publishes the neo tarballs on its next run.