Skip to content

hisilicon-opensdk: bump to 963f7e9, GC2083 on hi3516cv6xx - #2577

Merged
openipc-ai merged 2 commits into
masterfrom
opensdk-gc2083-cv6xx
Oct 13, 2026
Merged

openipc-ai merged 2 commits into
masterfrom
opensdk-gc2083-cv6xx

Conversation

@openipc-ai

@openipc-ai openipc-ai commented Oct 12, 2026 •

Copy link
Copy Markdown
Collaborator
  • hisilicon-opensdk: bump to 963f7e9 (sensor: add gc2083 for hi3516cv6xx (#260) openhisilicon#261) and build libsns_gc2083 for hi3516cv6xx. The library carries the vendor driver's ISP tables, the vendor scene INI's colour tuning, and the 0x400 black level that fixes the magenta cast. sys_config clocks the sensor at 27 MHz, and ipctool already detects it (chip 0x2083).
  • hisilicon-osdrv-hi3516cv6xx: load_hisilicon now gives open_sys_config the sensor this boot resolved (-sensor0 / the sensor env / the probe). Until now insert_ko passed the hard-coded sc4336p default unless -sensor0 was given, and S70vendor never passes it. So every cv6xx camera got sc4336p's clock and interface: 27 MHz for an OS04D10 that needs 24, and MIPI for a BT656/BT1120 source. Explicit -sensor0 / -sensor1 still win. gc2083 is also listed among the source-built sensors and in the usage text.

The bump also brings in OpenIPC/openhisilicon#259, which is docs only.

Testing: the library cross-compiles warning-free and passed openhisilicon's CI. load_hisilicon passes busybox sh -n, and its sensor selection was checked for the no-flag, -sensor0 and -sensor0 -sensor1 cases. Nothing has run on a camera yet: we have no Hi3516CV610 board, and the reporter is testing an H2-52PGX in OpenIPC/openhisilicon#260. Board-specific power, I2C bus and MIPI setup for that board are not part of this PR.

@openipc-ai

Copy link
Copy Markdown
Collaborator Author

/review

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented Oct 12, 2026 •

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

Grey Divider


Action required

1. New sensor support lacks camera evidence 📘 Rule violation ☼ Reliability
Description
HISILICON_OPENSDK_SENSORS_hi3516cv6xx now builds and ships libsns_gc2083, and load_usage()
advertises it. Because this changes the sensor set used by Hi3516CV6xx images, the stated absence of
an H2-52PGX/Hi3516CV610 boot and stream result leaves the camera behavior unverified.
Code

general/package/hisilicon-opensdk/hisilicon-opensdk.mk[245]

+	galaxycore_gc2083/libsns_gc2083 \
Evidence
The changed sensor list causes the Hi3516CV6xx image to build the new GC2083 sensor library, and the
changed loader usage text exposes that support. The PR description states that the library has not
yet been verified on a camera, which violates the hardware-evidence requirement for firmware
behavior changes.

Rule 3: Hardware evidence is present and honest
general/package/hisilicon-opensdk/hisilicon-opensdk.mk[245-245]
general/package/hisilicon-osdrv-hi3516cv6xx/files/script/load_hisilicon[216-216]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR adds GC2083 support to a camera image but explicitly reports that it has not been verified on hardware. The hardware-evidence gate requires a real affected-board result for image-affecting changes.
## Fix Focus Areas
- general/package/hisilicon-opensdk/hisilicon-opensdk.mk[245-245]
- general/package/hisilicon-osdrv-hi3516cv6xx/files/script/load_hisilicon[216-216]
## Recommended Fix
Test the affected Hi3516CV610/H2-52PGX camera with the new image and document before/after evidence including boot output, sensor detection, and stream behavior; otherwise provide the applicable selector or self-test evidence and clearly document the remaining hardware limitation.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. GC2083 boots with the wrong sensor setup ✓ Resolved
Description
load_hisilicon leaves SNS_TYPE0=sc4336p unless -sensor0 is passed, and insert_ko gives that
value to open_sys_config rather than using the detected SENSOR=gc2083. On a normal boot,
S70vendor calls load_hisilicon -i without that flag, so the newly included GC2083 library is
paired with the sc4336p kernel sensor configuration.
Code

general/package/hisilicon-osdrv-hi3516cv6xx/files/script/load_hisilicon[216]

+	echo -e "Available sensors:sc4336p gc2083 gc4023 sc450ai sc500ai sc431hai os04d10 imx307 os02m10 bt1120/bt656/bt601"
Evidence
The startup script passes no sensor argument, although that argument is the only path that changes
SNS_TYPE0. The newly advertised sensor can therefore be present in SENSOR while module insertion
still selects sc4336p.

general/overlay/etc/init.d/rcS[1-2]
general/overlay/etc/init.d/S70vendor[3-8]
general/package/hisilicon-osdrv-hi3516cv6xx/files/script/load_hisilicon[5-7]
general/package/hisilicon-osdrv-hi3516cv6xx/files/script/load_hisilicon[118-120]
general/package/hisilicon-osdrv-hi3516cv6xx/files/script/load_hisilicon[247-253]
general/package/hisilicon-osdrv-hi3516cv6xx/files/script/load_hisilicon[346-390]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
GC2083 is now advertised and built, but normal startup initializes `open_sys_config` for sc4336p because the detected sensor does not update `SNS_TYPE0`.
## Fix Focus Areas
- general/package/hisilicon-osdrv-hi3516cv6xx/files/script/load_hisilicon[5-7]
- general/package/hisilicon-osdrv-hi3516cv6xx/files/script/load_hisilicon[346-390]
- general/overlay/etc/init.d/S70vendor[4-8]
## Recommended Fix
After resolving `SENSOR` from the environment or probe, use it as the primary sensor type before `insert_ko`, while preserving explicit sensor arguments and avoiding a GC2083 default for other cameras.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Tip of the day
💡 Did you know, you can turn these tips off under Display > Comment parts

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Grey Divider

Qodo Logo

Comment thread general/package/hisilicon-opensdk/hisilicon-opensdk.mk
- hisilicon-opensdk: bump to 963f7e9 and build libsns_gc2083 for
  hi3516cv6xx (OpenIPC/openhisilicon#261), with the vendor's ISP tables,
  its colour tuning and the 0x400 black level. sys_config clocks the
  sensor at 27 MHz; ipctool already detects it (chip 0x2083).
- hisilicon-osdrv-hi3516cv6xx: list gc2083 among the source-built
  sensors and in load_hisilicon's usage text.

Not yet verified on hardware: OpenIPC/openhisilicon#260.
… resolved

insert_ko passed SNS_TYPE0/1 to open_sys_config, and those only change
with -sensor0/-sensor1, which S70vendor never passes. Every cv6xx camera
was therefore configured as sc4336p whatever was detected or stored in
the environment. sys_config takes the sensor clock and the MIPI/BT
interface from that name, so an OS04D10 got 27 MHz instead of 24 and a
BT656/BT1120 source was set up as MIPI. Use the resolved SENSOR unless a
flag named one, as the ev200 script does.
@openipc-ai
openipc-ai force-pushed the opensdk-gc2083-cv6xx branch from 3366992 to 0615833 Compare October 13, 2026 17:35
@openipc-ai
openipc-ai merged commit f1dbdb8 into master Oct 13, 2026
82 of 83 checks passed
@openipc-ai
openipc-ai deleted the opensdk-gc2083-cv6xx branch October 13, 2026 18:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant