hi3516cv500 family ships every opensdk module twice (~1.7 MB of squashfs per board)

[widgetii]

On every hi3516cv500-family image (kernel 7.0.0, hisilicon-opensdk), all 45 open_*.ko modules are present twice:

• /lib/modules/7.0.0/hisilicon/ — hand-installed by HISILICON_OPENSDK_INSTALL_TARGET_CMDS in general/package/hisilicon-opensdk/hisilicon-opensdk.mk (the cv500 branch installs open_*.ko verbatim);
• /lib/modules/7.0.0/updates/ — installed a second time by buildroot's kernel-module infrastructure (modules_install with INSTALL_MOD_STRIP=1).

Each tree is ~5.4 MB uncompressed. The copies are near- but not byte-identical (strip differences), so squashfs cannot deduplicate them — roughly 1.7 MB of compressed rootfs wasted on each of the four boards (hi3516av300_lite/_neo, hi3516cv500_lite, hi3516dv300_lite). Numbers are from the sizes.hi3516av300-neo.json asset of nightly-20260831-bebd80a (also visible in firmware-explorer).

load_hisilicon for this family drives everything through modprobe open_*, so depmod's search order resolves each name to exactly one tree and the other is dead weight. The hisilicon/ copy exists for vendor-name alignment on the older families; on cv500 the names in updates/ are already the open_* names the load script asks for, so the hand-install may have been redundant from birth.

Candidate fixes, in preference order:

1. Drop the cv500 hand-install and let updates/ serve modprobe (verify on hardware which tree depmod currently resolves — cf. the xm530 case where depmod preferred the vendor copy, xm530: autoload the SD card driver at boot #2315).
2. If both paths must keep existing, make the copies byte-identical so squashfs dedups them.

Needs a cv500-family board to verify boot + stream before touching — which is why this is an issue and not part of the PR that found it (#2346's size regression on hi3516av300_neo was fixed by pruning the consumer-less libsvpruntime.so/libnnie.so instead).