hisilicon-opensdk: bump for the SC2235 DVP pad fix

[openipc-ai]

Problem

hi3516ev200 boards with an SC2235 on the DVP pads get no video. The sensor is on the
bus and answers, but no VI interrupts arrive — the stock driver sets the DVP pad enables
before the sensor starts streaming, and on at least one camera that leaves the SoC with
no pixel clock.

Change

Bumps HISILICON_OPENSDK_VERSION from 6eb7736a to c1f9eb5c — exactly one commit,
OpenIPC/openhisilicon#233, which
repeats the pad setup once the sensor is streaming (stronger drive on 0x3641) and starts
streaming again afterwards. It is a delta appended after the existing register table, not
a replacement, so no other register changes for any sensor.

This is what #2446's SC2235 sensor ini and IQ profile were waiting for, and what
OpenIPC/builder#160 needs before an Imou
Cue 2 image is worth publishing.

Blast radius

The bump reaches hi3516ev200 and gk7205v200 — libraries/sensor/gk7205v200 is a
symlink to hi3516ev200, so both families build the one file.

Nothing regresses on either, because nothing uses that sensor yet:

• no br-ext-chip-hisilicon or br-ext-chip-goke defconfig names sc2235
• no builder device sets fw_setenv sensor sc2235
• the two builder devices that mention it at all do so in exclusion lists, pruning
  libsns_sc2235.so to save flash

libsns_sc2235.so is built and shipped for these families only because sc2235 is in the
shared V4 sensor name list. The Cue 2 will be the first OpenIPC device to select it.

Hardware tested on

Not by me, and I want to be plain about that. There is no hi3516ev200 board in the lab —
the recorded DNS name still resolves but the address does not answer — so I have no camera
to exercise this on.

The evidence is the contributor's, on #2446 and #233: one Imou Cue 2 (IPC-C22EN), flashed
clean with kernel and rootfs and the overlay erased, giving video, both streams in Frigate,
night mode and two-way audio. The reason I am comfortable bumping on one camera's evidence
is the blast-radius section above — with no other board selecting this sensor, there is no
working configuration for the change to break.

Evidence

The bump is one line and the diff between the two openhisilicon commits is the linked PR:

$ git -C openhisilicon log --oneline 6eb7736..c1f9eb5
c1f9eb5 hi3516ev200/sc2235: repeat the DVP pad setup after stream start (#233)

Selector and self-test:

$ python3 .github/scripts/ci-matrix.py --self-test
ci-matrix: self-test ok (100 boards, 137 packages, 60 cases)

$ git diff --name-only master | python3 .github/scripts/ci-matrix.py --stdin
ci-matrix: 45/100 boards (needs_build=True) --- narrowed to the affected boards

45 boards build this package, so the matrix covers the families that actually consume it.

Scope

• No kernel patches under general/package/all-patches/linux/
• No files specific to a single retail camera model
• Package sources come from an OpenIPC repository, and the version bump keeps the full 40-character SHA of the pin it replaces
• No LD_PRELOAD, and no binaries that cannot be rebuilt from source

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Bump hisilicon-opensdk for the SC2235 DVP pad fix

🐞 Bug fix ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Pins openhisilicon to the commit fixing missing SC2235 video on DVP-connected hi3516ev200 cameras.
• The shared sensor library also reaches gk7205v200; no existing board selects SC2235.

Diagram

graph TD
  P["OpenSDK version pin"] --> U["openhisilicon source"] --> S["SC2235 library"] --> H["hi3516ev200 firmware"]
  S --> G["gk7205v200 firmware"]

Loading

High-Level Assessment

Pinning the single upstream fix is preferable to carrying a local patch: it preserves the existing source-build path without duplicating the driver change. Review should verify the upstream commit; hardware validation was reported by its contributor, not repeated for this PR.

Files changed (1) +1 / -1

Bug fix (1) +1 / -1

hisilicon-opensdk.mkPin openhisilicon to the SC2235 DVP fix +1/-1

Pin openhisilicon to the SC2235 DVP fix

• Changes the full 40-character source revision from 6eb7736a69121fda49f53656001426d2fe6a5030 to c1f9eb5c37db2500d4ec37b15c424e5f48a7a531. The new upstream commit repeats DVP pad setup after SC2235 stream start; the package recipe itself is otherwise unchanged.

general/package/hisilicon-opensdk/hisilicon-opensdk.mk

[qodo-free-for-open-source-projects]

Code Review by Qodo

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

1. Affected cameras remain unverified 📘 Rule violation ☼ Reliability

Description

HISILICON_OPENSDK_VERSION changes the SDK revision used to build the camera image, including
sensor and DVP behavior. Because the PR states that no affected board was tested on real hardware,
video and boot behavior remain unverified for the hi3516ev200 and gk7205v200 families reached by
this package.

Code

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

+HISILICON_OPENSDK_VERSION = c1f9eb5c37db2500d4ec37b15c424e5f48a7a531

Evidence

The checklist requires real-board evidence for image changes that can alter camera behavior. The
changed SDK pin is consumed when building the firmware, while the PR description explicitly states
that no hi3516ev200 board was available for hardware testing.

Rule 3: Hardware evidence is present and honest
general/package/hisilicon-opensdk/hisilicon-opensdk.mk[8-8]

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 SDK revision changes firmware behavior for camera sensor and DVP handling, but the PR states that no affected board was tested on hardware.
## Fix Focus Areas
- general/package/hisilicon-opensdk/hisilicon-opensdk.mk[8-8]
## Recommended Fix
Exercise an affected `hi3516ev200` or `gk7205v200` camera with the new image and record observable boot and video results, including the SC2235 stream behavior, before merging.

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

---

Tip of the day

💡 Did you know, you can turn on the rule miner and Qodo learns your standards from review history

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗