Device profile for GARUS GSL-5030X-30AP-NM on PCB BLK16EV2-4339P-38X38:
Hi3516EV200, 8 MiB SPI NOR, wired Ethernet, fixed lens, no radio.
Sensor path is SC2315E-compatible MIPI at 1920x1080. The stock firmware's
2304x1296 "3M" mode is an output scaling path; no native 3MP sensor mode was
confirmed, so the profile keeps the proven 1080p mode. The physical die is
unidentified — XM documentation points at SC4239H, which has no OpenIPC driver
path — so the README row carries SC2315E? deliberately.
Day/night uses GPIO15 as the hardware status input with a bistable IR-cut
filter on GPIO8/GPIO9. GPIO15 needs its EV200 pinmux reasserted on every boot,
so that read-modify-write lives in muxes.sh, which S30customizer runs each
boot, rather than in the once-only customizer.sh. transitionDelayMs is 150,
measured on this camera: an immediate transition showed a purple cast while the
filter was still moving.
The exclude list prunes 33 of the 34 sensor drivers the Hi3516EV200 packages
install, leaving libsns_sc2315e.so, and keeps iq/imx307.ini so the default.ini
symlink still resolves. Codec and fps are left unset because h264 at 20 fps are
already the shipped majestic defaults for this SoC and variant.
Built, flashed and booted on hardware: 1080p video and RTSP, H.264 and H.265,
Ethernet, microphone capture and speaker output, and automatic day/night
switching with IR-cut operation.
HI3518EV300 with a JXF23 sensor and an RTL8188FU USB radio on 16 MiB NOR.
Video and Wi-Fi are working on the hardware; the motors are not yet, which the
README row records.
Finished off before merging, since the branch had sat since March:
BR2_PACKAGE_JSONFILTER is dropped, as #128 did for every other defconfig after
firmware/#2304. The repack.sh section heading that had been reworded in passing
is restored to what master has, and customizer.sh gets its missing trailing
newline. Rebased onto master, where the README row now sits alongside the
SpezVision SVI-252B entry added since.
The UBI config reference is corrected. It pointed at
scripts/ubifs/ubinize_hisilicon.cfg, which is not in the firmware tree — the
two devices using that name each ship a private copy — so the build reached
rootfs.ubifs and then failed on the missing file. It now uses the in-tree
ubinize.cfg, matching both hi3518ev200 ultimate boards; that suits the nand
repack, which passes uImage separately rather than embedding it in a volume.
This profile had never been compiled by CI before, which is why a defect this
plain survived two reviews. Both artifacts now build: NOR rootfs 6828/8192 KB,
NAND rootfs.ubi 13568/16384 KB.
T31X with an SC5235 sensor and an RTL8733BU USB radio on 16 MiB NOR.
The profile pins BR2_OPENIPC_SNS_MODEL, so ingenic-osdrv-t31 installs only this
board's sensor yaml and params blob and no exclude list is needed.
Rebuilt on current master before merging. The original branch carried an
unrelated 2025 commit from another contributor touching ssc338q_apfpv, whose
customizer no longer exists in the tree, and its README hunk had gone stale
against the device table; replaying either would only have produced conflicts
over devices this PR has nothing to do with. What landed is the net device
addition and nothing else.
BR2_PACKAGE_JSONFILTER is dropped, as #128 did for every other defconfig after
firmware/#2304.
Ingenic T31N with a GalaxyCore GC2053, 64 MiB RAM, 8 MiB SPI NOR and wired
Ethernet. Tested on the physical camera: builds, flashes and boots, with
Ethernet, GC2053 video, H.264/H.265 streaming, automatic day/night switching,
IR-cut control and audio capture/playback all working.
The board has no radio, so the defconfig drops wireless-tools, wpa_supplicant
and the Realtek driver that the nearest sibling carries, along with the QR
onboarding helper that only exists to join a network.
The kernel fragment turns off MMC, the wireless stack, USB and FAT rather than
forking the generic T31 config. Because FAT goes with it, the profile also
overrides /etc/modules: the stock list asks for vfat and exfat, which would no
longer exist.
The exclude list prunes motor.ko and the two sample_pwm modules. Those are
built for every T31 board by ingenic-opensdk regardless of the pinned sensor,
since they sit outside the sensor tree in the openingenic Kbuild, and no board
in the tree had pruned them until now. There is no Kconfig symbol to disable
them, so the exclude list is the only lever.
SpezVision SVI-252B K202 on board BLK16CV-0323-38X38-V1.01: HiSilicon Hi3516CV200,
Sony IMX323 on the I2C/DC 1080p configuration, 8 MiB SPI NOR, wired Ethernet only.
The board's day/night path is what needs describing. The hardware daylight sensor
is GPIO3_0 (legacy HiSilicon numbering 24) and the bistable IR-cut filter is
GPIO4_2 / GPIO4_1 (34 and 33), which the customizer seeds into majestic. GPIO3_0
has to be muxed to function 0 at 0x200f0034 before it can be read, and
load_hisilicon's imx323 branch does not touch that register, so the board ships a
muxes.sh for it — S30customizer runs that on every boot, independently of which
streamer is in use, so the pin contract holds for anything running on the camera.
No backlightPin is set: a separate software-controlled IR illuminator GPIO was not
proven on this board.
Rather than forking the whole hi3516cv200.generic.config into the device directory
the way the other CV200 profile does, the board carries a kernel config fragment
naming only its own hardware facts — no SD/MMC socket, no Wi-Fi radio, no used USB
path, NOR only — so it keeps tracking upstream kernel changes instead of shadowing
them. This is the first device here to use BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES.
Together with an exclude list trimmed to the one sensor this camera has, the image
lands at 3956736 B of rootfs, leaving 1256 KB of rootfs headroom and 524 KB of
kernel headroom on the 8 MiB layout.
Tested on physical hardware by the author: builds, flashes and boots, with IMX323
video, Ethernet, the hardware daylight sensor and automatic IR-cut switching all
working. A brief purple frame can still appear during the colour-to-grayscale
transition; that is tracked upstream in OpenIPC/majestic#325 and no board-specific
workaround is carried here.
SSC377, SmartSens SC430AI, 16 MB NOR, RTL8188FTV on USB. The generic
ssc377_lite defconfig with the 16 MB layout, the rtl8188fu driver and the
SAE-capable wpa_supplicant-openipc; the Wi-Fi module's power gate (GPIO 42)
in the wireless/usb entry; IR-cut, backlight and IR LED pins; the SC430AI
IQ file.
Depends on OpenIPC/sensors#7 (driver), OpenIPC/firmware#2445 (loader entry)
and OpenIPC/firmware#2449 (supplicant package).
Co-authored-by: nzzane <12163646+nzzane@users.noreply.github.com>
The first ssc337de_lite device in the tree to ship an excludes list: it prunes 17 of the 18 sensors OpenIPC/sensors builds for infinity6b0 and keeps sc401ai, the board's own.
Wi-Fi is an MT7601U on the vendor STA driver, so the device carries its own /etc/wireless/usb with the gpio 14 power cycle ahead of the modprobe, and execs modprobe so the profile's exit status is the module's rather than an unconditional success. The overlay is registered in .github/firmware-drift.json against the current firmware blob rather than left to drift silently.
Built green on CI before a rebase over #151 and #153, which collided only on the README device table.
A clone of the in-tree t31_lite_zte-k540 with the K545's own deltas: gpio-motors driven by ptz_control/ptz_gpio rather than the older motors package, majestic IR-cut, backlight and speaker pins, and the same SD-card detect patch (GPIO_PB(18) is pin 50). It reuses K540's atbm603x-t31-zte-k540 wlandev profile, which is already upstream in firmware's shared adapter table.
Built green on CI, narrowed to this device. Two points left open with the author, both inherited from K540 rather than introduced here: the defconfig declares an 8M flash while the README row says NOR_16M, which caps the rootfs partition at 5120KB instead of 8192KB; and the device ships no t31_lite.list, as K540 does not either.
The device is a YuanCam-branded (HQLS/hdwificam OEM) HI3518EV300 board —
confirmed on a lab unit via its Factory.bin/SysParam.bin tags
("YuanCamFactory"/"YuanCamSysparam") and its P2P device id
(DGK-423403-YZHGE). Rename the placeholder "Bathhouse" profile to a
proper vendor-model name and fill in the sensor, identified on hardware
with ipctool as JXH62 (previously "?" in the README table). The
defconfig, customizer.sh and excludes list carry over unchanged except
for the upgrade URL, which now points at the renamed release asset.
XiongMai's 85H50AI: hi3516ev300 + imx335 with a motorized zoom/focus
module whose MCU shares /dev/ttyAMA0 with the serial console at 115200,
speaking the XM near-Pelco protocol (majestic-webui's btzoom-xm).
Proven on a lab unit driven end to end through the WebUI
(majestic-webui#227).
The defconfig is a byte-copy of firmware's hi3516ev300_lite_defconfig.
customizer.sh (first boot) sets sensor imx335, the upgrade URL, and the
PTZ trio — ptz_control pelco-xm, ptz_port /dev/ttyAMA0, ptz_caps
'zoom focus' (majestic-webui#261) — and deletes the getty line from
/etc/inittab: the MCU owns the console UART. The edit lands in the
overlay and heals itself (an upgrade that wipes the overlay wipes
/etc/custom.ok too, so the script re-runs). S01printk quiets runtime
kernel messages that would drip onto the PTZ wire. The required
hi3516ev300_lite excludes list prunes every non-imx335 sensor blob,
generated from the live lite image so no entry is stale on arrival.
Dahua-OEM 2 MP camera. The SC223A is on hardware I2C0 routed to the
VI-RAW pads (0x112c0060/0x64 func2) rather than the default mipi-sensor
pads (0x30/0x34 func1) the SDK probes, and needs a 27 MHz MCLK
(0x120100f0=0x19; SDK default 0x11/div4 leaves it unresponsive).
S71devmem re-muxes the pads, selects the SENSOR_RSTN reset (GPIO8_7
func2) and fixes MCLK after S70vendor/load_goke; the stock
open_sensor_i2c then reaches the sensor over /dev/i2c-0. No kernel
module needed.
Verified on hardware: chip-id 0xcb3e over HW I2C0, MIPI lock 1920x1080
zero errors, majestic streams correct colour 1080p.
Co-authored-by: build <build@local>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Add TP-Link Kasa KC110 (HI3518EV200 + OV2735)
New device variant: hi3518ev200_ultimate_tplink-kasa-kc110.
Contents:
- kc110-board-support package: PTZ binary (mmap'd PL061), gpio-motors
shim for the openipc web GUI, IR control script, and a boot-time
pinmux init that writes 0x1 to the chip7/chip8 pads (0x200f00e8/ec/
f0/fc/100/104). The OpenIPC kernel pinctrl driver does not auto-set
these for the KC110's pan motor / IR-cut / IR-LED pads — the vendor
firmware writes them explicitly in hn_config.sh. Without this,
PL061 GPIODATA writes succeed silently but the pads never drive
the ULN2803 / solenoid / LED.
- Device overlay:
* etc/sensors/ov2735_i2c_1080p.ini — input_mode=0 (MIPI), 1-lane
(was input_mode=4 / 4-lane in upstream cv200 osdrv, which is
wrong for OV2735).
* usr/bin/load_hisilicon — adds an "ov2735" case that mirrors
ov2710_mipi (same MIPI pinmux + clock).
* usr/share/openipc/customizer.sh — first-boot configuration:
RTL8188FU wlandev, sensor config path, IR-cut pin 64, backlight
pin 63, lightMonitor true (AE recovery after IR-cut toggle).
- README.md row.
Hardware notes:
- SoC: Hi3518EV200; Sensor: OV2735 (MIPI 1-lane, RAW10);
Wi-Fi: RTL8188FU (USB); Flash: W25Q128 16 MB NOR.
- PTZ: 4-phase unipolar steppers via ULN2803 darlington array.
Pan = vendor base-10 GPIO 81/74/73/72 = OpenIPC PL061 65/60/59/58;
tilt = 0/1/2/44 = 0/1/2/36 (vendor's "44" is bank 4 pin 4 — i.e.
pin 36 in OpenIPC's PL061 numbering, NOT 44).
- IR-cut filter: GPIO 64 (vendor 80) active-low; IR-LED: GPIO 63
(vendor 77).
Status: PTZ + GPIO + IR fully functional. Video pipeline currently
needs an LD_PRELOAD shim around HI_MIPI_SET_DEV_ATTR because upstream
majestic builds combo_dev_attr_t with enIntfMode=DC / raw_data_type=0
for MIPI sensors that need RAW10. The shim is downstream-only pending
a real fix to majestic upstream; this PR delivers the rest of the
KC110 board support and will produce a fully-functional camera once
the majestic fix lands.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* tplink-kasa-kc110: use ov2735_mipi_1080p.ini
Follow OpenIPC/firmware #2155, which ships the OV2735 MIPI config as a
separate ov2735_mipi_1080p.ini and leaves ov2735_i2c_1080p.ini (the
parallel/DVP config) untouched.
- Rename the device's bundled sensor .ini to ov2735_mipi_1080p.ini and
carry the full corrected MIPI config: input_mode=0 (MIPI),
data_type=2 (RAW10), lane_id 2-lane, Input_mod=5 (MIPI),
Mask_0=0xFFF00000. The previous bundled copy only had input_mode
fixed (data_type/Input_mod/Mask_0 were still the wrong DVP defaults).
- Point customizer.sh's isp.sensorConfig at the new file.
- Exclude the unused parallel ov2735_i2c_1080p.ini from the image.
Verified on a TP-Link Kasa KC110 (OV2735 2-lane MIPI RAW10): clean
image, correct AE, RTSP H.264 1080p.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: moontwister <moontwister@users.noreply.github.com>
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
