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.
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.
The profile already left backlightPin unset, but the comment still described
the IR illuminator control as unresolved, which read as unfinished work rather
than as a board fact.
Hardware confirms the illuminator is driven by the board's own daylight-sensor
circuitry. The SoC only observes the resulting light state on GPIO3_0 and
drives the bistable IR-cut filter on GPIO34/33, so there is no SoC-controlled
backlight GPIO to configure here.
Documentation only; runtime configuration is unchanged. This retires the last
caveat the original SVI-252B K202 profile shipped with.
The profile went in with a known remainder: a brief purple frame during the
day/night transition, tracked upstream in OpenIPC/majestic#325 and deliberately
left without a board-specific workaround. That issue has since been fixed -- into
night the picture goes grey before the filter moves, coming back out it returns to
colour after the filter has shut, and the switch now reaches the stream on the next
frame instead of waiting out the current GOP. With that, dusk is clean on this
camera at the default `transitionDelayMs: 0`.
What is left is the dawn side, and it is mechanical: the bistable IR-cut filter is
still physically swinging shut while the picture is already back in colour, which
is worth about two frames of cast. `nightMode.transitionDelayMs` is the documented
pause between the picture changing and the filter moving (0-2000 ms, default 0),
and how fast a filter swings is a property of the board -- so this belongs in the
device profile rather than in any shared default. 150 ms clears it here.
Tested on the physical SVI-252B K202 by the author, repeated transitions in both
directions, both now clean.
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.
