hi3518ev100: add HiWatch DS-I203 device profile

[ArthurKoba]

Summary

Adds an OpenIPC device profile for the HiWatch DS-I203 camera.

Tested hardware:

• HI3518EV100
• Sony IMX122
• 256 MiB DDR3
• GD25Q128 16 MiB SPI NOR
• RTL8201F Ethernet PHY at address 3

The 256 MiB physical memory is configured as 128 MiB Linux + 128 MiB MMZ.

This hardware requires the DDR3/256M U-Boot variant added in OpenIPC/u-boot-hi3516cv100#6.

Device configuration

The profile provides the board-specific configuration required by the DS-I203:

• osmem=128M
• 16 MiB NOR partition layout
• PHY address 3 / MDIO interface 0
• IMX122 sensor selection
• /etc/sensors/imx122_spi_dc_1080p.ini
• IR-cut control on GPIO 6/5
• IR backlight on GPIO 42

The first-boot customizer writes the required U-Boot environment and performs a delayed reboot so the memory layout and Ethernet configuration take effect on the next boot.

The IR illumination hardware also supports PWM brightness control and PWM0 was verified working on the camera. The current hi3516cv100 Majestic HAL does not provide PWM backlight control, so the profile uses GPIO ON/OFF control for now.

Native PWM support is tracked in OpenIPC/majestic#321.

Hardware validation

Tested end-to-end on a physical HiWatch DS-I203, starting from the original Hikvision firmware and completing the full migration to OpenIPC.

After the first-boot customizer and automatic reboot:

• U-Boot detects 256 MiB RAM
• Linux boots with mem=128M
• MMZ is 128 MiB
• the 16 MiB MTD layout is correct
• Ethernet works with PHY address 3 / MDIO interface 0
• the factory MAC address is preserved
• IMX122 is selected with the expected sensor configuration
• Majestic starts successfully
• IR-cut control works
• IR backlight control works

Final firmware build size:

• kernel: 1819 KiB / 2048 KiB
• rootfs: 4056 KiB / 8192 KiB

The full device build and repository checks pass.

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

PR Summary by Qodo

Add HiWatch DS-I203 HI3518EV100 device profile

✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Adds a Lite OpenIPC profile for the HI3518EV100-based HiWatch DS-I203.
• Configures 256 MiB memory, 16 MiB NOR, Ethernet, IMX122, and infrared hardware.
• Applies boot and Majestic settings on first startup, then reboots automatically.

Diagram

graph TD
  A["Device Defconfig"] -->|builds| B["Lite Firmware"] -->|boots| C["First-Boot Customizer"] -->|writes| D["U-Boot Environment"] -->|applies after reboot| E["Board Boot"]
  C -->|configures| F["Majestic Settings"] -->|controls| G["Camera Hardware"]
  E -->|initializes| G

Loading

High-Level Assessment

A dedicated device profile follows the repository's established model and is preferable to a generic HI3518EV100 profile because the board requires specific DDR sizing, partitions, PHY addressing, sensor selection, and GPIO assignments. Runtime autodetection would add complexity without clear benefit for these fixed hardware characteristics.

Files changed (4) +87 / -0

Enhancement (1) +27 / -0

customizer.shApply DS-I203 boot and camera settings +27/-0

Apply DS-I203 boot and camera settings

• Configures the upgrade image, 128 MiB Linux memory allocation, NOR partitions, PHY address, MDIO interface, and IMX122 sensor. Sets Majestic's sensor, IR-cut, and backlight GPIO configuration before scheduling a reboot to activate boot-time settings.

devices/hi3518ev100_lite_hiwatch-ds-i203/general/overlay/usr/share/openipc/customizer.sh

Documentation (1) +1 / -0

README.mdList HiWatch DS-I203 as a supported device +1/-0

List HiWatch DS-I203 as a supported device

• Adds the DS-I203 hardware profile to the supported-device table, including its SoC, IMX122 sensor, 16 MiB NOR flash, completion status, and required DDR3/256M U-Boot variant.

README.md

Other (2) +59 / -0

hi3518ev100_lite_hiwatch-ds-i203_defconfigDefine the DS-I203 Lite firmware build +58/-0

Define the DS-I203 Lite firmware build

• Adds the Buildroot configuration for a 16 MiB HI3518EV100 Lite image using the hi3516cv100 kernel and Hisilicon SDK. Enables the OpenIPC packages needed for device management, streaming, networking, and configuration.

devices/hi3518ev100_lite_hiwatch-ds-i203/br-ext-chip-hisilicon/configs/hi3518ev100_lite_hiwatch-ds-i203_defconfig

hi3518ev100_lite.listRetain all files in the 16 MiB image +1/-0

Retain all files in the 16 MiB image

• Adds an empty exclusion policy documenting that the DS-I203 firmware requires no file removals for its 16 MiB image.

devices/hi3518ev100_lite_hiwatch-ds-i203/general/scripts/excludes/hi3518ev100_lite.list

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

Code Review by Qodo

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

1. Firmware targets the wrong chip model 📘 Rule violation ≡ Correctness

Description

The new defconfig sets BR2_OPENIPC_SOC_MODEL to hi3516cv100 even though the device directory and
documented hardware identify an hi3518ev100. Builds using this value identify the board as the
wrong model while the separate BR2_OPENIPC_SOC_FAMILY value already supplies the shared
hi3516cv100 family.

Code

devices/hi3518ev100_lite_hiwatch-ds-i203/br-ext-chip-hisilicon/configs/hi3518ev100_lite_hiwatch-ds-i203_defconfig[34]

+BR2_OPENIPC_SOC_MODEL="hi3516cv100"

Evidence

Compliance rule 3 requires the defconfig SoC selection to match the target hardware. The defconfig
declares hi3516cv100, while the newly documented device row identifies the tested chip as
HI3518EV100; the adjacent family setting separately represents the shared hi3516cv100 platform.

CLAUDE.md: Device Defconfig Must Match the Target Hardware: CLAUDE.md: Device Defconfig Must Match the Target Hardware: CLAUDE.md: Device Defconfig Must Match the Target Hardware: CLAUDE.md: Device Defconfig Must Match the Target Hardware: CLAUDE.md: Device Defconfig Must Match the Target Hardware: CLAUDE.md: Device Defconfig Must Match the Target Hardware: CLAUDE.md: Device Defconfig Must Match the Target Hardware: CLAUDE.md: Device Defconfig Must Match the Target Hardware
devices/hi3518ev100_lite_hiwatch-ds-i203/br-ext-chip-hisilicon/configs/hi3518ev100_lite_hiwatch-ds-i203_defconfig[33-35]
README.md[36-36]

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 HiWatch DS-I203 defconfig declares `hi3516cv100` as its SoC model, although the target hardware is `hi3518ev100`; the shared compatibility family is configured separately.
## Fix Focus Areas
- devices/hi3518ev100_lite_hiwatch-ds-i203/br-ext-chip-hisilicon/configs/hi3518ev100_lite_hiwatch-ds-i203_defconfig[34-35]
## Recommended Fix
Change `BR2_OPENIPC_SOC_MODEL` to `hi3518ev100`. Keep `BR2_OPENIPC_SOC_FAMILY="hi3516cv100"` if that is the shared kernel and driver family required by this chip.

ⓘ 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 ask Qodo to dismiss a finding you disagree with, with your reason on record

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

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

1. Firmware targets the wrong chip model 📘 Rule violation ≡ Correctness

The new defconfig sets BR2_OPENIPC_SOC_MODEL to hi3516cv100 even though the device directory and
documented hardware identify an hi3518ev100. Builds using this value identify the board as the
wrong model while the separate BR2_OPENIPC_SOC_FAMILY value already supplies the shared
hi3516cv100 family.

Agent Prompt

## Issue description
The HiWatch DS-I203 defconfig declares `hi3516cv100` as its SoC model, although the target hardware is `hi3518ev100`; the shared compatibility family is configured separately.

## Fix Focus Areas
- devices/hi3518ev100_lite_hiwatch-ds-i203/br-ext-chip-hisilicon/configs/hi3518ev100_lite_hiwatch-ds-i203_defconfig[34-35]

## Recommended Fix
Change `BR2_OPENIPC_SOC_MODEL` to `hi3518ev100`. Keep `BR2_OPENIPC_SOC_FAMILY="hi3516cv100"` if that is the shared kernel and driver family required by this chip.

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

[ArthurKoba]

Fixed. BR2_OPENIPC_SOC_MODEL is now hi3518ev100, while BR2_OPENIPC_SOC_FAMILY remains hi3516cv100 as required by the shared SDK family. I also aligned the kernel config path with the upstream hi3518ev100_lite_defconfig.

[openipc-ai]

Thanks for the writeup — the hardware validation list and the build sizes made this a lot quicker to check, and the SoC model fix from the earlier round is right. That one mattered more than it looks: rootfs_script.sh resolves the exclude list as ${OPENIPC_SOC_MODEL}_${OPENIPC_VARIANT}.list, so leaving hi3516cv100 there would have orphaned the file.

Two things need changing before this can go in. Both are in customizer.sh, and both are cases where a camera brought up by hand behaves differently from a fresh install — which is probably why the end-to-end test passed:

1. osmem 128M is set without totalmem, and load_hisilicon hard-exits when osmem >= totalmem.
2. fw_setenv mtdparts rewrites the flash layout at first boot, three seconds before reboot -f.

Details inline. Everything after those two is a nit you can take or leave.

Verified clean

• Defconfig delta against firmware's hi3518ev100_lite_defconfig is exactly the WiFi/mosquitto/motors removal plus BR2_OPENIPC_FLASH_SIZE 8 -> 16. Nothing else touched.
• Exclude list filename hi3518ev100_lite.list is correct, and the comment-only content is handled: rootfs_script.sh skips # lines, and firmware's own list for this board is empty anyway.
• Upgrade URL matches what CI publishes. The device name has two underscores, so COMMON=2 takes the rename branch in master.yml and the asset lands as hi3518ev100_lite_hiwatch-ds-i203-nor.tgz.
• ${extras} and ${mtdparts} do reach the kernel command line — both appear in CONFIG_BOOTARGS in u-boot's include/configs/hi-common.h. phyaddru is read by u-boot's drivers/net/hisfv300/net-drv.c, and hieth.phyaddru=3 works as a plain cmdline parameter because CONFIG_HIETH_SWITCH_FABRIC=y builds the driver in rather than as a module.
• imx122 is a real branch in hisilicon-osdrv-hi3516cv100's load_hisilicon (pinmux + ssp_sony.ko), and imx122_spi_dc_1080p.ini ships in that package and is installed to /etc/sensors.
• .github/scripts/ci-matrix.py --self-test passes on this branch, and the PR narrows the build matrix to exactly this one device.

[openipc-ai]

This needs fw_setenv totalmem 256M next to it, or the camera loses video on the very next boot.

hisilicon-osdrv-hi3516cv100/files/script/load_hisilicon opens with:

mem_total=$(fw_printenv -n totalmem | tr -d 'M')
mem_total=${mem_total:=64}

and ends the memory block with a hard guard:

if [ $os_mem_size -ge $mem_total ]; then
	echo "[err] os_mem[$os_mem_size], over total_mem[$mem_total]"
	exit
fi

calc_mmz_info then derives mmz_size = totalmem - osmem, so totalmem is the only source of the MMZ size — its absence silently becomes 64.

The trap is that totalmem is not reliably in the saved environment. OpenIPC's u-boot sets it from detect_memory() in board/hi3518/board.c, but that is a plain setenv into the RAM copy, never a saveenv. fw_printenv reads the env partition in flash, so it sees totalmem only if some install step happened to persist it. run setnor16m does, by accident, because it ends in saveenv — whereas the wiki's en/install-hisi.md procedure has the user type setenv totalmem 64M before saveenv, which persists the wrong value on any board with more than 64 MiB.

Boot by boot on a fresh install:

• Boot 1 — env still has u-boot's default osmem=32M, so os_mem_size=32, 32 >= 64 is false, modules load with a 32/32 split. This customizer runs and reboots.
• Boot 2 — cmdline is now mem=128M, os_mem_size resolves to 128, 128 >= 64 trips, load_hisilicon exits before insert_osal. No mmz.ko, no hi3518_*.ko, majestic cannot open the SDK. Permanent.

Your camera presumably has totalmem=256M in flash from the saveenv during bring-up, which is exactly why it worked for you and will not work for the next person. Pinning it makes the profile deterministic:

fw_setenv osmem 128M
fw_setenv totalmem 256M

devices/gk7205v300_lite_vixand-ivg-g6s and devices/hi3516ev300_ultimate_rostelecom-ipc8232swc-we already set both together for the same reason.

[openipc-ai]

Please drop this line. Rewriting the flash layout from a first-boot script is either a no-op or a brick, depending on how the camera was installed — and there is no way for the script to tell which.

The string itself is correct: it is byte-identical to mtdpartsnor16m in u-boot's include/configs/hi-common.h. But that is an opt-in macro, not the default. The default in the same CONFIG_EXTRA_ENV_SETTINGS block is the 8 MiB layout:

mtdparts       = hi_sfc:256k(boot),64k(env),2048k(kernel),5120k(rootfs),-(rootfs_data)   <- default
mtdpartsnor16m = hi_sfc:256k(boot),64k(env),3072k(kernel),10240k(rootfs),-(rootfs_data)  <- only via `run setnor16m`

So there are two install paths:

• User ran run setnor16m (whose saveenv persists the 16M string) and flashed with uknor16m/urnor16m — rootfs at 0x350000. The env already holds this exact string and the line does nothing.
• User flashed with the 8M macros — urnor8m writes the rootfs at 0x250000. That succeeds on a 16 MiB chip, because a 4056 KiB rootfs fits the 5120k window fine. The camera boots, reaches S30customizer, and this line moves root=/dev/mtdblock3 from 0x250000 to 0x350000. Three seconds later reboot -f fires into blank flash: kernel panic, recoverable only over UART.

Flash layout belongs to the install procedure, not to a first-boot script — no other device under devices/ sets mtdparts. If the DS-I203 needs the 16M layout, that belongs in the install instructions as run setnor16m before flashing.

[openipc-ai]

Follow-on from the mtdparts line above, in the branch where it does change something: rootfs_data moves too, from 256+64+2048+5120 = 7488 KiB (0x750000) to 256+64+3072+10240 = 13632 KiB (0xD50000).

S30customizer runs this script and then does touch /etc/custom.ok, both landing in the overlay at the old offset. After reboot -f the overlay is mounted at the new one, unformatted — so .isp.sensorConfig, the IR-cut pins, the backlight pin and lightMonitor are all gone, /etc/custom.ok is gone, and the customizer runs again and reboots again. Dropping the mtdparts line fixes this one too.

Separately, and not something this PR introduced: (sleep 3 ; reboot -f) & returns immediately, so rcS carries on into S70vendor (load_hisilicon -i, a serial insmod of the vendor modules) while the timer runs. On a slow first boot the reboot can land in the middle of that. Several existing profiles have the same race, so I would not block on it here.

[openipc-ai]

Small thing: this note sits above the upgrade URL, which has nothing to do with the bootloader. The line it actually explains is fw_setenv osmem 128M below — 128M is only valid on the DDR3/256M u-boot variant. Worth moving it down two lines (and above the totalmem line it should gain), so someone editing the self-update URL later does not read it as a constraint on that.

[openipc-ai]

extras is assigned wholesale, not appended, and it is the single catch-all that CONFIG_BOOTARGS tacks onto the command line (... mtdparts=${mtdparts} ${extras}). Firmware's own generic customizer uses the same slot for something else entirely (fw_setenv extras initcall_blacklist=hisi_femac_driver_init).

Not a bug today, but anyone who later needs an initcall blacklist or an mmz tweak on this board has to remember to re-append hieth.phyaddru=3 hieth.mdioifu=0 by hand, or Ethernet silently falls back to CONFIG_HIETH_PHYID_U=1 from the kernel config. A one-line comment saying extras is assigned rather than appended would save that.

[openipc-ai]

irCutEnabled and backlightEnabled (line 20) are both already true by default — the wiki's majestic-config.md shows them commented out at true, and they are opt-out keys: only an explicit false parks the filter or the lamp. No other device in the tree sets either.

The pins on lines 17-18 and 21 are what actually configure this board, so these two lines can go. Keeping them mostly risks a future reader assuming they are load-bearing.

[openipc-ai]

This can go — the board has no WiFi and every sub-option was correctly dropped, but the parent is still enabled.

linux-firmware-openipc.mk's INSTALL_TARGET_CMDS is four ifeq blocks keyed on _ATHEROS_9271, _MEDIATEK_MT7601U, _RTL_8188EU and _XRADIOTECH_XR829. With none of them selected the recipe expands to nothing, so the package is configured, built and tracked for zero bytes of output.

[openipc-ai]

Sort order: HiWatch comes after HB-WIFI-Z6 v1.2, so this row wants to be one line further down. Column alignment is correct. (The table already has a couple of other misplacements, so this is drift rather than a new problem.)