From 81edd55b89ceb2ae389c913c3b45f78e26019bc4 Mon Sep 17 00:00:00 2001 From: Adrian Fedoreanu Date: Sun, 9 Aug 2026 18:25:47 +0200 Subject: [PATCH] en: MT7601U driver performance note; VStarcam Hi3518EV200+GC2023 device page adding-wifi-driver.md: document that the mainline mt7601u and the vendor-lineage mt7601sta (BR2_PACKAGE_MT7601U_OPENIPC) drivers are not equivalent - measured 0.4-1.0 Mbps vs 15-17 Mbps transmit on the same Hi3518EV200 camera, dongle and AP, which is the difference between an RTSP stream that lags by seconds and one that keeps up. New device page for VStarcam pan/tilt cameras (Hi3518EV200 + GC2023 MIPI + MT7601U): install layout that keeps the vendor U-Boot, the missing-tftpdstp trap, GC2023 MIPI sensor notes including the digital gain 0xb1=0 black-frame failure mode, PTZ stepper pins recovered from the vendor motogpio.ko, and the IR-cut pinmux that sysfs alone cannot reach. --- README.md | 1 + en/adding-wifi-driver.md | 15 ++++ en/device-vstarcam-hi3518ev200-gc2023.md | 107 +++++++++++++++++++++++ 3 files changed, 123 insertions(+) create mode 100644 en/device-vstarcam-hi3518ev200-gc2023.md diff --git a/README.md b/README.md index 2ae45286..052a81b0 100644 --- a/README.md +++ b/README.md @@ -138,6 +138,7 @@ OpenIPC Wiki - [Smartwares CIP-37210](en/device-smartwares-cip-37210.md) - [Foscam X5](en/device-foscam-x5.md) - [TP-Link Tapo C110](en/device-tapo-c110.md) +- [VStarcam pan/tilt (Hi3518EV200 + GC2023)](en/device-vstarcam-hi3518ev200-gc2023.md) - [Xiaomi Mi Camera 2K (MJSXJ03HL)](https://github.com/OpenIPC/device-mjsxj03hl/) - [ATOM Cam / Hualai / Wyze](en/device-wyze-integration.md) - [Digitus DN-16048 Optizoom](en/device-digitus-dn16048.md) diff --git a/en/adding-wifi-driver.md b/en/adding-wifi-driver.md index 76f5dc8f..6c7520ba 100644 --- a/en/adding-wifi-driver.md +++ b/en/adding-wifi-driver.md @@ -72,6 +72,21 @@ BR2_PACKAGE_SSV635X_OPENIPC BR2_PACKAGE_MT7601U_OPENIPC ``` +Note: for MT7601U there are two different drivers. The mainline kernel driver +(`mt7601u.ko`, enabled via the kernel config) and the vendor-lineage MediaTek +DPO STA driver (`mt7601sta.ko`, built by `BR2_PACKAGE_MT7601U_OPENIPC`, with +cfg80211 support so the interface is a plain `wlan0` and wpa_supplicant drives +it as usual). They are not equivalent: on a Hi3518EV200 camera with a USB +`148f:7601` dongle, measured on the same access point and channel, the mainline +driver managed only 0.4–1.0 Mbps transmit (with repeated `mt7601u_mcu_wait_resp +retrying` in dmesg and gateway RTT spikes to 800+ ms), while `mt7601sta` reached +15–17 Mbps transmit with clean 9.7 ms RTT — the difference between an RTSP +stream that lags by seconds and one that keeps its send queue empty. If your +video stalls on this chip while download speed looks fine, measure the upload +direction and try the STA driver. Do not swap the two drivers on a live system +(rmmod/modprobe churn can wedge the dongle MCU until a power cycle) — pick one +at boot. + #### SigmaStar: ``` BR2_PACKAGE_SSW101B diff --git a/en/device-vstarcam-hi3518ev200-gc2023.md b/en/device-vstarcam-hi3518ev200-gc2023.md new file mode 100644 index 00000000..5ef7bcf1 --- /dev/null +++ b/en/device-vstarcam-hi3518ev200-gc2023.md @@ -0,0 +1,107 @@ +# OpenIPC Wiki +[Table of Content](../README.md) + +VStarcam pan/tilt cameras (Hi3518EV200 + GC2023 + MT7601U) +--- + +Notes from a full conversion of a VStarcam indoor pan/tilt camera (P2P UID +prefix `VSTA...`, close sibling of the C8892WIP in the builder device list). +Everything below was verified on real hardware. + +### Hardware + +| Component | Detail | +|-----------|--------| +| SoC | HiSilicon Hi3518EV200 | +| Sensor | GalaxyCore GC2023, 1080p, wired to **MIPI** (2-lane RAW10), SDK I2C address `0x6e` | +| Flash | 16 MB SPI NOR (GD25Q128, `0xc8 0x40 0x18`) | +| Wi-Fi | MediaTek MT7601U on USB (`148f:7601`) | +| PTZ | Two 28BYJ-48-style steppers on GPIOs, pan `31 32 33 34`, tilt `58 59 60 61` | +| Serial | ttyAMA0 at 115200 8N1; U-Boot 2010.06, prompt `hisilicon #`, `bootdelay=1` | + +Vendor firmware serial login is `vstarcam2017` / `20170912` (uid 0) — the +username is not `root`; `root` is always rejected. + +### Installing while keeping the vendor U-Boot + +The vendor U-Boot stores its environment at offset `0x80000`, which sits inside +the kernel region of OpenIPC's standard 16 MB layout — with standard offsets a +later `saveenv` would write the environment straight through the kernel. Keeping +the vendor U-Boot (and therefore the vendor recovery path) works fine with a +shifted layout: + +``` +setenv bootargs 'mem=32M console=ttyAMA0,115200 panic=20 root=/dev/mtdblock2 rootfstype=squashfs init=/init mtdparts=hi_sfc:1024k(boot),3072k(kernel),8192k(rootfs),-(rootfs_data)' +``` + +- Kernel at `0x100000`, rootfs at `0x400000`. The vendor `bootcmd` + (`sf read 0x82000000 0x100000 0x300000; bootm`) needs no change at all — + OpenIPC's uImage uses the same `0x80008000` load address as the vendor kernel. +- `root=/dev/mtdblock2`, not the `mtdblock3` from the upstream install guide — + this layout has no separate `env` partition, so every index shifts down one. +- The overlay partition must be named exactly `rootfs_data` and boot needs + `init=/init`, or you get a read-only system with no persistent config. + +Two U-Boot traps worth knowing before you flash: + +- **This U-Boot has no `tftpdstp`** (`strings` on the boot partition shows only + `tftpblocksize`/`tftptimeout`), so it silently retries against anything that + is not port 69. Run the TFTP server on the standard port. +- The stripped build has no `boot` or `run` commands — invoke the `bootcmd` + steps by hand. + +### Sensor: GC2023 over MIPI + +Use the `gc2023_mipi` sensor identity and `gc2023_mipi_1080p.ini` (2-lane +RAW10, `Isp_Bayer=0`/RGGB). The plain `gc2023` entry in `load_hisilicon` muxes +the parallel VI pads, which disables the MIPI PHY on this board — the tell is +`/proc/umap/vi` showing `IntCnt=0` with `TmgErr=0` and `ccErrN=0` (no VSYNC at +all; bad ini timings would raise the error counters instead). + +Caveat: on the tested unit the closed `libsns_gc2023.so` shipped with the +firmware did not produce frames (VENC timeout — it appears to program the +sensor for DVP output). The working setup used the *vendor's* MIPI sensor +library plus a replay of its 123-write init table, because that library leaves +digital gain (page 0 register `0xb1`) at 0 — which multiplies every pixel to +zero: perfectly valid MIPI framing carrying an all-black raster. If you see +valid framing but black frames, check `0xb1` before suspecting optics or IQ. + +The sensor answers only on the SDK's own I2C (via `ipctool i2cget`, 8-bit +address `0x6e`) — sweeping `/dev/i2c-*` finds nothing and proves nothing. + +### Wi-Fi + +Build with `BR2_PACKAGE_MT7601U_OPENIPC=y` and load `mt7601sta`, not the +mainline `mt7601u` — see the driver note in +[Adding a wifi driver](adding-wifi-driver.md): mainline managed 0.4–1.0 Mbps +transmit on this hardware, the STA driver 15–17 Mbps on the same dongle and AP. + +If both eth0 and wlan0 are up, make sure they do not share a DHCP hostname: +busybox `ifup` sends the same hostname on every interface, and a DHCP server +that keys reservations on hostname will hand both interfaces the same address, +which blackholes the camera (ARP answered by the wrong interface). + +### PTZ + +`fw_setenv gpio_motors "31 32 33 34 58 59 60 61"` drives the head with the +`gpio-motors` package. The pins came from the vendor's `motogpio.ko`: it never +calls `ioremap` and uses static-mapping virtual addresses, so subtracting the +fixed `phys 0x20000000 → virt 0xFE100000` offset turns its literal pool back +into real GPIO banks. There are no working limit switches — the vendor homes by +driving into the mechanical stop and counting steps back out. + +### IR-cut and IR LED + +The IR-cut solenoid is bi-stable: pulse sysfs GPIO **64** for ~200 ms to switch +to day (filter in), pulse GPIO **65** for night (filter out). The IR illuminator +is a plain level on sysfs GPIO **1**. Both filter pins power up muxed as +`SAR_ADC` channels, so nothing responds until the pinmux is set: + +``` +devmem 0x200F0100 32 1 # MUXCTRL_REG64 -> GPIO8_0 +devmem 0x200F0104 32 1 # MUXCTRL_REG65 -> GPIO8_1 +``` + +Do not brute-force sweep GPIOs looking for pins on this board — some lines are +sensor power/reset, and a sweep that leaves one asserted breaks sensor I2C until +a power cycle.