Add hi3516cv200_lite_spezvision-svi-252b-k202 device profile (SpezVis… - #161
openipc-ai merged 2 commits into
Conversation
…ion SVI-252B K202, IMX323)
PR Summary by QodoAdd SpezVision SVI-252B K202 HI3516CV200 device profile
AI Description
Diagram
High-Level Assessment
Files changed (7)
|
Code Review by Qodo🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)
Great, no issues found!Qodo reviewed your code and found no material issues that require reviewTip of the day💡 Did you know, you can describe a rule in plain language on the Rules page and Qodo drafts it for you |
rootfs_script.sh tests every entry with [ -e "${TARGET_DIR}${entry}" ] against
the literal string, so a path containing a glob never expands and never deletes
anything. Both lines came across from the sibling hi3516cv200_lite list:
/lib/modules/4.9.37/kernel/drivers/staging/*/*.ko
/lib/modules/4.9.37/kernel/fs/f2fs/*.ko
Neither has a live target on this board in any case. hi3516cv200.generic.config
carries "# CONFIG_F2FS_FS is not set", and the one staging module that would
otherwise be built here is r8188eu, which this device's kernel fragment already
switches off at CONFIG_R8188EU.
Left in, every build of this device would print "excludes: 2 of 72 entries in
hi3516cv200_lite.list matched no file" — the same permanently-on warning OpenIPC#155
cleared out of five hi3518ev200_lite lists. That warning is how a stale exclude
gets noticed, so it should not be on by default.
openipc-ai
left a comment
openipc-ai
left a comment
There was a problem hiding this comment.
Reviewed against hi3516cv200_lite_trassir-tr-d4121ir1-v2 (the only other Hi3516CV200 lite profile) and against what the firmware packages actually install. This is a careful profile — a few notes on what I checked, and one thing I pushed to the branch.
Exclude list. I walked it against the real install set rather than against the sibling's list, since the sibling's is itself incomplete. hisilicon-osdrv-hi3516cv200 installs 26 sensor .ini, 6 IQ .ini plus the default.ini -> ar0130.ini symlink, and 11 libsns_*.so plus the libsns_imx323_i2c_dc.so -> _v1.so symlink; hisilicon-opensdk adds 18 more .so for this family plus the libsns_ov2710_dc/_mipi symlinks. Your list removes every one of those except imx323_i2c_dc_1080p.ini, libsns_imx323_i2c_dc_v1.so and its symlink — which is exactly what the DllFile line in that .ini points at. ircut_demo, ir.ko, hi_rtc.ko and piris.ko are all genuinely installed for CV200 (ir.ko/piris.ko come from opensdk, not osdrv), so those four entries are live too. Emptying /etc/sensors/iq/ including the default.ini symlink matches what hi3518ev200_lite_switcam-hs303 and gk7202v300_lite_ipg-g3-wr already do.
Two entries could never match, so I pushed b177412 removing them:
/lib/modules/4.9.37/kernel/drivers/staging/*/*.ko
/lib/modules/4.9.37/kernel/fs/f2fs/*.ko
general/scripts/rootfs_script.sh tests [ -e "${TARGET_DIR}${entry}" ] on the literal string, so a glob never expands. They are dead on their own terms here as well — hi3516cv200.generic.config has # CONFIG_F2FS_FS is not set, and the one staging module that would otherwise be built is r8188eu, which your fragment already turns off at CONFIG_R8188EU. Left in they would print excludes: 2 of 72 entries ... matched no file on every build, the same permanently-on warning #155 cleared out of five other lists. They came across from the sibling; no fault of the port.
Kernel fragment. Nice — this is the first device here to use BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES instead of forking the whole 60 KB hi3516cv200.generic.config into the device directory the way the sibling does, so it cannot go stale against upstream. All 27 symbols exist and are enabled in the generic config, so every line does work; Buildroot 2024.02.10's merge_config.sh recognises the # CONFIG_X is not set form; and $(EXTERNAL_VENDOR) resolves through general/external.mk the same way the CUSTOM_CONFIG_FILE line above it does. The NOR path (CONFIG_MTD_SPI_NOR, CONFIG_SPI_HISI_SFC) is untouched by the NAND lines.
Runtime. muxes.sh is the right hook — S30customizer runs it unconditionally on every boot, devmem is in the busybox config, and mode 644 is fine since it is invoked as sh …. load_hisilicon's imx323) branch muxes I2C0 and the VI pads but never touches 0x200f0034, so nothing fights your GPIO3_0 setting. fw_setenv sensor imx323 is read back by rcS and S31hostname. Every cli -s path is a setting majestic actually carries — lightSensorInvert included, it ships in the stock /etc/majestic.yaml under nightMode: with a default of false — and lint-cli-paths.py is happy with the shapes.
Registration. ci-matrix.py --self-test passes at 116 devices and the diff narrows the build to this device alone. The upgrade URL filename matches what CI renames the artifact to, the exclude list keeps the <soc>_<flavor>.list name, and the README row is in sort order with the columns aligned.
Nothing else from me. Approving the workflow run now so we get a real build; the 8 MiB fit is the last open question and only the image can answer it.
openipc-ai
left a comment
openipc-ai
left a comment
There was a problem hiding this comment.
Build is green — 10 min, rootfs 3956736 B with 1256 KB of headroom on the 8 MiB layout and 524 KB left on the kernel, and no stale entries left in the exclude list (114 files removed, nothing reported as unmatched). Tested on hardware by the author, verified against the packages here. Merging.
2 participants
Adds a device profile for the SpezVision SVI-252B K202 — HiSilicon
HI3516CV200, Sony IMX323, 8 MiB SPI NOR, wired Ethernet only.
The board needs a few device-specific settings beyond the standard
HI3516CV200 lite configuration:
muxes.shselects GPIO mode for GPIO3_0 (0x200f0034 = 0) on everyboot, independently of the selected streamer.
fragment disables those unused subsystems.
backlightPinis configured because a separate software-controlledIR illuminator GPIO was not proven for this board.
Tested on a physical SpezVision SVI-252B K202: the firmware builds,
flashes and boots successfully; IMX323 video, Ethernet, the hardware
daylight sensor and automatic IR-cut switching are working.
One remaining visual quirk is outside the Builder profile: Majestic can
show a brief purple/magenta frame during the color-to-grayscale transition.
A configurable intra-transition delay is tracked in OpenIPC/majestic#325.
No board-specific workaround is included here.