EVK Supported Cameras

Renesas RZV EVK support MIPI Camera Module

Video4Linux 

Video4Linux (V4L2) is the primary framework in Linux for handling video capture devices, including MIPI and USB camera modules (e.g., CSI-2 connected cameras). Here’s how V4L2 is used to configure and interact with such cameras:

In the examples below a MIPI Camera and USB Camera attached to the EVK

Verify Camera Detection

Example Output ... ( both MIPI and USB Camera Attached)

Get Camera Topology/Pipeline

For MIPI-CSI Cameras it is necessary to examine the topology/pipeline ( Camera Module → MIPI-CSI → CRU → CRU Output ). This information is related to the Device Tree ( ports and endpoints).

Get Supported Formats and Resolutions

Below is how to get the supported Formats of Camera and CRU.

USB Camera Supported: Formats, Resolutions, and fps

MIPI-CSI CRU Supported: Formats

NOTE: See Change CRU Output

MIPI-CSI Camera Module : Formats and Resolutions

Get Camera and RZ CRU Parameters

Check the MIPI Camera module supported formats.

MIPI-CSI Camera Pipline Configuration (media-ctl)

Key Points:

1. media-ctl is part of the v4l-utils package, which provides tools for working with V4L2 devices.

2. It interacts with the Linux Media Controller API (MC API), a subsystem that handles complex media device topologies (e.g., cameras, sensors, encoders, and their interconnections).

3. V4L2 focuses on video capture and output, while Media Controller manages the entire pipeline (sensors, ISP, DMA engines, etc.).

4. Use Case: media-ctl configures routes, formats, and links between components (e.g., connecting a camera sensor to an ISP in the pipeline) before V4L2 applications (like v4l2-ctl or GStreamer) use the device.

RZV Command Break Down

RZV2H and RZV2N MIPI Camera

Command 1: Reset the Media Pipeline

media-ctl -d /dev/media0 -r

• -d /dev/media0: Specifies the media device to configure (here, /dev/media0).

• -r: Resets all links in the pipeline (disconnects existing routes).
  (Useful to start from a clean state before reconfiguring.)

Command 2: Link CSI-2 Output to CRU Input

media-ctl -d /dev/media0 -l "'rzg2l_csi2 16000400.csi20':1 -> 'CRU output':0 [1]"

Breakdown:

• -d /dev/media0: Specifies the media device (here, /dev/media0).

• -l: Creates a link between two pads in the pipeline.

• 'rzg2l_csi2 16000400.csi20':1:

  • rzg2l_csi2 16000400.csi20: The CSI-2 receiver entity (RZ/G2L-specific).

  • :1: Refers to output pad 1 of the CSI-2 receiver.

• -> 'CRU output':0:

  • CRU output: The Capture Resolution Unit (CRU) entity.

  • :0: Refers to input pad 0 of the CRU.

• [1]: Enables the link ([0] would disable it).

Purpose:

This command routes video data from the CSI-2 receiver's output to the CRU's input for further processing (e.g., scaling, cropping).

Command 3: Set Format on CSI-2 Output Pad

media-ctl -d /dev/media0 -V "'rzg2l_csi2 16000400.csi20':1 [fmt:UYVY8_2X8/1920x1080 field:none]"

Breakdown:

• -V: Sets a format (fmt) on a pad.

• 'rzg2l_csi2 16000400.csi20':1: Targets output pad 1 of the CSI-2 receiver.

• [fmt:UYVY8_2X8/1920x1080 field:none]:

  • UYVY8_2X8: Pixel format (YUV 4:2:2, packed as UYVY).

  • 1920x1080: Camera Module resolution.

  • field:none: Progressive video (non-interlaced).

Purpose:

Configures the CSI-2 receiver to output video in YUV422 (UYVY) format at the resolution defined by 1920x1080.

Command 4: Set Format on IMX462 Sensor Output

media-ctl -d /dev/media0 -V "'imx462 0-001f':0 [fmt:UYVY8_2X8/1920x1080 field:none]"

Breakdown:

• 'imx462 0-001f':0: Targets output pad 0 of the IMX462 camera sensor.

• [fmt:UYVY8_2X8/1920x1080 field:none]:

  • Same format/resolution as above to ensure compatibility.

Purpose:

Configures the IMX462 sensor to output video in YUV422 (UYVY) at the same resolution as the CSI-2 receiver.

Key Points:

1. Pipeline Flow:

   IMX462 Sensor → CSI-2 Receiver → CRU

   • The sensor (imx462) sends data to the CSI-2 receiver (rzg2l_csi2).

   • The CSI-2 receiver forwards it to the CRU (CRU output).

2. Format Matching:

   • Both the sensor and CSI-2 output are set to UYVY8_2X8 with the same resolution.

   • Mismatches will cause pipeline errors (e.g., "EPIPE" in GStreamer).

3. Resolution (1920x1080):

   • Defines the camera resolution.

4. Why field:none?

   • Indicates progressive video (no interlacing).

5. rzg2l_csi2 16000400.csi20

   1. 16000400 this is the base register address for the RZV CRU

   2. RZV2N CRU0 : 16000400 CRU1: 16010400

   3. RZV2H CRU0 : 16000400 CRU1: 16010400, CRU2: 16020400,  CRU2: 16030400,

Setting the CRU Output

This section explains how to use the CRU Image Processing Block ( Blue ) in the RZV.
A list of the supported CRU formats ( BGR3 ) can be found here.

Open

Terminology

• Device Node Differences

  • /dev/videoX - Video Device Node

    • Purpose: Main interface for video data streaming and user-facing controls

    • Represents: Either a capture device (camera) or output device (display)

    • Used for:

      • Configuring stream formats (pixel format, resolution)

      • Allocating and managing video buffers

      • Starting/stopping video streaming

      • Basic controls (brightness, contrast, etc.)

    • Users: Applications that actually process video data (e.g., ffmpeg, gstreamer, custom apps)

  • /dev/v4l-subdevX - Sub-device Node

    • Purpose: Interface for hardware component configuration

    • Represents: Individual hardware blocks in the pipeline (sensors, CSI-2 receivers, scalers, etc.)

    • Used for:

      • Configuring subdevice-specific parameters

      • Setting formats on individual pads

      • Low-level hardware control

    • Users: Mainly system integrator, not end-user applications

  • /dev/mediaX - Media Controller Device Node

    • Purpose: Pipeline topology management

    • Represents: The entire media device and its internal graph

    • Used for:

      • Discovering the hardware pipeline

      • Creating/enabling/disabling links between components

      • Querying the connection graph

    • Users: Pipeline configuration tools and framework initialization

• Virtual Channels

  • Virtual Channel (VC):

    • Used to multiplex multiple logical data streams over a single physical MIPI CSI-2 lane.

    • Each data stream (e.g., from different sensors) can be assigned a unique VC identifier (0–3 in standard CSI-2, but extensions allow more).

    • Helps in distinguishing different data sources when multiple sensors share the same MIPI interface.

  • Stream Virtual Channel (SVC):

    • An extension introduced in MIPI CSI-2 v2.0+ to support multiple independent data streams (e.g., from a single sensor that outputs multiple types of data, like RGB + depth).

    • Allows a single physical sensor to transmit multiple logical streams (e.g., video + metadata) over the same VC by further subdividing it.

    • Uses Data Type (DT) and Virtual Channel ID (VC-ID) to differentiate streams.