kernel: bring up hi3516cv6xx (V5 — Hi3516CV610/CV608)

[widgetii]

Summary

Adds a new CHIPARCH=hi3516cv6xx arm to the openhisilicon kernel-module dispatch, covering the V5 generation of HiSilicon vision SoCs — Hi3516CV610 and Hi3516CV608.

42 open_*.ko modules build clean against openipc/linux 5.10.221 (ARMv7 Cortex-A7, musl) and load successfully on a real CV610 demo board:

• full MPP image + encode + audio + AI pipeline up
• /proc/umap/ exposes 27 chardevs (sys, vb, vi, isp, vpss, venc, h264e/h265e/jpege/svac3e, ive, svp_npu, aiisp, audio aio/ai/ao/aenc/adec/acodec, mipi_rx, pm, …)
• sensor I2C/SPI probe path reaches the bus (/dev/i2c-{0,1,2}, /dev/ot_mipi_rx)
• zero depmod warnings, zero unresolved symbols

Pattern

Mirrors hi3516cv500 with two structural differences inherent to V5:

• open_mmz ships as a separate module — V4 folded MMZ into open_osal
• every blob's init wrapper is shipped as source by the vendor SDK (Hi3516CV610_SDK_V1.0.2.0/.../out/init/src/*_init.c), so no init source had to be hand-written for the 30 blob-backed modules; only the closed MPP/codec payloads need blob-linking

Source patches against vendor code

Three small, scoped patches:

1. kernel/compat/kernel_compat.h — dma-contiguous.h gate switched to __has_include because the openipc/linux cv6xx kernel branch backports the upstream-5.16 merge of dma-contiguous.h into dma-map-ops.h onto 5.10.221, so the version-code-based gate misfires.

2. kernel/osal/hi3516cv6xx/mmz/cma_allocator.c —

   • pte_fn_t signature drift: 4-arg vendor (pte_t*, struct page*, addr, data) → upstream 3-arg (pte_t*, addr, data)
   • bsp_flush_tlb_kernel_range → public flush_tlb_kernel_range (the bsp_ wrapper lives in a vendor BSP we don't ship)
   • apply_to_page_range(&init_mm, …) gated behind CONFIG_CMA because init_mm is not EXPORT_SYMBOL'd and V5 boards default to CONFIG_CMA=n with mmz_allocator=ot at boot

3. kernel/pwm/hi3516cv6xx/pwm.c and kernel/piris/hi3516cv6xx/piris.c — force #undef IOMEM before redefining as __iomem. arch/arm/include/asm/io.h already provides IOMEM(x) as a function-like macro that collides with the vendor's object-like usage. Both files' #ifndef IOMEM guard sees the function-like macro and skips, leaving IOMEM as an undefined token at the use site.

Vendor blobs

The 30 closed-source .o payloads under kernel/obj/hi3516cv6xx/ are extracted from out/obj/mod_*.o in the Hi3516CV610_SDK_V1.0.2.0 release. Force-added because the repo .gitignore otherwise excludes *.o (same pattern as the cv500 / ev200 obj trees).

CI status

hi3516cv6xx is intentionally not in .github/workflows/build.yml's Build SDK matrix in this PR. The reason: the CI's "Build OpenHisilicon" step depends on firmware's hisilicon-opensdk.mk knowing how to dispatch CHIPARCH=hi3516cv6xx, and OpenIPC/firmware:master doesn't yet have that wiring (PR #2167 added the cv6xx board package but with prebuilt vendor .ko, not opensdk). Until the firmware companion PR lands (defconfig flip + opensdk.mk SoC arm + osdrv .mk strip + load_hisilicon rewrite), any matrix entry for hi3516cv6xx here would fail at the firmware checkout step and gate the PR.

CI matrix entry will land in the firmware companion PR cycle once both repos can dispatch cv6xx natively. The build itself has been validated locally (see "Test plan" below) using the firmware-side companion changes via BR2_PACKAGE_HISILICON_OPENSDK_OVERRIDE_SRCDIR.

Deferred follow-ups (not blocking)

• open_cipher, open_km, open_otp, open_hardware_cryptodev — vendor ships these only as full closed .ko (not separate mod_*.o); need a separate objcopy-extraction step
• open_es8388, open_sample_ist, open_spi_st7789 — extdrv audio codec / sample peripherals not used by the standard load_hisilicon chain

Hardware validation

Hi3516CV610 demo board (sc4336p sensor):

load mmz ....OK!
load base.ko ....OK!     <-- the boot-hang point before this PR
... 33 more "load X.ko ....OK!" lines ...
load sensor_i2c.ko ....OK!
load sensor_spi.ko ....OK!
ot_wtdg init ok.

$ lsmod | wc -l
43
$ ls /proc/umap | wc -l
27
$ ls /dev/i2c-* /dev/ot_*
/dev/i2c-0 /dev/i2c-1 /dev/i2c-2 /dev/ot_proc /dev/ot_lsadc /dev/ot_mipi_rx

Test plan

• Build clean (make BOARD=hi3516cv6xx_lite br-hisilicon-opensdk with firmware-side BR2_PACKAGE_HISILICON_OPENSDK_OVERRIDE_SRCDIR pointing at this PR's tree)
• Zero depmod warnings on install
• All 42 .ko files install to /lib/modules/5.10.221/extra/
• Modules load on real CV610 hardware via insmod with full paths
• Modules load on real CV610 hardware via modprobe (with buildroot-generated modules.dep)
• Full load_hisilicon -a -sensor0 sc4336p -sensor1 sc4336p chain completes
• CI matrix entry — adds in firmware companion PR cycle (see "CI status" above)
• End-to-end sysupgrade + cold boot — requires firmware companion PR with HISILICON_OPENSDK_VERSION bumped and PR #2170's CONFIG_IO_STRICT_DEVMEM=n
• majestic RTSP smoke test once sysupgrade lands

closes #180

[anatol]

Fantastic! Thank you very much for your work.

I see that a lot of *.o binaries has been merged. So I wondering what is the current policy and plans related to it. Do you plan eventually reimplement/recover it to a proper *.c linux driver?