MIPI: combo_dev_attr_t built with raw_data_type=0 / wrong enIntfMode; ignored .ini values (cv200 / OV2735)

[moontwister]

Summary

On hisilicon-hi3516cv200 (verified on Hi3518EV200 + OV2735, 2-lane MIPI RAW10), majestic appears to skip the sensor .ini's [mipi] section when building the kernel ioctls that configure the MIPI receiver block. Two ioctls land with wrong / uninitialized values, no frames flow, and majestic logs the familiar Timeout from venc channel 0 / ERR_ISP_? cascade.

Symptom

• /proc/driver/hi_mipi stays at boot defaults (LaneNum=4, PhyMode=CMOS, DataType=N/A) instead of the sensor's LaneNum=2 RAW10 MIPI — i.e. the MIPI RX block is never actually configured.
• ISP IRQ count = 0, VI IntCnt = 0, no frames reach VENC.
• Vendor firmware on the same hardware produces LaneNum=2 / RAW10 / MIPI (confirmed via a vendor-FW round-trip flash and snapshot diff).

Root cause (two ioctls)

After tracing with an LD_PRELOAD shim around ioctl() (source attached below), majestic's calls to two ioctls arrive with wrong values:

1. HI_MIPI_SET_DEV_ATTR (ioctl 0x41306d01, _IOW('m', 1, combo_dev_attr_t))

The combo_dev_attr_t is built with:

• input_mode = 0 (MIPI — correct, taken from .ini input_mode)
• mipi_dev_attr.raw_data_type = 0 ← uninitialized / not from .ini data_type
• mipi_dev_attr.lane_id[] = all zeros / unset ← not from .ini lane_id

Kernel rejects raw_data_type = 0 with invalid raw_data_type, must be in [2,5). Valid values are RAW_DATA_10BIT=2, RAW_DATA_12BIT=3, RAW_DATA_14BIT=4.

The .ini has these fields populated (after #2155 lands on cv200) — they should drive the struct.

2. VIU_DEV_ATTR_SET (ioctl 0x40804900)

The VI_DEV_ATTR_S arrives with enIntfMode != VI_MODE_MIPI. Vendor firmware sets enIntfMode = 5 (VI_MODE_MIPI) and au32CompMask[0] = 0xfff00000 (10-bit data on bits 12-21). Majestic uses the default initializer / a value appropriate for parallel sensors, even when .ini input_mode = 0.

What the shim does

// HI_MIPI_SET_DEV_ATTR — fix raw_data_type + lane_id
if (combo_dev_attr.input_mode == 0 /* MIPI */) {
    combo_dev_attr.mipi_dev_attr.raw_data_type = 2;          // RAW_DATA_10BIT
    combo_dev_attr.mipi_dev_attr.lane_id[0..1] = {0, 1};     // 2-lane
    combo_dev_attr.mipi_dev_attr.lane_id[2..7] = {-1, ...};  // disabled
}

// VIU_DEV_ATTR_SET — fix enIntfMode + comp mask
if (intf != 5) {
    vi_dev_attr.enIntfMode = 5;                              // VI_MODE_MIPI
    vi_dev_attr.au32CompMask[0] = 0xfff00000;                // RAW10 alignment
}

After the shim is loaded: /proc/driver/hi_mipi flips to LaneNum=2 RAW10 MIPI, mipi int IRQs fire, ISP IRQs climb, VI receives frames, RTSP serves clean H.264 1080p.

Suggested fix

For MIPI sensors (input_mode = 0), majestic should populate combo_dev_attr.mipi_dev_attr from the .ini's [mipi] section:

• raw_data_type ← [mipi] data_type (RAW_DATA_* enum, .ini values match the kernel enum exactly)
• lane_id[] ← [mipi] lane_id (pipe-separated, -1 = disable)

And the VI enIntfMode / au32CompMask should be derived from [mode] input_mode and [mipi] data_type respectively (the comp-mask values are standard per RAW bit-width on cv200).

cv300 already works because its ov2735_i2c_1080p.ini has correct values and its majestic build appears to respect them; cv200 majestic does not.

Hardware / repro

• Camera: TP-Link Kasa KC110 (Hi3518EV200, OV2735 MIPI 2-lane, RTL8188FU). Same symptom probably affects other Hi3518EV200 + OV2735 cameras.
• Firmware: OpenIPC hi3518ev200_ultimate, with OpenIPC/firmware#2154 and #2155 (load_hisilicon ov2735 case + .ini fixes — without those the sensor doesn't even reach the MIPI ioctl stage).
• Workaround: LD_PRELOAD shim (source). Reproducible by unset LD_PRELOAD; /etc/init.d/S95majestic restart — symptoms return instantly.

Context

Came out of a longer reverse-engineering effort to bring up OV2735 on Hi3518EV200 (full diagnostic writeup here). Happy to provide more disasm / register dumps if useful. The shim is intentionally not being upstreamed — flagged as such in the closed OpenIPC/firmware#2152 where @widgetii correctly pointed out that the right fix lives here in majestic.

🤖 Generated with Claude Code

[widgetii]

@moontwister — a master build is up with two relevant changes for this case:

1. Fail-fast if [mipi] data_type is missing (and [mode] raw_bitness isn't set to derive it from) — instead of silently sending raw_data_type=0 and letting hi_mipi reject it with a generic error.

2. Pre-ioctl diagnostic log on Gen 2/3/4, mirroring what Gen 5 already had. On Gen 2, just before HI_MIPI_SET_DEV_ATTR:

   SET_DEV_ATTR: input_mode=N raw_data_type=N lanes=[A,B,C,D]
   

   Exactly the data your shim currently reverse-engineers to capture.

The change does not ship sensor .ini files (those still belong in the firmware sensor package) and does not add a per-sensor table in majestic.

Build

• master+bcf6700, 2026-05-28, hi3516cv200/lite (Hi3518EV200 family — same SoC as KC110)
• https://openipc.s3.eu-west-1.amazonaws.com/majestic.hi3516cv200.lite.master.tar.bz2
• meta: https://openipc.s3.eu-west-1.amazonaws.com/majestic.hi3516cv200.lite.master.tar.meta

Procedure

With LD_PRELOAD shim unset and your post-#2155 .ini in place:

tar -xjf majestic.hi3516cv200.lite.master.tar.bz2
cp majestic-hi3516cv200/majestic /usr/bin/majestic
/etc/init.d/S95majestic restart
logread | grep -E 'SET_DEV_ATTR|data_type is required|input_mode .* disagree'
cat /proc/driver/hi_mipi | head

Three outcomes I expect, with what each one tells us

Log shows	Diagnosis	Next fix
[mipi] data_type is required for MIPI sensors	The post-#2155 .ini is still missing data_type.	Firmware-side .ini fix.
SET_DEV_ATTR: ... raw_data_type=3 lanes=[0,1,-1,-1], kernel accepts, but frames garbled / /proc/driver/hi_mipi shows RAW12	The .ini's data_type = 3 (RAW12) is wrong for OV2735's RAW10. majestic is faithfully passing what the .ini says.	Firmware-side: change data_type = 3 → 2 in ov2735_i2c_1080p.ini. Note #2155 changed input_mode and lane_id but left data_type as-is.
SET_DEV_ATTR: ... raw_data_type=0 lanes=[0,0,0,0] despite a .ini with both keys correct, or the ioctl still fails with the value the log shows being in range	Genuine ingestion / struct-offset bug not yet characterized.	Attach the logread snippet + the actual .ini you ran with and I'll dig further on the cv200 SDK header side.

Thanks for the very precise shim write-up — the field offsets and shim semantics made the diagnostic-log column choices trivial.

[moontwister]

Tested on KC110 (Hi3518EV200 + OV2735) with the master+bcf6700 build — the master build fully fixes this. With the right .ini values, the shim becomes unnecessary; no majestic code change is needed.

Summary

majestic was building combo_dev_attr_t correctly all along; it was faithfully passing what the .ini said. The .ini itself had three wrong values that the master build's new diagnostic log + fail-fast made obvious:

.ini field	Was	Should be (per vendor / sensor capabilities)	Why
[mode] input_mode	4	0 (INPUT_MODE_MIPI)	4 is unused; MIPI is 0. Fixed in OpenIPC/firmware#2155.
[vi_dev] Input_mod	2 (VI_INPUT_MODE_DIGITAL_CAMERA)	5 (MIPI)	Triggers the new disagree-check (your fail-fast). Not yet in #2155 — adding.
[mipi] data_type	3 (RAW_DATA_12BIT)	2 (RAW_DATA_10BIT)	OV2735 outputs RAW10. Not yet in #2155 — adding.
[mipi] lane_id	0|1|2|3|-1|...	0|1|-1|-1|...	OV2735 is 2-lane MIPI on cv200. Fixed in #2155.

Test sequence on master+bcf6700

Step 1: original cv200 .ini, no shim → fail-fast on Input_mod

ERROR sensor_config: [mode] input_mode (0) and [vi_dev] Input_mod (2)
disagree; expected Input_mod=5 for this input_mode

The new validation caught it perfectly. This is a fourth outcome not in your three-row table; worth adding (".ini [vi_dev] Input_mod doesn't agree with [mode] input_mode").

Step 2: Input_mod=5 patched, data_type=3 + 1-lane unchanged → master sends what .ini says

SET_DEV_ATTR: input_mode=0 raw_data_type=3 lanes=[0,-1,-1,-1]

/proc/driver/hi_mipi: LaneNum=1 RAW12 MIPI. Sensor init OK, RTSP up. This matches your outcome #2 exactly.

Step 3: also patched data_type=3→2 and lane_id=0|-1...→0|1|-1... → vendor-correct

SET_DEV_ATTR: input_mode=0 raw_data_type=2 lanes=[0,1,-1,-1]

/proc/driver/hi_mipi: LaneNum=2 RAW10 MIPI (matches vendor diagnostic snapshot). Sensor init OK, ISP IRQs climbing (90+/s), VENC IRQs climbing, VPSS sending 1469 frames to VENC in test window.

Conclusion

The shim was working around the symptom of a wrong .ini, not a majestic bug. Master is correct. Closing on the majestic side as soon as #2155 is extended with the two missing .ini fixes and merges; the shim package can then be deleted entirely.

Updating #2155 now to add the two missing fields. Big thanks for the diagnostic-log addition — it converted what would have been hours of disasm into a 10-minute three-step ladder.

[widgetii]

Thanks for the precise 3-step walk through @moontwister — that's exactly the kind of validation feedback that makes the diagnostic-log addition worth its weight.

You're right that the table should have had a 4th row for the input_mode ↔ Input_mod disagree case — I'll keep that in mind next time I'm landing a fail-fast pair. Glad both new code paths (disagree-check and pre-ioctl log) caught real bugs in the wild on first contact.

No further change needed on the majestic side. Closing here; the followup work is on the firmware .ini (#2155 v2 with the two remaining fields), after which the kc110-mipi-shim Buildroot package can be deleted entirely.