[openipc-ai]

Draft device for the D-Link DCS-2330L rev A, built from @garnser's findings in #216. Not yet flashed on hardware — this is for the reporter to test.

Depends on OpenIPC/firmware#2726 (merged) for the RTL8188EUS driver to compile on the 3.0.8 kernel.

SoC	Hi3518CV100 (hi3518cv100_lite, kernel 3.0.8)
Sensor	OV9712, DC 720p
Wi-Fi	RTL8188EU USB 0bda:8179
Flash	32M NOR (standard 8M lite image)

What it carries

• defconfig — firmware's hi3518cv100_lite with RTL8188EUS_OPENIPC in place of MT7601U.
• /etc/sensors/ov9712_i2c_dc_720p_dcs2330l.ini — the stock ini with Mask_0 = 0xFFC00000 (stock is 0x3FF00000), which the report found removes the green/purple highlight corruption. Board-only; the stock ini is left alone for other OV9712 cameras. Selected via .isp.sensorConfig in the customizer.
• /etc/wireless/usb — profile rtl8188eu-dlink-dcs-2330l: modprobe 8188eu rtw_power_mgnt=0 rtw_ips_mode=0 rtw_enusbss=0 (the options from the report; they only take effect on the modprobe line).
• customizer — IR-cut irCutPin1 0 with lightMonitor, h264 at 20 fps, wlandev, upgrade URL.
• /etc/init.d/S96irled — a shell replacement for the report's dcs2330-ir daemon: sets pad mux 0x200f0134/0x200f0138 to 0, then drives PWM2 (0x20130040..4c, period 150 = 20 kHz) at irled_duty percent (default 35, fw_setenv irled_duty N) while /sys/class/gpio/gpio0/value is 1, off otherwise. PWM1 (heater) is never touched.
• excludes — every sensor .ini/.so that isn't OV9712 (~690 KB uncompressed).

Deliberately left out: the dcs2330-image ISP helper (SDK struct offsets, mmap shim and unit-specific shading tables) and the scene-specific IQ/gain tuning — those remain optional local tweaks as the report suggests.

Verified

• Local ./builder.sh against the firmware branch: uImage 1821/1983 KB, rootfs 4800/5120 KB, all exclude entries matched; 8188eu.ko, both inis, S96irled and the wireless profile present in the rootfs.
• ci-matrix.py --self-test ok.

Reporter's component results (on their custom 3.0.8 install, not this image — see the comments)

• S96irled at bbd695b: default 35% → duty 53, 20%/35% via restart, stop disables PWM2, follows majestic's day/night on GPIO0. The octal irled_duty bug they found is fixed in 75f060d.
• Board INI matches their hardware-tested one key-for-key; it removes the highlight solarisation.
• Wi-Fi with the same driver/guards/options associates on their hand-built module. This image's module isn't tested yet.
• Kernel + rootfs for component testing: release test-dcs-2330l-75f060d.

Needs testing on the camera (@garnser)

1. How to get a standard OpenIPC image onto this unit (OpenIPC u-boot vs. the stock bootloader's loadbootaddr selector) — your install used a custom layout, so please keep your recovery path at hand.
2. Wi-Fi associates with wlandev rtl8188eu-dlink-dcs-2330l.
3. Video with the board ini, no green/purple highlights.
4. IR-cut switches, and the IR LEDs come on at night (/etc/init.d/S96irled stop/start; try fw_setenv irled_duty 20 etc.).

Refs #216

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

PR Summary by Qodo

Add draft D-Link DCS-2330L rev A firmware support

✨ Enhancement ⚙️ Configuration changes 📝 Documentation 🕐 20-40 Minutes

AI Description

• Add a Hi3518CV100 lite build with RTL8188EU Wi-Fi and board-specific OV9712 settings.
• Control IR LEDs through PWM2 while Majestic switches the IR-cut filter.
• Trim unused sensor files to fit the image; hardware flashing and validation remain outstanding.

Diagram

graph TD
  D["Device defconfig"] --> B["Lite image"] --> C["Board customizer"] --> M["Majestic"]
  C --> S["OV9712 config"] --> M
  C --> W["Wi-Fi profile"]
  M -->|"GPIO0 night state"| I["IR LED script"] --> P["PWM2 LEDs"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Kernel PWM interface

• ➕ Avoids direct register writes from a polling shell script.
• ➖ Requires confirming PWM driver support on the 3.0.8 kernel and adds kernel-side work before hardware validation.

Recommendation: Keep the board-local configuration and small PWM2 script for this test build rather than changing the shared OV9712 profile or adding kernel support now. Validate boot layout, video, Wi-Fi and day/night behavior on hardware before treating the device as supported.

Files changed (7) +333 / -0

Enhancement (1) +59 / -0

S96irledDrive board IR LEDs from GPIO0 night state +59/-0

Drive board IR LEDs from GPIO0 night state

• Adds an init script that restores pad mux settings and polls the IR-cut GPIO to enable or disable PWM2. Its default 35% duty cycle can be set with the irled_duty environment variable; PWM1 is left untouched.

devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled

Documentation (1) +1 / -0

README.mdList DCS-2330L rev A as awaiting hardware testing +1/-0

List DCS-2330L rev A as awaiting hardware testing

• Adds the camera’s SoC, sensor, USB Wi-Fi and flash details to the device table. Marks the image as not yet flashed.

README.md

Other (5) +273 / -0

hi3518cv100_lite_dlink-dcs-2330l_defconfigDefine the Hi3518CV100 lite firmware build +67/-0

Define the Hi3518CV100 lite firmware build

• Adds a device defconfig using the 3.0-kernel HiSilicon lite setup and an 8 MB image target. Selects RTL8188EU firmware and the RTL8188EUS driver in place of the generic image’s MT7601U support.

devices/hi3518cv100_lite_dlink-dcs-2330l/br-ext-chip-hisilicon/configs/hi3518cv100_lite_dlink-dcs-2330l_defconfig

ov9712_i2c_dc_720p_dcs2330l.iniAdd a board-specific OV9712 capture profile +121/-0

Add a board-specific OV9712 capture profile

• Adds a 720p OV9712 profile with Mask_0 set to 0xFFC00000 for this board’s VI wiring. Keeping it separate avoids changing capture settings for other OV9712 cameras.

devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/sensors/ov9712_i2c_dc_720p_dcs2330l.ini

usbLoad RTL8188EU with board-reported options +8/-0

Load RTL8188EU with board-reported options

• Adds a device Wi-Fi profile that loads 8188eu with power management, IPS and USB selective suspend disabled.

devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/wireless/usb

customizer.shSet DCS-2330L first-boot defaults +28/-0

Set DCS-2330L first-boot defaults

• Selects the board sensor profile, IR-cut and light monitoring, H.264 at 20 fps, the Wi-Fi profile and a device-specific upgrade URL.

devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/usr/share/openipc/customizer.sh

hi3518cv100_lite.listExclude unused sensor profiles and libraries +49/-0

Exclude unused sensor profiles and libraries

• Lists non-OV9712 sensor INI files and shared libraries for removal from the lite image, retaining the files required by this camera.

devices/hi3518cv100_lite_dlink-dcs-2330l/general/scripts/excludes/hi3518cv100_lite.list

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

Code Review by Qodo

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

1. IR LED duty changes do not take effect while running ✓ Resolved

Description

S96irled reads irled_duty only once before entering run, so the daemon never refreshes the
configured duty while it is active. Changing the environment value with fw_setenv or restarting
the night transition therefore continues using the stale startup value until the service is
restarted.

Code

devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[R9-10]

+IRLED_DUTY=$(fw_printenv -n irled_duty 2>/dev/null)
+IRLED_DUTY=${IRLED_DUTY:-35}

Evidence

The service initializes IRLED_DUTY once before run and then uses that fixed shell variable when
night mode changes; no later configuration read occurs in the loop.

Route and control the IR emitter through PWM2
devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[9-10]
devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[30-36]

Agent prompt

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

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
Issue description
The IR LED daemon reads `irled_duty` only at startup, so configuration changes are not reread while the daemon runs as required by the board-specific IR control behavior.
Fix Focus Areas
- devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[9-10]
- devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[30-36]
Recommended Fix
Reload and validate `irled_duty` during the control loop or immediately before each PWM2 update, preserving the default of 35 and ensuring duty changes are applied through the existing disable/re-enable sequence.

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

---

2. Restarting can leave the IR LEDs off ✓ Resolved

Description

The stop branch removes the PID file immediately after signalling the controller, without waiting
for its TERM trap to finish disabling PWM2. If start follows before that trap runs, the old
controller can turn off PWM2 after the new controller has enabled it, and the new loop will not
restore it until the GPIO value changes.

Code

devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[R48-50]

+		start-stop-daemon -K -q -p $PIDFILE
+		[ $? = 0 ] && echo "OK" || echo "FAIL"
+		rm -f $PIDFILE

Evidence

The controller disables PWM2 in its termination trap, while stop deletes its PID file without
waiting. Start can then launch another controller, whose loop writes PWM only when the sampled GPIO
value changes.

devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[28-37]
devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[40-50]

Agent prompt

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

## Issue description
Stopping the IR controller returns and deletes its PID file before the controller's PWM cleanup finishes, allowing a subsequent start to race with that cleanup.
## Fix Focus Areas
- devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[46-50]
## Recommended Fix
After signalling the recorded controller, wait for that process to terminate before removing its PID file and completing stop. Handle a termination timeout without allowing a second controller to start against the old one.

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

---

3. Missing GPIO state can leave IR LEDs on ✓ Resolved

Description

The run loop initializes last to an empty value, so a failed first read of
/sys/class/gpio/gpio0/value also produces an empty value and skips the PWM update. If PWM2 was
already enabled when the daemon starts and the GPIO node is unavailable, the loop never enforces the
intended off state while reads keep failing.

Code

devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[R29-33]

+	last=
+	while :; do
+		night=$(cat /sys/class/gpio/gpio0/value 2>/dev/null)
+		if [ "$night" != "$last" ]; then
+			[ "$night" = 1 ] && pwm2 "$IRLED_DUTY" || pwm2 0

Evidence

A failed cat produces the same empty string as last=, so neither PWM branch runs. The start path
has no preceding call to disable PWM2.

devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[12-20]
devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[23-43]

Agent prompt

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

## Issue description
An unavailable GPIO node on the first poll matches the loop's empty initial state, leaving any previously enabled PWM2 output untouched.
## Fix Focus Areas
- devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[23-35]
## Recommended Fix
Disable PWM2 at startup before polling, and treat an unreadable or invalid GPIO value as the off state. Ensure the first sample applies a state even when the read fails.

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

---

4. Invalid brightness can stop IR control ✓ Resolved

Description

IRLED_DUTY is taken directly from fw_printenv and used in shell arithmetic without checking that
it is an integer from 0 to 100. A malformed irled_duty value encountered on a night-state
transition can fail the arithmetic expansion after PWM2 has been disabled, preventing the controller
from applying the night setting.

Code

devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[R9-10]

+IRLED_DUTY=$(fw_printenv -n irled_duty 2>/dev/null)
+IRLED_DUTY=${IRLED_DUTY:-35}

Evidence

The environment value has only an empty-string fallback. On a night transition, pwm2 disables the
channel before interpolating that unchecked value into arithmetic for the duty register.

devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[9-20]
devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[29-35]

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 boot-environment brightness value reaches PWM arithmetic without validation, so a malformed setting prevents normal night-state control.
## Fix Focus Areas
- devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[9-10]
- devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/init.d/S96irled[12-20]
## Recommended Fix
Validate the environment value as a decimal integer in the 0–100 range before entering the loop; use the documented default when it is invalid. Pass only the validated value to PWM arithmetic.

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

---

View review recommended (1)

5. Wi-Fi driver failures report success ✓ Resolved

Description

The wireless profile executes exit 0 regardless of whether modprobe 8188eu succeeds. When the
module is missing or rejects an option, the profile reports a successful load despite Wi-Fi
remaining unavailable.

Code

devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/wireless/usb[R4-5]

+	modprobe 8188eu rtw_power_mgnt=0 rtw_ips_mode=0 rtw_enusbss=0
+	exit 0

Evidence

The customizer selects this exact profile; its matching branch unconditionally returns zero
immediately after modprobe, discarding that command's failure status.

devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/usr/share/openipc/customizer.sh[21-23]
devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/wireless/usb[3-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 board's wireless profile masks a failed driver load by unconditionally returning success.
## Fix Focus Areas
- devices/hi3518cv100_lite_dlink-dcs-2330l/general/overlay/etc/wireless/usb[3-5]
## Recommended Fix
Return the exit status of `modprobe 8188eu` for the matching profile instead of always exiting zero.

ⓘ 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 add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[garnser]

Thanks for turning the findings into a device target and merging the Wi-Fi compatibility fix. I reviewed bbd695b2ef98acbea309c0590de22abd9d133248 and ran component tests on the DCS-2330L A. The complete image from this PR has not been flashed or booted, so please keep its hardware-installation status pending.

Hardware results for the new IR script

I ran this PR's S96irled logic on the existing custom Linux 3.0.8 installation. For isolation, only DAEMON and PIDFILE were changed to temporary paths. A temporary fw_printenv shim supplied the test duty values in RAM, so these tests did not write the bootloader environment. The existing native IR controller was stopped while the candidate ran, and restored afterwards.

Test	Observed PWM2 readback
Missing duty setting, night	Default 35%; period 150, active duty 53, control 5
Change to 20% and restart	Active duty 30, control 5
Change back to 35% and restart	Active duty 53, control 5
Stop	Control 0, emitter disabled; the old latched duty remains visible as expected
Command daytime through Majestic	GPIO0 became 0; candidate disabled PWM2
Command nighttime through Majestic	GPIO0 became 1; candidate enabled PWM2

The private snapshots also showed a brightness response between 20% and 35%. This was not a calibrated illumination test. The source touches PWM2 and the two board mux registers, leaving PWM1 alone. Automatic day/night monitoring, the original 35% controller and the existing nighttime ISP profile were restored after testing. The automatic fallback script's checksum is unchanged.

Remaining decimal-input bug in duty()

08 and 09 pass the current digits/range check but the camera's BusyBox sh interprets leading-zero arithmetic operands as octal. A read-only reproduction on the actual camera:

sh -c 'd=08; n=$(((150 * d + 50) / 100)); printf "%s\n" "$n"'
# sh: arithmetic syntax error; exit status 2

Likewise, a setting such as 035 can silently use the wrong duty. No such value was applied to the real PWM hardware during the test. Normalizing a bounded decimal string before PWM arithmetic fixes both the leading-zero case and oversized input. Suggested replacement, tested with the camera's BusyBox shell:

duty() {
    d=$(fw_printenv -n irled_duty 2>/dev/null)
    case "$d" in
        [0-9] | [0-9][0-9] | [0-9][0-9][0-9])
            d=$(expr "$d" + 0)
            [ "$d" -le 100 ] || d=35
            ;;
        *) d=35 ;;
    esac
    echo "$d"
}

Verified outputs: empty/invalid/negative/101/oversized input → 35; 0 → 0; 08 → 8; 09 → 9; 035 → 35; 100 → 100. PWM arithmetic then succeeds. The original script, rather than this suggested fix, was used for the normal 20%/35% hardware tests above.

Sensor, Wi-Fi and installation scope

• Sensor: the PR's board INI matches the hardware-tested INI section-for-section/key-for-key, including Mask_0 = 0xFFC00000. The existing custom installation with that configuration no longer has the original green/purple highlight solarization. A residual cool colour tint is a separate issue; the optional scene-specific ISP tuning should remain separate as you have done.
• Wi-Fi: the current custom build is associated (wpa_state=COMPLETED), and all three running module parameters are 0. This supports the reported driver/guard/options combination, but does not establish that the new Buildroot-produced module, first-boot wlandev selection or complete PR image has been tested.
• Bootloader/layout: this unit still has its stock bootloader. Its stored bootcmd is sf probe 0;sf read 0x82000000 $(loadbootaddr) $(loadbootsize);bootm 0x82000000. The selector names are not persistent keys returned by fw_printenv on the running unit; they must not be assumed to have fixed stored values.

The running custom layout has the kernel at offset 0x00200000, length 0x00200000 (mtd3); rootfs at 0x00c00000, length 0x00800000 (mtd6); and rootfs_data at 0x01400000, length 0x00200000 (mtd7). It boots with root=/dev/mtdblock6 and explicit mtdparts. The boot/mydlink/rescue and remaining stock partitions were retained. These are observations of this installation, not flashing instructions. A standard 8M layout cannot be treated as a drop-in upgrade for this arrangement while retaining the same fallback.

The camera is managed over Wi-Fi only, and preserving the existing automatic fallback is required. Could you attach the prebuilt kernel and rootfs components, their SHA-256 checksums, and the exact builder/firmware source revisions used, as offered in #216? The next step is to inspect those artifacts and plan fallback-preserving component testing within the existing layout. Even successful component testing there would not validate a standard 8M installation path or an OpenIPC U-Boot conversion. I have not performed either conversion or a full-image flash in this round.

[openipc-ai]

Thanks. The on-camera S96irled results are exactly what was needed, and the octal catch is a real bug.

duty(): fixed in 75f060d with your replacement as-is. Under BusyBox ash here it gives your outputs: empty/abc/-5/101/1000 → 35, 0 → 0, 08 → 8, 09 → 9, 035 → 35, 100 → 100. The image's BusyBox has expr.

Components: https://github.com/OpenIPC/builder/releases/tag/test-dcs-2330l-75f060d (prerelease, outside the nightly/manifest channels)

builder	75f060d84922faaf298efa3ac5885aa742a39ec7 (this PR's head)
firmware	a5d9fcef1191d3e030f75625dce8889ae64f1baa (master, includes OpenIPC/firmware#2726)
uImage.hi3518cv100	1864712 B, load/entry 0x80008000, 08ed54b10f2d86d9bb904c233d1fd689299cb2a720477642f62e0a6d5e3a0b2a
rootfs.squashfs.hi3518cv100	4915200 B, squashfs 4.0 xz, 8ec8727b6c3c1d49d9bf9243b8927a8dab12d3b7048e33ea2952100b97209aad

Both fit the partitions you listed: the kernel fits your 2 MiB mtd3 and the rootfs your 8 MiB mtd6. Use them as a pair, since 8188eu.ko in the rootfs is built for this kernel.

What this image does that matters inside your layout. These come from reading the firmware source, not from running it on your arrangement:

• Command line: the kernel takes it from the bootloader (CMDLINE_FROM_BOOTLOADER, not FORCE, with MTD_CMDLINE_PARTS=y), so your root=/dev/mtdblock6 and explicit mtdparts apply.
• Overlay: /init finds the overlay by the partition name rootfs_data. If that partition won't mount as jffs2 and isn't recognised as OpenIPC settings, /init erases it. Your mtd7 holds your current overlay, so back it up first.
• Bootloader environment:
  • The image ships no /etc/fw_env.config, so fw_printenv/fw_setenv find the environment on their own. I haven't verified where they'd land on the stock D-Link layout.
  • S30customizer runs customizer.sh once, unless /etc/custom.ok exists in the overlay. That script calls fw_setenv upgrade … and fw_setenv wlandev …, which write the environment.
  • If you want the environment untouched, make sure /etc/custom.ok is present before first boot.
• Wi-Fi-only management: this image's /etc/wireless/usb knows only the profile rtl8188eu-dlink-dcs-2330l. Any other wlandev value loads no driver, so check fw_printenv -n wlandev first.
• Your overlay can override files in this image: a /etc/wireless/usb, S96dcs2330-ir or majestic.yaml already there replaces the image's copy. With your native IR controller still in the overlay, two controllers would drive PWM2.
• Upgrades: don't run sysupgrade on this layout. It assumes the standard OpenIPC partitioning.

The hardware-install status stays pending as you asked. Component results on your layout would cover the kernel, driver and rootfs. A standard 8M or OpenIPC U-Boot install would remain a separate, untested question.