GC2023 over MIPI on hi3516cv200: platform gaps, closed-lib behavior, and the recovered vendor init table

[phedoreanu]

Findings from bringing up a VStarcam Hi3518EV200 camera (GC2023 wired to MIPI CSI-2, 2-lane RAW10) on OpenIPC, offered as raw material for proper GC2023 support — ideally an open-source driver like the recent OV2710 work (#2035, #2038, #2042). Everything below was measured on real hardware.

1. No GC2023 config ships. hi3518ev200_ultimate ships libsns_gc2023.so, but none of the 25 files in /etc/sensors is a gc2023 ini, so majestic dies with No matches for 'gc2023_i2c' in /etc/sensors → Cannot start SDK → segfault. (The only gc2023 ini anywhere in the org, glutinium's gc2023_1080p_line.ini, is a byte-for-byte copy of the OV9712 720p template — its values are not evidence about this sensor.)

2. load_hisilicon breaks MIPI-wired boards. The gc2023 entry muxes the parallel VI pads (0x200f007c..0x200f0094), which disables the MIPI PHY. A diagnostic worth writing down: /proc/umap/vi showing IntCnt=0 with TmgErr=0 and ccErrN=0 means wrong bus, not wrong timings — bad ini timings raise the error counters; a dead PHY gives zero of everything. A companion PR adds a gc2023_mipi identity following the OV2710 precedent, leaving the DVP entry untouched.

3. The shipped closed lib produces no frames on this MIPI hardware. Three libsns binaries tested on the same unit, same MIPI ini, same fixed pinmux:

library	frames	writes digital gain 0xb1
vendor MIPI libsns_gc2023.so	yes	no — leaves it 0
vendor DVP libsns_gc2023_dvp.so	none (VENC timeout)	yes, 0x01
OpenIPC libsns_gc2023.so	none (VENC timeout)	yes, 0x01

The OpenIPC lib drives the sensor over I2C fine (it writes 0xb1), but appears to program it for DVP output.

4. The black-frame trap: digital gain 0xb1. The vendor MIPI lib leaves page-0 register 0xb1 (digital gain, integer part) at 0 — every pixel multiplied to zero, i.e. perfectly valid MIPI framing carrying an all-black raster. The decisive observation: ISP output was a pure constant tracking the configured luminance with ~8 distinct values and zero noise — real sensor data always carries noise, which rules out the whole optics/IR-cut/IQ family in one measurement. Writing 0xb1 = 0x01 restores the picture instantly. Any future open driver must initialize this register.

5. The vendor lib also breaks ISP AE. It feeds the AE nonsense limits (MaxLine=2), and the per-frame register writes the ISP commands never reach the sensor — exposure stays at the init table's 1014 lines forever (observed: AE commanding Line=2 with Error=-196 while i2cget 0x03/0x04 reads 0x3f6). A userspace loop closing ISP OriAve → exposure lines over I2C works as a stopgap; an open-source cmos.c would fix this properly.

6. The recovered init table. sensor_linear_1080p30_init from the vendor lib, recovered by disassembling and emulating its mov r1,#val; mov r0,#reg; bl sensor_write_register sequence — 123 writes, order-sensitive (0xfe is the page select). MIPI page 3 carries 0x01=0x5F, 0x10=0x91, 0x12/0x13=0x0960 (2-lane, RAW10). Happy to contribute it in whatever form fits — open driver table, docs, or a follow-up PR.

GC2023 init table — 123 writes, in order

0xf2 0x00
0xf6 0x00
0xfc 0x06
0xf7 0x01
0xf8 0x07
0xf9 0x06
0xfa 0x00
0xfc 0x0e
0xfe 0x00
0x03 0x03
0x04 0xf6
0x05 0x02
0x06 0xc6
0x07 0x00
0x08 0x10
0x09 0x00
0x0a 0x00
0x0b 0x00
0x0c 0x00
0x0d 0x04
0x0e 0x40
0x0f 0x07
0x10 0x88
0x17 0x54
0x18 0x02
0x19 0x0d
0x1a 0x18
0x20 0x54
0x23 0xf0
0x24 0xc1
0x25 0x18
0x26 0x64
0x28 0xe8
0x29 0x08
0x2a 0x08
0x2b 0x48
0x2f 0x40
0x30 0x99
0x34 0x00
0x38 0x80
0x3b 0x12
0x3d 0xb0
0xcc 0x8a
0xcd 0x99
0xcf 0x70
0xd0 0x9c
0xd2 0xc1
0xd8 0x80
0xda 0x28
0xdc 0x24
0xe1 0x14
0xe3 0xf0
0xe4 0xfa
0xe6 0x1f
0xe8 0x02
0xe9 0x02
0xea 0x03
0xeb 0x03
0xfe 0x00
0x80 0x5c
0x88 0x73
0x89 0x03
0x90 0x01
0x92 0x00
0x94 0x00
0x95 0x04
0x96 0x38
0x97 0x07
0x98 0x80
0xfe 0x00
0x40 0x22
0x43 0x07
0x4e 0x3c
0x4f 0x00
0x60 0x00
0x61 0x80
0xfe 0x00
0xb0 0x58
0xb1 0x01
0xb2 0x00
0xb6 0x00
0xfe 0x01
0x01 0x00
0x02 0x01
0x03 0x02
0x04 0x03
0x05 0x04
0x06 0x05
0x07 0x06
0x08 0x0e
0x09 0x16
0x0a 0x1e
0x0b 0x36
0x0c 0x3e
0x0d 0x56
0x0e 0x5e
0xfe 0x02
0x40 0x40
0x81 0x05
0xfe 0x01
0x54 0x77
0x58 0x00
0x5a 0x05
0xfe 0x03
0x01 0x5f
0x02 0x10
0x03 0x9a
0x10 0x91
0x11 0x2b
0x12 0x60
0x13 0x09
0x15 0x06
0x36 0x88
0x21 0x08
0x22 0x02
0x23 0x10
0x24 0x01
0x25 0x10
0x26 0x04
0x29 0x03
0x2a 0x04
0x2b 0x04
0xfe 0x00

Practical notes for anyone reproducing: the sensor answers only on the SDK's own I2C (ipctool i2cget, 8-bit address 0x6e) — sweeping /dev/i2c-* finds nothing and proves nothing; and while majestic runs, its per-frame sensor writes reset the page select, so any multi-step register work must stop majestic first.