hisilicon-osdrv-hi3516cv200: rmmod openhisilicon source modules by open_* name

[widgetii]

Summary

load_hisilicon for hi3516cv200 (V2; covers hi3516cv200 / hi3518ev200 / hi3518ev201) issued rmmod -w against vendor file names (mmz, hi_media, sys_config, sensor_i2c, sensor_spi, hi3518e_isp, hi_mipi, pwm, wdt) for modules openhisilicon ships with KBUILD_MODNAME=open_*. Those rmmods miss silently with "No such file or directory".

The cv200 failure path is more visible than other platforms: when fw_env.config isn't readable (or the env has no sensor key), load_hisilicon falls through to autodetect. Partial unload from name-mismatched rmmods leaves open_mmz loaded; insert_ko's insmod mmz.ko … || report_error then hits "module already loaded", calls report_error, exits the script. /dev/sys never re-appears, majestic dies with Cannot get chip id.

This is exactly the regression originally reported by a XiongMai X50H20L_18EV200_S38 user on OpenIPC 2.6.04.27-lite — see OpenIPC/openhisilicon#62 for the full investigation.

Why cv200 needs only a partial rename

Verified by extracting .gnu.linkonce.this_module from a live cv200 rootfs:

File	Internal name
mmz.ko	open_mmz
hi_media.ko	open_himedia
sys_config.ko	open_sys_config
sensor_i2c.ko	open_sensor_i2c
sensor_spi.ko	open_sensor_spi
hi3518e_isp.ko	open_isp
hi_mipi.ko	open_mipi_rx
pwm.ko	open_pwm
wdt.ko	open_wdt
hi3518e_base.ko	hi3518e_base
hi3518e_sys.ko	hi3518e_sys
hi3518e_{adec,aenc,ai,ao,aio}.ko	hi3518e_{...}
hi3518e_{venc,h264e,...,vpss,viu,vgs,region,tde,ive,chnl,jpege,rc}.ko	hi3518e_{...}
acodec.ko	acodec

Strategy B blob-wrapped modules (everything in bold) keep their vendor names because the vendor .o's .gnu.linkonce.this_module wins the link, so their rmmod -w calls don't change. Only Strategy C source-built modules need the rename.

Live verification

Tested on real hi3516cv200 hardware (hi3518ev200, OpenIPC 2.6.04.28, JXF22 sensor, MMZ 32M):

$ load_hisilicon -r 2>&1     # with patched script
...
rmmod: can't unload module 'tlv_320aic31': No such file or directory  # expected
rmmod: can't unload module 'hifb': No such file or directory          # expected
$ lsmod | grep -v '^(8188fu|cfg80211|vfat|fat)' | wc -l
5    # all camera modules cleanly unloaded

$ load_hisilicon -i 2>&1
==== Your input Sensor type is jxf22 ====    # success marker
$ ls /dev/sys
/dev/sys
$ lsmod | wc -l
32
$ majestic
... [sdk] start_sdk@557: HiSilicon SDK started
... [rtsp] rtsp_init@28: RTSP server started on port 554

Two consecutive -r/-i cycles ran without errors.

For comparison, with the original script the same -r leaves open_mmz / open_himedia / open_sys_config / open_sensor_i2c / open_isp / open_mipi_rx / open_pwm / open_wdt orphaned in lsmod, and the next -i hits report_error at insert_mmz's insmod mmz.ko ... || report_error — bricking majestic.

Refs

• OpenIPC/openhisilicon#62 — root-cause investigation, includes the user's original XiongMai X50H20L_18EV200_S38 failure log.
• OpenIPC/openhisilicon#63 — CI assertions PR. CV200 stays masked there by OpenIPC/openhisilicon#64 (sys.ko EPERM in qemu-hisilicon's cv200 emulation), so the QEMU CI loop won't catch this — real-hardware test above is the validation.
• Sibling fixes opened earlier: OpenIPC/firmware#2026 (cv500), #2027 (cv100), #2028 (3519v101).

Scope and follow-ups

15 rmmod call sites updated. Strategy B blobs and external modules (tlv_320aic31, hifb, audio Strategy B, video Strategy B, acodec) preserved.

Sibling cv200-family platforms still TODO: hi3516av100 (V2A; blocked by #65 in CI but the rename pattern should mirror this). hi3516cv300 (V3; blocked by #66).

[widgetii]

Autodetect-path verification on real hi3516cv200 hardware

Updated my testing to exercise the actual user-bug code path (insert_detect → ipcinfo → remove_detect → insert_ko), not just the manual -r/-i cycle I'd validated earlier. Results below.

Setup

Camera: hi3518ev200 / Hi3518EV20X SoC / JXF22 sensor / OpenIPC 2.6.04.28-lite (busybox 1.36.1, kernel 4.9.37). Patched script at /usr/bin/load_hisilicon. /etc/fw_env.config was actually present on this lab camera, so the env path is the default; I forced the autodetect branch by replacing /usr/sbin/fw_printenv with a stub that returns 1 (matching the user's Cannot parse config file '/etc/fw_env.config' failure mode).

Procedure

1. killall majestic; load_hisilicon -r — clean unload via the safe (env) path so remove_ko's order-aware unload runs while the system is fully loaded; ends with 5 unrelated modules left (8188fu, cfg80211, vfat/fat).
2. Replace fw_printenv with #!/bin/sh\nexit 1 stub. Verified fw_printenv -n sensor; echo $? prints 1.
3. load_hisilicon -i (no -sensor arg) — script's if fw_printenv -n sensor returns false → enters the autodetect branch.
4. Restore /usr/sbin/fw_printenv from /tmp backup.

Result

mmz_start: 0x82000000, mmz_size: 32M
hisilicon: Get data from ipcinfo and set SENSOR as jxf22       ← autodetect ran
insert audio
==== Your input Sensor type is jxf22 ====                     ← insert_ko completed

• Get data from ipcinfo (not from environment) confirms insert_detect → ipcinfo --short-sensor → remove_detect ran.
• ==== Your input Sensor type is jxf22 ==== confirms insert_ko completed without hitting report_error. With the original script, this would have died at insert_mmz's insmod mmz.ko ... || report_error because mmz was orphaned in open_mmz form by remove_detect's silent rmmod misses.
• lsmod | wc -l = 32 — full module set: hi3518e_{base,sys,viu,vpss,venc,h264e,jpege,chnl,rc,vgs,region,tde,ive,adec,aenc,ai,ao,aio} + acodec + source-side open_{mmz,himedia,sys_config,isp,sensor_i2c,mipi_rx,pwm,wdt}.
• ls /dev/sys → /dev/sys exists.
• Zero rmmod: can't unload lines in the autodetect log (other than the expected tlv_320aic31 / hifb legitimately-not-loaded ones during the prior remove_ko).
• After restoring fw_printenv: majestic started cleanly, reached HiSilicon SDK started, RTSP up on :554, HTTP up on :80.

Why this validates the user's report

The original report had Cannot parse config file '/etc/fw_env.config' errors, so load_hisilicon's fw_printenv -n sensor returned non-zero on every boot, S70vendor's load_hisilicon -i always took the autodetect branch, and remove_detect's name-mismatched rmmods left source modules orphaned — insert_ko's first insmod mmz.ko || report_error then exited the script. End state: lsmod stuck at open_sensor_spi, open_sensor_i2c, open_isp, hi3518e_base, open_himedia, open_mmz, open_sys_config — exactly what the user pasted.

This test reproduced that exact failure path in a controlled way (stub fw_printenv → guaranteed autodetect entry) and confirmed the patched script lands in a working state instead.

The earlier "verified live" claim only covered the remove_ko path via manual -r/-i cycles, which did not exercise remove_detect. This run closes that gap.