MIPI CSI Camera Bring-Up on Embedded Linux: A Practical Checklist
A new image sensor on a custom board rarely works on the first boot. Across camera bring-ups on Rockchip and other SoCs, the same handful of issues account for most of the lost days. This is the order I check things in, from the hardware up. 1. Prove the hardware before touching the driverConfirm the sensor's power rails come up in the order its datasheet asks for, the master clock is present at the right frequency, and the reset and power-down GPIOs are driven to the correct levels. Then...
A new image sensor on a custom board rarely works on the first boot. Across camera bring-ups on Rockchip and other SoCs, the same handful of issues account for most of the lost days. This is the order I check things in, from the hardware up.
1. Prove the hardware before touching the driver
Confirm the sensor's power rails come up in the order its datasheet asks for, the master clock is present at the right frequency, and the reset and power-down GPIOs are driven to the correct levels. Then check that the sensor answers on I2C at its expected address and that you can read its chip ID register. If the chip ID read fails, nothing above this layer will work.
2. Get the device tree and media graph right
The sensor node, its endpoint and the receiver endpoint must agree on the number of data lanes and the link frequency. A mismatch here typically shows up as stream-on succeeding while no frames ever arrive. Use media-ctl -p to confirm every entity in the pipeline is present and every link is enabled.
3. Capture one raw frame before any tuning
Use v4l2-ctl to stream a few raw frames to a file and inspect them offline. A frame with a strong green or magenta cast usually means the Bayer order is wrong. Shifted or torn lines point at a resolution, blanking or timing mismatch between the sensor mode and the receiver.
4. Only then move to ISP and image quality tuning
Once raw capture is stable, bring in the ISP pipeline: auto exposure, white balance, lens shading, noise reduction and sharpening. Most SoC vendors ship a tuning tool for this. Tuning on top of an unstable raw pipeline wastes time, because every fix gets masked by the underlying fault.
The short checklist
- Power sequencing, clock and reset/power-down GPIOs verified on a scope
- Chip ID read back over I2C
- Lane count and link frequency identical in sensor and receiver endpoints
- media-ctl shows the full pipeline linked
- Raw frames captured and checked for Bayer order and timing
- ISP and IQ tuning started only after raw capture is stable
Most camera bring-up delays trace back to power sequencing, device tree endpoints or the wrong Bayer order.
Stuck on a sensor port or a BSP that will not stream? Send a short project brief and I will tell you where I would look first.