Skip to content

gk7205v500: install the sc223a sensor driver, whose config already ships - #2436

Merged
openipc-ai merged 1 commit into
masterfrom
gk7205v500-sensor-sc223a
Sep 17, 2026
Merged

openipc-ai merged 1 commit into
masterfrom
gk7205v500-sensor-sc223a

Conversation

@openipc-ai

@openipc-ai openipc-ai commented Sep 17, 2026 •

Copy link
Copy Markdown
Collaborator

Problem

A GK7205V500 / GK7202V500 whose sensor is an SC223A has no video on any
image this tree builds, however it is configured.

The sensor's configuration already ships: the package installs
files/sensor/config/*.ini wholesale, so /etc/sensors gets
sc223a_i2c_1080p.ini. But majestic on this family loads its sensor driver by
dlopening /usr/lib/sensors/libsns_<name>.so, and of the ~50 drivers the
package carries, only sc2336 and sc401ai had their install lines
uncommented. So the configuration half of this sensor shipped and the code half
did not.

What this does not fix, said plainly: the four-lane
4l_sc223a_i2c_1080p.ini sitting beside it names DllFile=libsns_sc223a_4l.so,
and the V500 SDK has no such file in any flavour — shared or static, lib_log
or lib_nolog. It is not alone: six of the fifteen configs this package ships
name a driver that is not in the package.

config                              DllFile                    in package?
4l_sc223a_i2c_1080p.ini             libsns_sc223a_4l.so        NO
jxf23_i2c_1080p.ini                 libsns_f23.so              NO
jxf23_i2c_dc_1080p.ini              libsns_f23_dc.so           NO
mis2008_i2c_1080p.ini               libsns_mis2008.so          NO
sc200ai_i2c_1080p.ini               libsns_sc200ai.so          NO
sc2232h_i2c_1080p.ini               libsns_sc2232h.so          NO
sc223a_i2c_1080p.ini                libsns_sc223a.so           yes  <- this PR

That set was evidently inherited with the config set from a family whose SDK
had those drivers (goke-osdrv-gk7205v200 does ship libsns_sc223a_4l.so).
Pruning them is a separate question from shipping the driver the two-lane
config asks for, so this PR records it rather than widening.

Additive — the sensor is already in the list the package builds, which is the
shape CLAUDE.md's "Add a sensor to an SoC family" asks for. No default is
repointed and no existing install changes.

Worth recording for the next report, because it cost a round trip here:
SC223A is sold as SC5239S, and SC223A / SC2239P / SC233A are one die
wearing three labels — ipctool's src/sensors.c says the latter, the wiki's
guide-supported-sensors.md the former. A reporter quoting their seller will
say "SC5239S", not "sc223a".

Reported on a GK7202V500 in #2428, where the board's own prompt read
gk7205v500-unknown until the sensor was set by hand.

Hardware tested on

No physical camera. I do not have a GK7205V500/GK7202V500 board, and say so
rather than leaving the section blank. The reporter of #2428 has one with this
exact sensor.

What can be checked without hardware, and was: that the driver is installed by
the build, that it is the file majestic looks for, that it loads, and that the
image still fits. What cannot: that the ISP brings this sensor up and streams.
QEMU models no sensor on this machine, so that half is the reporter's.

Evidence

Before — openipc.gk7205v500-nor-ultimate.tgz built from master:

# ls /usr/lib/sensors/
libsns_sc2336.so   libsns_sc401ai.so
# ls /etc/sensors/ | grep sc223a
4l_sc223a_i2c_1080p.ini
sc223a_i2c_1080p.ini

The config is there, the driver majestic would dlopen is not.

After — built from this branch:

# ls -la /usr/lib/sensors/
-rw-r--r-- 1 root root 38932 libsns_sc223a.so
-rw-r--r-- 1 root root 26472 libsns_sc2336.so
-rw-r--r-- 1 root root 31104 libsns_sc401ai.so

It resolves completely against the image it ships on — 19 undefined symbols,
none unresolved, and libc.so its only NEEDED — so the dlopen will not
fail the way the missing libhi_* shims did in #2434:

libsns_sc223a.so: 19 undefined, 0 unresolved on the built image
NEEDED: [libc.so]

Size, +12KB compressed and 1316KB still free under the cap:

                        master          this branch
- rootfs.squashfs:   [6864KB/8192KB]  [6876KB/8192KB]
- uImage:            [1896KB/2048KB]  [1896KB/2048KB]
- rootfs.ubi:       [13312KB/16384KB] [13312KB/16384KB]

Scope

  • No kernel patches under general/package/all-patches/linux/
  • No files specific to a single retail camera model — this is a sensor the SoC family supports, not a board
  • No probing or bring-up tooling
  • Nothing under general/overlay/ or in a shared load_<vendor> script hardcodes a value specific to my board — no load_goke default is repointed; this only adds to the package's sensor list
  • Package sources come from an OpenIPC repository, and any version bump keeps at least the specificity of the pin it replaces
  • No LD_PRELOAD, and no binaries that cannot be rebuilt from source — libsns_sc223a.so is already in this package's files/sensor/, from the same vendor SDK drop as its siblings; this PR adds no file, only an install line
  • New code is selected by a defconfig, so CI actually builds it

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

Copy link
Copy Markdown

PR Summary by Qodo

Install SC223A sensor driver in GK7205V500 images

🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 10 minutes

Grey Divider

AI Description

• Install the existing SC223A driver alongside configurations already included in GK7205V500 images.
• Restore video support for SC223A-compatible sensors, including SC5239S-labeled hardware.
• Document equivalent sensor names to simplify future hardware identification.
Diagram

graph TD
  A["Build Package"] -->|installs| B["Sensor Config"] -->|read by| C["Majestic"] -->|dlopen| D["SC223A Driver"] -->|initializes| E["SC223A Sensor"]
Loading
High-Level Assessment

The additive package install is the appropriate approach because the driver binary and matching configurations already exist, and Majestic expects this exact library path. Installing every bundled sensor driver would unnecessarily consume constrained image space, while changing defaults or adding detection logic would broaden scope and risk existing boards.

Files changed (1) +7 / -1

Bug fix (1) +7 / -1
goke-osdrv-gk7205v500.mkInstall the existing SC223A sensor driver +7/-1

Install the existing SC223A sensor driver

• Enables installation of libsns_sc223a.so into /usr/lib/sensors so Majestic can load the driver referenced by existing SC223A configurations. Adds context documenting the SC223A, SC2239P, SC233A, and SC5239S naming aliases and the missing-driver failure.

general/package/goke-osdrv-gk7205v500/goke-osdrv-gk7205v500.mk

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

qodo-free-for-open-source-projects Bot commented Sep 17, 2026 •

Copy link
Copy Markdown

Code Review by Qodo

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

Grey Divider


Action required

1. SC223A cameras lack real-device validation 📘 Rule violation ☼ Reliability
Description
The added libsns_sc223a.so installation changes the firmware's camera behavior without validation
on a real GK7205V500 or GK7202V500 camera. The PR explicitly states that no physical camera was
available, so CI and image inspection cannot establish that the sensor initializes and streams
successfully.
Code

general/package/goke-osdrv-gk7205v500/goke-osdrv-gk7205v500.mk[R128-134]

+	# SC223A is the die behind the SC5239S these boards are sold with, and the
+	# SC2239P and SC233A labels too -- one part, several names, which is why the
+	# sensor the seller advertises is not the one the driver is called after.
+	# Its two configs (sc223a_i2c_1080p.ini, 4l_sc223a_i2c_1080p.ini) already
+	# ship; only the driver majestic dlopens from /usr/lib/sensors was missing,
+	# so a camera with this sensor had no video however it was configured. #2428.
+	$(INSTALL) -m 644 -t $(TARGET_DIR)/usr/lib/sensors $(GOKE_OSDRV_GK7205V500_PKGDIR)/files/sensor/libsns_sc223a.so
Evidence
The compliance rule requires real-camera evidence for firmware changes that can alter camera
behavior and explicitly fails PRs that state the change was not tested on hardware. The changed
install command places the sensor driver into the image, while the PR description says no physical
camera was available and that sensor bring-up and streaming could not be verified.

Rule 1: Hardware evidence is present and honest
general/package/goke-osdrv-gk7205v500/goke-osdrv-gk7205v500.mk[128-134]

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 installs the SC223A sensor driver, which can change camera behavior, but the description states that no physical GK7205V500 or GK7202V500 camera was available for validation. The compliance gate requires real-device evidence for firmware changes that can affect camera behavior.
## Fix Focus Areas
- general/package/goke-osdrv-gk7205v500/goke-osdrv-gk7205v500.mk[128-134]
## Recommended Fix
Test the resulting image on an affected GK7205V500 or GK7202V500 camera with an SC223A-compatible sensor, and add before/after or post-change evidence showing driver loading, sensor initialization, and successful video streaming. If no hardware can be tested, obtain and include evidence from the reporter's matching board before merging.

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


2. The four-lane SC223A configuration still cannot load 🐞 Bug ≡ Correctness
Description
The new install rule copies only libsns_sc223a.so, while 4l_sc223a_i2c_1080p.ini requests
libsns_sc223a_4l.so. Any camera selecting that shipped four-lane configuration still fails the
sensor driver's dlopen and has no video, despite the PR's claim that both SC223A configurations
are supported.
Code

general/package/goke-osdrv-gk7205v500/goke-osdrv-gk7205v500.mk[134]

+	$(INSTALL) -m 644 -t $(TARGET_DIR)/usr/lib/sensors $(GOKE_OSDRV_GK7205V500_PKGDIR)/files/sensor/libsns_sc223a.so
Evidence
The changed install command adds only the non-4-lane library. The shipped four-lane configuration
explicitly sets DllFile=libsns_sc223a_4l.so, and the package directory contains no corresponding
libsns_sc223a_4l.so; the analogous GK7205V200 package separately installs that library, confirming
the names represent distinct required files.

general/package/goke-osdrv-gk7205v500/goke-osdrv-gk7205v500.mk[128-134]
general/package/goke-osdrv-gk7205v500/files/sensor/config/4l_sc223a_i2c_1080p.ini[1-4]
general/package/goke-osdrv-gk7205v200/goke-osdrv-gk7205v200.mk[58-64]

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 package installs `libsns_sc223a.so`, but the shipped `4l_sc223a_i2c_1080p.ini` configuration names `libsns_sc223a_4l.so`, which is absent from the GK7205V500 sensor directory. Cameras using that configuration still fail to load the sensor driver.
## Fix Focus Areas
- general/package/goke-osdrv-gk7205v500/goke-osdrv-gk7205v500.mk[134-134]
- general/package/goke-osdrv-gk7205v500/files/sensor/config/4l_sc223a_i2c_1080p.ini[1-4]
- general/package/goke-osdrv-gk7205v500/files/sensor/
## Recommended Fix
Install the matching `libsns_sc223a_4l.so` file alongside `libsns_sc223a.so` if that vendor driver is available in the package sources. If no matching library exists, do not claim the four-lane configuration is supported; instead remove or correct that configuration through the appropriate source change and verify every shipped SC223A config names an installed library.

ⓘ 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 enable the Remediation agent and Qodo fixes findings in a dedicated fix PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Grey Divider

Qodo Logo

Comment thread general/package/goke-osdrv-gk7205v500/goke-osdrv-gk7205v500.mk
Comment thread general/package/goke-osdrv-gk7205v500/goke-osdrv-gk7205v500.mk
@openipc-ai
openipc-ai force-pushed the gk7205v500-sensor-sc223a branch from ec49940 to 50c464b Compare September 17, 2026 17:31
@openipc-ai openipc-ai changed the title gk7205v500: install the sc223a sensor driver, whose configs already ship gk7205v500: install the sc223a sensor driver, whose config already ships Sep 17, 2026
A GK7202V500 whose sensor is an SC223A has no video on any image this tree
builds. /etc/sensors gets sc223a_i2c_1080p.ini already -- the package installs
files/sensor/config/*.ini wholesale -- but majestic on this family dlopens
/usr/lib/sensors/libsns_<name>.so, and of the fifty drivers the package
carries only sc2336 and sc401ai were uncommented. So the configuration half of
the sensor shipped and the code half did not.

Additive, and the sensor is in the list the package already builds, per
CLAUDE.md's "Add a sensor to an SoC family". 39000 bytes uncompressed, 12KB
compressed, and the board has 1316KB of headroom under its 8192KB cap.

This does not make the four-lane 4l_sc223a_i2c_1080p.ini work: that config
names libsns_sc223a_4l.so, which the V500 SDK does not contain in any flavour
-- static or shared, log or nolog. It is one of six configs in this package
naming a driver that is not here (jxf23, jxf23_dc, mis2008, sc200ai, sc2232h
are the others), evidently inherited with the config set from a family whose
SDK had them. Pruning those is a separate question from shipping this driver,
so the comment records it rather than widening this change.

Worth knowing for the next report: SC223A, SC2239P and SC233A are one die
wearing three labels, and it is sold as SC5239S -- ipctool's sensors.c says the
first, the wiki's guide-supported-sensors.md the second. A reporter quoting
their seller will not say "sc223a".

Reported on a GK7202V500 in #2428.
@openipc-ai
openipc-ai force-pushed the gk7205v500-sensor-sc223a branch from 50c464b to b9c4b3f Compare September 17, 2026 19:05
@openipc-ai
openipc-ai merged commit 839b990 into master Sep 17, 2026
27 checks passed
@openipc-ai
openipc-ai deleted the gk7205v500-sensor-sc223a branch September 17, 2026 19:31
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