Skip to content

hisilicon-opensdk: wire up hi3519v101 open_ modules into firmware - #2010

Merged
widgetii merged 1 commit into
masterfrom
feat/3519v101-opensdk-modules
Apr 16, 2026
Merged

hisilicon-opensdk: wire up hi3519v101 open_ modules into firmware#2010
widgetii merged 1 commit into
masterfrom
feat/3519v101-opensdk-modules

Conversation

@widgetii

@widgetii widgetii commented Apr 16, 2026

Copy link
Copy Markdown
Member

Summary

Add V3A (hi3519v101) support — fifth platform after CV200, CV100, AV100, CV500.

hi3519v101 has OSAL (source-compiled) like CV500, so blobs call osal_* wrappers. Zero code fixes needed in openhisilicon — only firmware wiring.

  • Install block with vendor names in /lib/modules/3.18.20/hisilicon/
  • Blob prefix: hi3519v101_*, source prefix: hi_*
  • 38 modules installed
  • Image fits lite flash (5048KB < 5120KB)
  • Also enables opensdk for hi3516av200 (same SOC_FAMILY)
  • Builds and installs IMX385 sensor library from source (supersedes hisilicon-opensdk: build IMX385 sensor from source for hi3519v101 #2013)

Test plan

  • make BOARD=hi3519v101_lite all builds successfully
  • make BOARD=hi3516av200_lite all builds successfully (4508KB < 5120KB)
  • 38 modules installed with correct vendor names
  • Zero depmod warnings (except pre-existing PCIe)
  • extra/ cleaned
  • Hardware tested on hi3516av200 (NAND, IMX385 sensor, 256MB RAM)
  • All modules load on boot via load_hisilicon
  • /dev/hi_mipi created, sensor library loaded
  • HiSilicon SDK started, JPEG snapshot captured (54KB)
  • CI passes

🤖 Generated with Claude Code

Add V3A (hi3519v101) support — same pattern as CV500.
hi3519v101 has OSAL (source-compiled), so blobs call osal_* wrappers
and no code fixes were needed in openhisilicon.

Key details:
- Kernel 3.18.20 (module path /lib/modules/3.18.20/hisilicon/)
- Blob prefix: hi3519v101_*, source prefix: hi_*
- 38 modules installed with vendor-compatible names
- Image fits lite flash (5048KB < 5120KB)

Also enables opensdk for hi3516av200 (same SOC_FAMILY=hi3519v101).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@widgetii
widgetii force-pushed the feat/3519v101-opensdk-modules branch from d92c9a8 to c30265e Compare April 16, 2026 14:23
@widgetii
widgetii merged commit 26ab278 into master Apr 16, 2026
88 checks passed
widgetii added a commit that referenced this pull request Jun 19, 2026
In per-package mode, target-finalize merges per-package/*/target/ into
output/target/ via $(call per-package-rsync,$(sort $(PACKAGES)),...).
The $(sort ...) is alphabetical, so hisilicon-osdrv-* always rsyncs
after hisilicon-opensdk and clobbers any file we install at the same
path -- even though HISILICON_OPENSDK_DEPENDENCIES sequences us after
osdrv during build.

Net effect: every file opensdk and osdrv share a path for ends up as
the osdrv vendor blob in the shipped image. Verified on a hi3516av200
(hi3519v101 SDK) test camera:

- /usr/lib/sensors/libsns_imx385.so -- vendor blob (stSnsObj),
  not opensdk's source-built lib (stSnsImx385Obj). Majestic fails:
    sensor_getsnsobj@101 Cannot load symbol 'stSnsImx385Obj' from driver
    Cannot init sensor / Cannot start SDK
- /lib/modules/3.18.20/hisilicon/hi_mipi.ko -- vendor blob,
  not opensdk's open_mipi_rx.ko (so PR #2010's open kernel modules
  have been silently inactive on hi3519v101 since it landed).

Same trap exists for hi3516cv500 (imx335/307/415 + ~30 .ko files)
and hi3516ev200 (imx307).

Fix: register a TARGET_FINALIZE_HOOK that re-rsyncs opensdk's
per-package target tree onto output/target/ after buildroot's
alphabetical merge runs. Opensdk's per-package staging is already
"osdrv contents + opensdk overlay" (because of the existing
_DEPENDENCIES), so a plain rsync -a is exactly what we want
to apply on top.

Gated on BR2_PER_PACKAGE_DIRECTORIES=y; without per-package mode
install ordering already does the right thing.

Verified post-fix on the same camera: source-built libsns_imx385.so
loads, sensor inits ("-------Sony IMX385 Sensor 1080p30 Initial OK!-------"),
RTSP starts, /image.jpg returns a valid 1920x1080 JPEG.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
widgetii added a commit that referenced this pull request Jun 19, 2026
In per-package mode, target-finalize merges per-package/*/target/ into
output/target/ via $(call per-package-rsync,$(sort $(PACKAGES)),...).
The $(sort ...) is alphabetical, so hisilicon-osdrv-* always rsyncs
after hisilicon-opensdk and clobbers any file we install at the same
path -- even though HISILICON_OPENSDK_DEPENDENCIES sequences us after
osdrv during build.

Net effect: every file opensdk and osdrv share a path for ends up as
the osdrv vendor blob in the shipped image. Verified on a hi3516av200
(hi3519v101 SDK) test camera:

- /usr/lib/sensors/libsns_imx385.so -- vendor blob (stSnsObj),
  not opensdk's source-built lib (stSnsImx385Obj). Majestic fails:
    sensor_getsnsobj@101 Cannot load symbol 'stSnsImx385Obj' from driver
    Cannot init sensor / Cannot start SDK
- /lib/modules/3.18.20/hisilicon/hi_mipi.ko -- vendor blob,
  not opensdk's open_mipi_rx.ko (so PR #2010's open kernel modules
  have been silently inactive on hi3519v101 since it landed).

Same trap exists for hi3516cv500 (imx335/307/415 + ~30 .ko files)
and hi3516ev200 (imx307).

Fix: register a TARGET_FINALIZE_HOOK that re-rsyncs opensdk's
per-package target tree onto output/target/ after buildroot's
alphabetical merge runs. Opensdk's per-package staging is already
"osdrv contents + opensdk overlay" (because of the existing
_DEPENDENCIES), so a plain rsync -a is exactly what we want
to apply on top.

Gated on BR2_PER_PACKAGE_DIRECTORIES=y; without per-package mode
install ordering already does the right thing.

Verified post-fix on the same camera: source-built libsns_imx385.so
loads, sensor inits ("-------Sony IMX385 Sensor 1080p30 Initial OK!-------"),
RTSP starts, /image.jpg returns a valid 1920x1080 JPEG.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@widgetii
widgetii deleted the feat/3519v101-opensdk-modules branch June 19, 2026 12:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant