MIPI CSI on a devkit marked not supported: custom carrier path

Your devkit boots, its reference design opens in your CAD tool, and the camera PHY page carries a red note: NOT SUPPORTED, NOT VALIDATED. You wanted to bring a camera in over MIPI CSI, perhaps through a serializer and deserializer pair, and the note reads like a dead end. It is not. What follows separates what the annotation states from what it does not, explains why developer kits of this class validate camera-over-Ethernet instead, and sets out what a custom carrier board must get right: lane rate, routing, sensor driver, device tree and pixel path. You finish with a decision you can defend — spin a carrier that uses the SoC's MIPI CSI lanes, or put a GigE or USB3 board-level camera on the ports the kit already validates.

What NOT SUPPORTED, NOT VALIDATED states

Vendor documentation carries three levels of commitment. A supported interface comes with drivers, documentation and a support channel: ask questions, get answers. A validated interface adds testing: the vendor has run that exact configuration end to end, at the stated data rates, and will reproduce failures. The pair NOT SUPPORTED, NOT VALIDATED says this interface sits outside both commitments on this board.

Read the note as statements about the devkit, not about the silicon. The kit's carrier does not bring the camera PHY out in validated form, so there is no camera connector you can design against from the kit alone. No validated driver or device-tree configuration ships for it, so the vendor will not debug MIPI attempts on that board. What the note does not say is that the SoC lacks the interface. On this class of SoC the CSI-2 receiver and its D-PHY lanes exist in the design, which is why the vendor's design guide carries a video-input chapter addressed to custom carrier designs. The annotation describes the devkit's validated configuration; the design guide is the vendor telling you the lanes are there for a board you build.

Why developer kits validate Ethernet cameras first

The validated camera path on kits of this class is camera-over-Ethernet: industrial GigE Vision cameras on a standard Ethernet port, enumerated and driven by the camera SDK, with no device-tree or kernel work on your side. The choice is not arbitrary. Ethernet reaches 100 m on ordinary cabling, while MIPI CSI-2 is a board-level link specified for short, length-matched lane runs with no standard connector, so every carrier is its own electrical and mechanical design. A kit that must serve many users validates the interface that works for everyone and marks the per-project one as unvalidated.

For you the consequence is practical: everything the note says about MIPI leaves the Ethernet camera path untouched. That port is tested and supported, and it is the fastest way to move images into the kit today.

What your custom carrier must add

Treat the video-input chapter as the specification for your board: which CSI controller the lanes map to, where the receive clock comes from, and the routing limits the layout must meet. Around the sensor or the deserializer, a minimal carrier adds:

• sensor power rails, sequenced in the order the sensor's data sheet requires;
• a reference clock to the sensor at the frequency its register map expects;
• an I2C bus for control, with the sensor's address on the bus number the driver opens;
• reset and status GPIOs;
• the CSI lane pairs and clock pair, routed as length-matched differential pairs inside the chapter's limits.

Each item maps to a known failure mode: a sensor that powers but never appears on I2C, or one detected but refusing to stream. Run the carrier board compatibility checks before you order the first spin, and select the sensor against the platform, because sensor support decides the driver work.

The lane-rate math that fixes two lanes or four

Do the arithmetic before layout starts, because lane count drives the connector, the routing and the driver's mode table.

CSI-2 carries active pixel data, not blanking, and packet overhead means a lane delivers roughly 80 to 85 % of its line rate as payload; plan on 80 %. The frame-rate estimation method works the same calculation in more detail, including embedded data lines.

Worked example: a 5 MP sensor, 2592 × 1944 active pixels at 30 fps in RAW10.

• payload = 2592 × 1944 × 30 × 10 = 1,511,654,400 bit/s ≈ 1.51 Gbit/s
• two lanes at 80 %: 1,511,654,400 / 2 / 0.80 ≈ 945 Mbit/s per lane
• four lanes at 80 %: 1,511,654,400 / 4 / 0.80 ≈ 472 Mbit/s per lane

MIPI D-PHY line rates commonly run from 80 Mbit/s up to 1.5 Gbit/s per lane, with later revisions reaching 2.5 Gbit/s. Two lanes at 945 Mbit/s sit inside the common range; four lanes at 472 Mbit/s leave margin for temperature and clock tolerance. One number belongs to the SoC rather than the standard: its per-lane maximum can sit below the PHY specification's ceiling, and the design guide prints the value that applies to your lanes.

The software stack you inherit

On a validated kit the vendor ships the driver and the device tree; on your carrier you own three layers. The kernel driver for the sensor covers register map, power sequencing and the mode table that states resolution, data type and lane count. The device-tree overlay binds lanes, I2C bus and address, and clocks to the CSI receiver; when frames never arrive, the CSI mapping troubleshooting flow is where mismatches surface first, and a driver built for a different kernel can leave the overlay unloaded — the missing DTB diagnosis covers that case. The pixel path comes third: a RAW sensor feeds either the SoC's ISP or your own code, and what raw output means without an ISP and the CPU cost of inline ISP processing are both worth reading before you promise a frame rate.

Bring-up follows a predictable sequence: the sensor is missing on I2C first, then detected but silent. Work through the I2C and device-tree checks, then the power, clock and device-tree review, and keep driver, overlay and SDK on one matched version set.

Three ways to get the images in

Weigh the paths before spending hardware budget:

The bridge route trades rate for setup speed: its bandwidth sizing decides whether your sensor's payload fits at all, and what a converter board must include separates production-capable hardware from evaluation parts. Where the sensor must sit remote from the host, a CSI Ethernet extension kit extends the link without a driver on your side.

The Ethernet route needs no board design. A global-shutter, M12-mount GigE board camera that hangs off the kit's validated port:

Hosts with USB3 can take higher frame rates instead, with a 3.1 MP global-shutter board camera running 120 fps at full resolution over C-mount:

Where resolution beats frame rate, the same GigE port carries a 12 MP board camera with 1.6 μm pixels:

Production: keep the validated interface if you can

The custom carrier makes sense when your product is the board. When your product is the inspection cell — camera, light, decision — most teams keep the validated interface into production. Vision controllers take the same Ethernet and USB3 cameras on purpose-built ports and add the light-control channels a cell needs:

The controller class in the card runs a complete cell: its four light channels drive strobing, its LAN and USB3 ports take the board cameras above, and your engineering effort goes into the application instead of a board spin. If the decision should live at the camera end rather than in the controller, edge object detection: SoC camera boards vs smart cameras works through that trade.

When the custom carrier earns its cost

Commit to the MIPI carrier when at least one of these holds:

• the sensor must sit on your own PCB for mechanical reasons — a bore-scope head, a housing behind glass, a pen-sized probe;
• you ship volume where sensor module plus your board lands well below a housed industrial camera per unit, and the engineering amortizes;
• several sensors must be synchronized on one board without extra cabling;
• your team owns hardware and kernel-level software, and a bring-up across one or two revisions fits the schedule.

Take the validated path when the opposites hold: tens of units rather than thousands, one camera, weeks rather than quarters, no kernel engineer on the roster. The bridge and extension-kit routes above sit between the two; treat them as prototypes rather than a production plan.

A devkit decision is reversible: images over Ethernet this quarter and the MIPI carrier in the next hardware revision is a plan, not a compromise.

Checks before you commit to the spin

• Read the video-input chapter end to end before schematic capture; it names the CSI controllers, the lane mapping and the routing limits.
• Run the lane-rate formula for the sensor's worst mode — highest frame rate at highest bit depth — and compare each lane against the SoC's printed maximum.
• Select the sensor against the platform, not its data sheet alone; the platform match decides the driver work.
• Route the lane pairs length-matched, follow the chapter's clock-pair rules, and keep I2C and the reference clock clear of switching regulators.
• Budget the software explicitly: sensor driver, overlay, pixel path decision, matched SDK version.
• Decide raw-into-ISP or raw-into-your-code early, because it changes the driver and the CPU budget together.

The decision

The note does not say MIPI cannot work on the SoC; it says this devkit does not do MIPI and the vendor will not support attempts on that board. If the sensor must live on your PCB, start the custom carrier now: the video-input chapter as your schematic reference, the lane-rate formula to fix two lanes or four, and the driver, overlay and pixel path budgeted from day one. If you need images next month, put a GigE or USB3 board-level camera on the validated ports, prove the application, and fold the MIPI carrier into the next hardware revision.

Browse the board-level cameras for both interfaces, read the systems topic page for the rest of the embedded bring-up guides, or tell us your sensor and volume and we will size the paths with you.