QEMU CI: hi3518e_sys.ko returns -EPERM during init under qemu-hisilicon (CV200)

[widgetii]

What CI shows

QEMU boot (hi3516cv200) (job 73587502290 on PR #63 head):

Loading vendor modules...
mmz_start: 0x82000000, mmz_size: 32M
insmod: can't insert 'hi3518e_sys.ko': Operation not permitted
qemu-system-arm: terminating on signal 15 from pid 2982 (timeout)

init_module() for the cv200 sys blob returns -EPERM immediately. The script never reaches remove_detect() or insert_ko(), so the QEMU log truncates here.

Why this is not #62

• It happens during insert_detect()'s first insmod hi3518e_sys.ko — there is no prior partial-unload state and the module is not already loaded.
• The same insmod: can't insert 'hi3518e_sys.ko': Operation not permitted line appears in the Apr 19, 2026 QEMU CI run (run/24629058064), well before PR hisilicon-opensdk: re-apply overlay in target-finalize to beat osdrv firmware#2021 merged. At that point the file at /lib/modules/4.9.37/hisilicon/hi3518e_sys.ko was the vendor osdrv blob, not openhisilicon's renamed open_sys.ko (alphabetical target-finalize made vendor win). So the failure pre-dates openhisilicon ever shipping that module on cv200.
• On real hi3518ev200 hardware (openipc-hi3518ev200.dlab.doty.ru, kernel 4.9.37), insmod /lib/modules/4.9.37/hisilicon/hi3518e_sys.ko vi_vpss_online=0 mem_total=64 returns 0 and dmesg prints load sys.ko for Hi3518EV200...OK!. So sys.ko itself is fine; the failure is QEMU-side.

The most likely cause is the blob's init reading a chip-id / SCTL / clock register that qemu-hisilicon's hi3516cv200 machine doesn't model, returning a value the blob refuses, and bailing with -EPERM. This is independent of the load_hisilicon name-mismatch tracked in #62 — fixing #62 won't make this go away.

What's needed

1. Identify which register / hardware probe in hi3518e_sys.o is failing under qemu-hisilicon (objdump or dynamic trace via QEMU mmio log).
2. Either:
   • Extend qemu-hisilicon's hi3516cv200 machine to return whatever value the blob expects, or
   • Patch the cv200 sys init wrapper (kernel/init/hi3516cv200/sys_init.c) to skip the failing probe under QEMU when a runtime sentinel is set, or
   • Document this as a known QEMU limitation and exclude insmod: can't insert from the CI assertions.

Real-hardware test plan after fix

Whatever route we take, before declaring this fixed we must verify on real hi3518ev200 hardware (e.g. the dlab.doty.ru test camera) that:

• load_hisilicon -i -sensor jxf22 still loads sys.ko cleanly (dmesg | grep "load sys.ko").
• /dev/sys exists.
• majestic reaches Sensor driver loaded and serves a valid frame on /image.jpg.

Any QEMU-side workaround that makes CI green but breaks real-hardware module load is worse than no workaround.

Refs

• Filed alongside ci: fail QEMU smoke test on silent module-load regressions #63 (CI assertions) and CV200: open_* module names break load_hisilicon's remove_detect/insert_ko sequence #62 (real-hardware load_hisilicon name mismatch).
• Sibling issues for AV100 and CV300 will be filed for the analogous QEMU-only failures on those platforms.

[widgetii]

Closing — re-run of the PR #63 boot matrix passes for hi3516cv200: https://github.com/OpenIPC/openhisilicon/actions/runs/25115363588/job/73638970247

The fix landed in widgetii/qemu-hisilicon@b3bc53a ("hisi-sysctl: per-SoC SCSYSID layout to fix V1-V3 chip-id detection"), which set the V2 byte-layout SCSYSID block and chip_variant=1 for CV200, so the vendor blob's chip-ID probe now returns the value real silicon does instead of the packed 32-bit ID PR #39 had imposed.

Verified locally on the OpenIPC latest lite blob (/lib/modules/4.9.37/hisilicon/hi3518e_sys.ko):

# insmod hi3518e_sys.ko vi_vpss_online=0 sensor=unknown mem_total=64; echo $?
0
# dmesg | tail -1
load sys.ko for Hi3518EV200...OK!

— exactly the success line this issue documents from real hardware.

Real-hardware re-validation on the openipc-hi3518ev200.dlab.doty.ru test camera (per this issue's gating clause) is still owed before declaring the V2 path fully clean, but the QEMU CI failure that motivated this issue is gone.