rostelecom-ipc8232swc-we: drive the status LEDs (red power, blue net)

[widgetii]

Problem

The profile maps the two status LEDs in gpio.conf (led1=10 red, led2=25 blue), but
nothing on a majestic image reads gpio.conf, so the LEDs were inert. The only thing touching
them was muxes.sh, which pinned both high under a ### set leds power off ### comment that in
fact left them solid on: the LEDs are active high, so gpio set lights them.

Change

Drive them the usual boot/ready way, matching the stock firmware's own hardware map
(GPIO10 = red "power", GPIO25 = blue "net"):

• S01leds — boot: power LED on, net LED off.
• S99leds — ready: net LED on once boot reaches its end, so a lit blue LED means the camera is
  up. Both off when led_disabled=1, like the LED scripts on other OpenIPC cameras, and off on
  shutdown.
• muxes.sh no longer touches them.

IR-cut (irCutPin1/2 63/67), the IR illuminator (backlightPin 72) and the speaker
(speakerPin 28) were already correct in customizer.sh and work on majestic's defaults
(irCut/backlight auto, day/night by picture); this only adds the missing LED behaviour.

Hardware tested on

The lab IPC8232SWC-WE (Hi3516EV300, ov2735). Running the two scripts on it:

• baseline red=1 blue=1
• S01leds start → red=1 blue=0 (power only)
• S99leds start → red=1 blue=1 (power + net)

reading the GPIO values back at each step; GPIO10/25 drive on this board. IR-cut/day-night is
live on the same camera — majestic holds the night IQ sections for the next switch.

[openipc-ai]

/review

[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. The power LED lights despite being disabled ✓ Resolved

Description

S01leds unconditionally sets GPIO10 without checking led_disabled, while S99leds checks that
setting only later. When led_disabled=1, the red LED remains lit between the early and late boot
scripts, and it lights again if the early script is started manually.

Code

devices/hi3516ev300_ultimate_rostelecom-ipc8232swc-we/general/overlay/etc/init.d/S01leds[11]

+		gpio set 10; gpio clear 25

Evidence

The early script sets GPIO10 on every start. The late script is the first of these two scripts to
read led_disabled and clear GPIO10 when it equals 1, leaving a boot interval in which the
disabled power LED is on.

devices/hi3516ev300_ultimate_rostelecom-ipc8232swc-we/general/overlay/etc/init.d/S01leds[9-12]
devices/hi3516ev300_ultimate_rostelecom-ipc8232swc-we/general/overlay/etc/init.d/S99leds[8-15]

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 early boot script lights the red power LED even when `led_disabled=1`; the late boot script turns it off only afterward.
## Fix Focus Areas
- devices/hi3516ev300_ultimate_rostelecom-ipc8232swc-we/general/overlay/etc/init.d/S01leds[9-12]
## Recommended Fix
Read `led_disabled` before setting GPIO10. When it is `1`, clear both LEDs in the early script; otherwise retain the red-on, blue-off boot state.

ⓘ 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 switch off images and animations for a plain-text comment

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[widgetii]

Fixed in 1782821: S01leds reads led_disabled too, so with led_disabled=1 both LEDs stay dark from the start rather than the red one lighting until S99leds runs. Verified on the lab IPC8232SWC-WE (Hi3516EV300, ov2735): led_disabled unset → red on / blue off; led_disabled=1 → both off.