SSC377 + SC4336P: MIPI receive pipeline never initializes; VIF unmask fails

[hsand]

I've been trying to get the IMOU Bullet 3 working, below is Claude's summary of the issue.

Hardware

• SoC: SigmaStar SSC377 (infinity6c family, INFINITY6C SSC027A-S01A per DTB machine model)
• Sensor: SmartSens SC4336P (4MP, 2-lane MIPI), chip ID 0x429c (regs 0x3107/0x3108 → 0x9c 0x42)
• I2C: bus 1, slave address 0x30
• Reference design: Stock firmware identifies this as a "377 project" board with the sensor on Pad2 per its own init script comment

Software

• Firmware: OpenIPC 2.6.x-lite, built 2026-05-14
• Kernel: 5.10.61 PREEMPT ARMv7 (single-core)
• Majestic: master+501058e, built 2026-05-13
• Sensor driver: sensor_sc4336p_mipi.ko from sigmastar-osdrv-infinity6c

Symptom

Majestic starts, the sensor registers correctly with the SDK at Sensor index 0: 2560x1440@30fps, ISP buffers allocate, then MhalCameraOpen fails at the VIF stage:

[MI WRN] [120]:  MHal_VIF_InputMask vif dev 0 unmask fail
[MI WRN] [3849]: EnqueueAsyncOutputTask costs 1040312us [M6:D0:P0]
[CMDQ] cmdq(0) ERR: WAIT_TRIG_TIMEOUT (0x00000400)
[CMDQ] Wait command timeout. Trigger_Bus Bit [0] Event [ISP0_GP_INT2]
[MI WRN] [2402]: [scl0_P0_MAIN] inputtask's fence is not finished more than 2070ms
[MI WRN] [2402]: [isp0_P0_MAIN] inputtask's fence is not finished more than 2090ms
... fence timeouts grow indefinitely

No frames ever reach the ISP. /image.jpg returns nothing.

Root cause analysis (best understood so far)

The CSI receivers are never configured, even though VIF has been told their source:

/sys/devices/virtual/mstar/vif0/vif_info:
== VIF DEV-0 ==
INTF_MODE = 4
CH_EN: 1
SRC: MIPI0
INPUT_FMT: RGB
PIX_FMT: 10 bits
CROP_EN: 1
CROP_START_X: 0 - 2559
CROP_START_Y: 0 - 1439

/sys/devices/virtual/mstar/csi0/csi_info:
== MIPI0 info ==   IDEAL_RECV_SIZE = 0, 0   CUR_RECV_SIZE = 0, 0
== MIPI1 info ==   IDEAL_RECV_SIZE = 0, 0   CUR_RECV_SIZE = 0, 0
== MIPI2 info ==   IDEAL_RECV_SIZE = 0, 0   CUR_RECV_SIZE = 0, 0

VIF was configured for the expected 2560×1440 crop window, but IDEAL_RECV_SIZE = 0, 0 on every CSI receiver means CSI was never given dimensions. The failure inside MhalCameraOpen happens between VIF setup and CSI dimension setup — VIF unmask fails, which short-circuits the rest of pipeline initialization.

The sensor itself is correctly initialized (verified via direct I2C reads after driver load):

0x0100 = 0x01            streaming enabled
0x0103 = 0x00            not in standby
0x3018 = 0x3a            MIPI config (programmed, not reset default)
0x3031 = 0x0a            RAW10 format
0x320c/0x320d = 0x0af0   HTS = 2800
0x320e/0x320f = 0x05dc   VTS = 1500 (matches stock vts_30fps exactly)

CSI interrupt counters across all three MIPI receivers are zero — no FRAME_START, FRAME_END, or even error interrupts. The sensor is configured to stream, but with the CSI receivers never enabled, this can't be confirmed at the SoC level.

Comparison with working stock firmware

Stock firmware (Anjvision-style SSC377+SC4336P board, dumped from device, scripts at /usr/etc/imod) does several things OpenIPC's load_sigmastar does not:

Setting	Stock	OpenIPC
srcfg write (pad routing)	srcfg 2 1 2 0 1 1 (Pad2, MIPI, 2-lane, MclkIdx 0, PwdPin + RstPin enabled)	srcfg 0 1 0 0 0 0 (Pad0, MIPI, no lane, no GPIOs)
Sensor driver chmap arg	chmap=4	chmap=1 (same for all 9 sensors in the case statement)
Pre-probe sensor writes	0x440D=0x10, 0x4400=0x11, 10 ms sleep	not present
ISP / MSCL / JPE clocks (2-lane mode)	216 MHz	384 MHz (default clk_idx=0, 320 MHz earlier in log)
mi_common.ko parameters	g_ModParamPath=/usr/config/modparam.json	none
Per-board config	exported from /usr/etc/product.cfg (LANE_NUM, SenMclkMode, etc.)	none
Module structure	split: mi_common, mi_sys, mi_vif, mi_sensor, mi_isp, mi_rgn, mi_aio, mi_ao, mi_ai, mi_ipu, mi_scl, mi_vcodec, mi_venc	unified mi.ko

Stock's imod script comment explicitly states:

"In the 377 project, the Sensor Pad2 connector position is used, this position determines the chmap value at driver load time"

What we tried, and what failed

srcfg value	chmap	Result
0 1 0 0 0 0 (OpenIPC default)	1	Sensor registers → MHal_VIF_InputMask vif dev 0 unmask fail → CMDQ timeout
0 1 2 0 1 1	1	Identical to above — srcfg lane/GPIO changes had no observable effect
2 1 2 0 1 1 (stock value)	4	Sensor never registers; Cannot query sensor index

The fact that altering srcfg lane and pwd/rst fields produces no change is suspect — suggests OpenIPC's sensor_config.ko may be parsing the input but not actually programming the same SoC registers stock's srcfg.ko does.

Confirmed facts

1. The DTB declares both pad 0 and pad 2:
   • /proc/devicetree/.../soc/csi/ and .../soc/vif/ exist with csi_sr0_*, csi_sr2_*, vif_sr0_*, vif_sr2_* properties
   • The kernel CSI driver knows about sensor pad 0 AND sensor pad 2 (visible in /sys/devices/virtual/mstar/csi0/csi_dbg_mask)
   • Pad 1 is absent from both DTB and the CSI driver's debug list
2. The OpenIPC sensor driver accepts module params lane_num, chmap, hdr_lane_num, i2c_slave_id, mclk, sensor_module_version, and applies them (cat /sys/module/.../parameters/lane_num reads back the value supplied at insmod).
3. The SoC has three MIPI receivers (MIPI0, MIPI1, MIPI2) exposed via /sys/devices/virtual/mstar/csi0/csi_info.
4. Ghidra analysis of stock sc4336p_MIPI.ko confirms 2-lane operation as the canonical mode: function pCus_init_mipi2lane_linear_4M30fps is referenced in the cus_camsensor_init_handle_linear setup; the .data section explicitly initializes lane_num=2 and hdr_lane_num=4.

Open questions

1. Why does chmap=4 (stock's value for pad-2 wiring) prevent sensor registration in OpenIPC's build, when the DTB and CSI driver both declare pad 2 support?
2. Does OpenIPC's sensor_config.ko actually program the SoC's pad multiplexer / MIPI routing the way stock's srcfg.ko does, or is it a stub that consumes input without effect? Identical behavior with three different srcfg payloads strongly suggests the latter.
3. Are the stock pre-probe writes (0x440D=0x10, 0x4400=0x11) required to bring the SC4336P MIPI block out of some default-disabled state? They appear in stock's pCus_init_mipi2lane_linear_4M30fps before the chip-ID probe, suggesting they may be needed for any subsequent MIPI activity.
4. Why does VIF unmask fail in MhalCameraOpen despite the sensor being correctly initialized and ready to stream? This is inside the proprietary mi.ko; outside debugging can't reach it.

Suggested investigation

• Inspect MHal_VIF_InputMask in the SDK source — what preconditions must be satisfied before unmask succeeds?
• Verify sensor_config.ko's write handler actually programs SoC pad mux / MIPI routing registers vs. just parsing input.
• Check whether the sensor driver's init register table includes the pre-probe 0x440D / 0x4400 writes that appear in stock's binary.
• Consider whether the chmap=1 default in load_sigmastar is correct for hardware variants where the sensor is wired to a pad other than Pad0.

Environment to reproduce

• OpenIPC lite image generated from ssc377_lite_defconfig (or ssc377d_lite_defconfig)
• Any SSC377+SC4336P board manufactured to the Anjvision reference design (most current factory-firmware SC4336P + SSC377 cameras appear to use this layout)
• Sensor detected via i2cdetect -y -r 1 at address 0x30; i2ctransfer -f -y 1 w2@0x30 0x31 0x07 r2 returns 0x9c 0x42

Attached / available on request

• Full dmesg from boot through failure
• logread output covering majestic startup and fence-timeout sequence
• Ghidra decomp of stock cus_camsensor_init_handle_linear and pCus_init_mipi2lane_linear_4M30fps
• Stock imod script and modparam.json
• Strings dump of stock sc4336p_MIPI.ko confirming exported parameters

logread.txt
imod.txt
dmesg.txt