Repository navigation
hi3516cv6xx: the CV2003, GC4653 and VS4388, wired to the second MIPI port - #2722
Merged
Merged
Conversation
…port Three CV610/CV608 cameras from one vendor (OpenIPC/majestic#355, #356, #357) had no picture on OpenIPC: no driver for their sensors, and the sensor on a MIPI port nothing here could use. Their drivers are now in openhisilicon (the pin moves to 6e6729a1a): CV2003, GC4653 and VS4388, each written from that vendor's own firmware, with the sensor clock in sys_config (24, 27 and 24 MHz). majestic takes the port from the profile. All three boards wire the sensor the same way, which the owner confirmed and the stock umap shows: the second MIPI port in 2+2 mode, lanes 1 and 3, clock on the second clock lane, into VI device 1. The profiles say so -- devno 1, lane_divide_mode 1, lane_id 1|3 -- and RGGB, RAW10, linear: cv2003_i2c_1080p.ini 1920x1080p30, 2400 lines gc4653_i2c_4M.ini 2560x1440p30, 1501 lines vs4388_i2c_4M.ini 2560x1440p30, 1482 lines These are 8 MB boards, so the drivers and profiles ship on lite as well as ultimate. hi3516cv6xx_lite stays inside its cap: firmware.bin 7360 KB of 7616 KB, uImage 2021 KB of 2048 KB. ipcinfo names the sensors cv2003, gc4653 and vs4388 -- the VS4388 at 0x6c since OpenIPC/ipctool#256 -- and those are the names load_hisilicon hands sys_config and majestic looks the profiles up by.
widgetii
requested review from
cronyx,
flyrouter and
viktorxda
as code owners
October 29, 2026 05:38
PR Summary by QodoEnable three Hi3516CV6xx sensors on the second MIPI port
AI Description
Diagram
High-Level Assessment
Files changed (5)
|
Code Review by Qodo
1. New camera support lacks hardware proof
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
This was referenced Oct 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three CV610/CV608 cameras from one vendor had no picture on OpenIPC: OpenIPC/majestic#355 (CV2003), #356 (GC4653) and #357 (VS4388). There were two causes:
What this ships
openhisilicon pin
b0d848e→6e6729a1a, which brings:Each driver was written from that vendor's own firmware: its init tables and its exposure, gain and frame-length registers, limits and sync order.
Three profiles, installed on lite and ultimate, since these are 8 MB boards:
cv2003_i2c_1080p.inigc4653_i2c_4M.inivs4388_i2c_4M.iniWiring
All three boards wire the sensor the same way: the second MIPI port in 2+2 mode, lanes 1 and 3, clock on the second clock lane, into VI device 1. The stock umap shows it, and the owner confirmed it for all three. The profiles express that as
devno = 1,lane_divide_mode = 1,lane_id = 1|3. majestic reads these keys, and the VI device followsdevno.sys_configalready muxesMIPI_RX0_CK1N/Pto MIPI with the same0x1430the vendor firmware uses, so the second clock lane reaches the receiver.Naming
ipcinfo --short-sensorreportscv2003,gc4653andvs4388; the VS4388 is found at0x6csince OpenIPC/ipctool#256, and ipctool is built from HEAD.load_hisiliconstores that name and hands it toopen_sys_config, which picks the clock by it. majestic finds each profile by the same name.Checked
Local builds
hi3516cv6xx_lite:firmware.bin7360 KB of 7616 KB, uImage 2021 KB of 2048 KB.hi3516cv6xx_ultimate: 9408 KB of 15808 KB, uImage 2029 KB./usr/lib/sensors/libsns_{cv2003,gc4653,vs4388}.soand the three profiles in/etc/sensors.On a Hi3516CV608 (ultimate, split NOR, SP2308 sensor on port 0). It has none of the three new sensors. What it does show is that the image upgrades, boots, and leaves an existing cv6xx board unchanged. The ultimate image was flashed with this tree's
sysupgrade1.0.80:local-20261028-build)local-20261029-build)firmware.binwritten and read back in 2m12s, settings staged at0x980000, bootsipcinfo --short-sensor/fw_printenv sensorsp2308/sp2308sp2308/sp2308/etc/sensorscv2003_i2c_1080p.ini,gc4653_i2c_4M.ini,vs4388_i2c_4M.ini/usr/lib/sensorslibsns_cv2003.so,libsns_gc4653.so,libsns_vs4388.soopen_sys_config.koin the image (/rom)cv2003,gc4653,vs4388; md5 matches the build/Not yet tested: none of the three new sensors has been run, because no CV2003, GC4653 or VS4388 board is available here. These go into the nightly so the owner of the three cameras (majestic#355/#356/#357) can test them; the issues ask for umap, logs and a picture.