To use the CAM3 slot on the vision mezzanine board, SW2300 switch 1 must be OFF.
This is the default state.
CAM0A works without any DIP switch setting.
IQ-9075-EVK is offered as the core kit.
The core kit supports MIPI CSI cameras only.
GMSL cameras require a separate GMSL mezzanine board connected to the core kit.
Interface
Hardware Path
Status
MIPI CSI
Core kit / main board
Supported
GMSL
External GMSL mezzanine
Supported via add-on board
In the IQ-9075-EVK hardware stack:
The core kit / main board exposes four MIPI CSI (C/D-PHY) connectors
The GMSL mezzanine board exposes four GMSL ports (0 to 3)
IQ-9075-EVK has four CSI PHYs.
Each CSI PHY can be routed to either a MIPI camera port or a GMSL camera port using the DIP switch on the core kit / main board.The switch assignment differs between EVT and DVT/PVT hardware.
EVT Hardware
DVT/PVT Hardware
DIP switch setting for IQ-9075-EVK EVT hardware:
Switch
OFF (Default)
ON
Connection When ON
Connection When OFF
SW2-1
HIGH
LOW
CSI0 → GMSL mezzanine
CSI0 → main board
SW2-2
HIGH
LOW
CSI1 → GMSL mezzanine
CSI1 → main board
SW2-3
HIGH
LOW
CSI2 → GMSL mezzanine
CSI2 → main board
SW2-4
HIGH
LOW
CSI3 → GMSL mezzanine
CSI3 → main board
DIP switch setting for IQ-9075-EVK DVT/PVT hardware:
Any camera can operate independently. A maximum of two cameras can run concurrently with real-time IFE. All four cameras can run concurrently with the Offline IFE feature.
The software supports OX03F10 Bayer and OX03F10 YUV GMSL cameras.
GMSL Port
Supported Resolution / FPS
Sensor
Notes
Port-0
1824 × 1536 @ 30 FPS
OX03F10 Bayer
Four OX03F10 Bayer GMSL cameras can be connected on Port-0. Any one camera can operate independently. All four cameras on a single port can run concurrently using the Per Port Group feature.
Port-2
1920 × 1536 @ 30 FPS
OX03F10 YUV
Four OX03F10 YUV GMSL cameras can be connected on Port-2. Any one camera can operate independently. All four cameras on a single port can run concurrently using the Per Port Group feature.
Port-3
1920 × 1536 @ 30 FPS
OX03F10 YUV
Four OX03F10 YUV GMSL cameras can be connected on Port-3. Any one camera can operate independently. All four cameras on a single port can run concurrently using the Per Port Group feature.
Port-2 + Port-3
1920 × 1536 @ 30 FPS
OX03F10 YUV
Eight OX03F10 YUV GMSL cameras can be connected, four on Port-2 and four on Port-3. Any one camera from each port can operate independently. All eight cameras can run concurrently using the Per Port Group feature.
IQ-8275-EVK is offered in the core kit.
The core kit supports MIPI CSI cameras.
GMSL cameras require a separate GMSL mezzanine board connected to the core kit.
IQ-8275-EVK has three CSI PHYs.
Each CSI PHY can be routed to either a MIPI camera port or a GMSL camera port using the DIP switch on the core kit/main board.The switch assignment differs for EVT and DVT/PVT hardware.
EVT Hardware
DVT / PVT Hardware
DIP switch setting on IQ-8275-EVK EVT hardware:
Switch
ON
OFF (Default)
SW2-1
CSI0 → GMSL mezzanine
CSI0 → main board
SW2-2
CSI1 → GMSL mezzanine
CSI1 → main board
SW2-3
CSI2 → GMSL mezzanine
CSI2 → main board
DIP switch setting on IQ-8275-EVK DVT/PVT hardware:
Any camera can operate independently. Up to two cameras can run concurrently with real-time IFE. All three cameras can run concurrently using Offline IFE.
The software supports OX03F10 Bayer and OX03F10 YUV GMSL cameras.
GMSL Port
Supported Resolution / FPS
Sensor
Notes
Port-0
1824 × 1536 @ 30 FPS
OX03F10 Bayer
Four Bayer GMSL cameras can be connected on Port-0. Any one camera can operate independently. All four cameras on a single port can run concurrently using the Per Port Group feature.
Port-2
1920 × 1536 @ 30 FPS
OX03F10 YUV
Four YUV GMSL cameras can be connected on Port-2. Any one camera can operate independently. All four cameras on a single port can run concurrently using the Per Port Group feature.
IQx7181 EVK provides multiple camera serial interface (CSI) connectors, supporting camera modules with different PHY types and lane configurations.
This enables flexible camera connectivity for bring-up and validation use cases.
Qualcomm Linux supports the following APIs for camera:
GStreamer API
GStreamer is an open-source multimedia framework. Qualcomm provides a GStreamer plugin (qtiqmmfsrc) that allows developers to control the camera subsystem in applications. See Qualcomm GStreamer plugins for more information.
V4L2 API
V4L2 is a framework within the Linux kernel that provides support for video capture, video output, and other multimedia devices. Developers can operate the camera using the V4L2 API. The V4L2 API, which uses the CAMSS driver, is suitable for developers who only need to obtain raw images from the camera.
gst-launch-1.0 is a command-line GStreamer utility used to build and run a GStreamer pipeline. The pipeline is specified as a collection of elements with properties separated by exclamation marks (!).
Connect to the device console using SSH. See How To SSH? for instructions.
1
🗑️ Clear GStreamer Registry
Clear GStreamer registry (if needed)
If a GStreamer command was executed before enabling the camera overlay, the GStreamer registry must be cleared after enabling the camera overlay. Run the following command to clear the registry:
Terminal
rm ~/.cache/gstreamer-1.0/registry.aarch64.bin
2
📉 Tune Log Level
Log Level Tuning (if needed)
Camera use-cases are expected to run on a performance (perf) build for optimal results. On default builds, reduce the kernel console log level as shown below:
Terminal
echo 4 > /proc/sys/kernel/printk
3
⚡ Activate Adreno OpenCL for cam-server
Activate Adreno OpenCL for cam-server (For Advanced Camera Use-cases only)
Before running any Advanced camera use cases like SHDRv2, SHDRv3, Defog, etc., configure the cam-server systemd service to use the Adreno OpenCL ICD library.
1
🛠️ Open the service override
Edit the cam-server systemd unit so it can load a custom environment file.
Ensure that MIPI cameras are connected to CSI slots. The OV9282 MIPI camera should be connected to the CAM 0A slot and the IMX577 MIPI camera should be connected to the CAM3 slot.
This command starts the camera with 720p at 30 FPS configuration. The frame coming from the camera sensor is thrown away by fakesink. If the gst pipeline status is changed to “PLAYING” as shown below, this indicates that the camera is running. Since this command dumps camera frames to fakesink, nothing will be saved on the device.
Log Output
gbm_create_device(187): Info: backend name is: msm_drmSetting pipeline to PAUSED ...Pipeline is live and does not need PREROLL ...Setting pipeline to PLAYING ...New clock: GstSystemClock
This command starts the camera with 720p at 30 FPS configuration and saves it as a video file after h264 video encoding. If the gst pipeline status is changed to “PLAYING”, this indicates the camera is running.To stop the camera, press CTRL+C.
2
Pull recorded content
/opt/mux_avc.mp4 is generated on the device. The recorded content can be pulled from the device by running the following scp command on the host PC:
Press Enter. This command will print the following menu and wait for user input.
Menu
##################################### MENU #####################################============================== Pipeline Controls==============================(0) NULL: Set the pipeline into NULL state(1) READY: Set the pipeline into READY state(2) PAUSED: Set the pipeline into PAUSED state(3) PLAYING: Set the pipeline into PLAYING state==================================== Other====================================(p) Plugin Mode: Choose a plugin which to control(q) Quit : Exit the applicationChoose an option:
3
Take a snapshot
Use the following menu steps to take a snapshot while recording video.
Menu Steps
(1) ready -> (3) Playing -> (p)Plugin Mode : Select (8)camerasrc -> (37) capture-image -> (1): still - Snapshot ->(1) Snapshot count ( 'guint' value for arg1)
4
Stop and retrieve files
To stop the camera, press Enter, press b (back), and then press q (quit). The recorded video file and snapshot images are saved in /opt/. The recorded content can be pulled from the device by running the following scp command on the host PC:
QCS6490 has five CSI PHYs to which you can connect five MIPI cameras.QCS6490 has three IFEs and two IFE Lites. This means you can run three cameras with IFEs and two cameras with IFE Lites. IFE Lites only support raw dumps from the sensor. You can connect mono cameras to the IFE Lites, dump raw frames, and then convert the output to YUV frames using a CHI node.To validate five camera concurrency on the RB3 platform:
1
Connect MIPI cameras
Connect MIPI cameras as described in the following table.
Slot
Camera sensor
CAM 0A
OV9282 mono camera
CAM 0B
OV9282 mono camera
CAM1
IMX577 bayer camera
CAM2
IMX577 bayer camera
CAM3
IMX577 bayer camera
2
Run GST commands for all five cameras concurrently
For OV9282 mono cameras, a separate camera pipeline (RealTimeMonoToYUV) is used. This pipeline uses IFE Lites to dump the raw frame and then convert it to a YUV frame using a CHI node. Use the GST parameter ife-direct-stream=1 to use this camera pipeline. Since it runs with an IFE Lite, 2A is not applied on these cameras.
The QCS6490 maximum encode capability is 4K@30. Thus, the total encode processing from all five cameras has to be under the 4k@30 limit.
Ensure that the camera (MIPI or GMSL) sensor is connected to the IQ-9075-EVK device. You can connect OV9282 MIPI cameras on CSI slots. Connect OX03f10 Bayer GMSL cameras to GMSL Port-0 and OX03f10 YUV GMSL cameras to Port-2 and Port-3.
The following command starts the camera with 720p at 30 FPS configuration. The frame coming from the camera sensor is thrown away by fakesink. If the gst pipeline status is changed to “PLAYING” as shown below, this indicates that the camera is running. Since this command dumps camera frames to fakesink, nothing will be saved on the device.
Log Output
gbm_create_device(187): Info: backend name is: msm_drmSetting pipeline to PAUSED ...Pipeline is live and does not need PREROLL ...Setting pipeline to PLAYING ...New clock: GstSystemClock
This command starts the camera with 720p at 30 FPS configuration and saves it as a video file after h264 video encoding. If the gst pipeline status is changed to “PLAYING”, this indicates the camera is running. To stop the camera, press CTRL+C.
2
Pull recorded content
/opt/mux_avc.mp4 is generated on the device. The recorded content can be pulled from the device by running the following scp command on the host PC:
Press Enter. This command will print the following menu and wait for user input.
Menu
##################################### MENU #####################################============================== Pipeline Controls==============================(0) NULL: Set the pipeline into NULL state(1) READY: Set the pipeline into READY state(2) PAUSED: Set the pipeline into PAUSED state(3) PLAYING: Set the pipeline into PLAYING state==================================== Other====================================(p) Plugin Mode: Choose a plugin which to control(q) Quit : Exit the applicationChoose an option:
3
Take a snapshot
Use the following menu steps to take a snapshot while recording video.
Menu Steps
(1) ready -> (3) Playing -> (p)Plugin Mode : Select (11)camerasrc ->(38) capture-image -> (1): still - Snapshot ->(1) Snapshot count ( 'guint' value for arg1)
4
Stop and retrieve files
To stop the camera, press Enter, press b (back), and then press q (quit). The recorded video file and snapshot images are saved in /opt/. The recorded content can be pulled from the device by running the following scp command on the host PC:
There are four MIPI CSI slots present on the IQ-9075-EVK main board. Connect OV9282 cameras to MIPI CSI ports. You can run any two OV9282 cameras concurrently out of four cameras.Run the following GST command in two different terminals with camera = 0, 1 to validate MIPI camera concurrency. Use different file names when saving the encoded file of each camera.
You can also run all four MIPI cameras concurrently using the offline IFE feature. Refer to Support multi-camera using offline IFE for information on four camera validation.
A single GMSL port contains four slots, allowing connection of four GMSL cameras to a single CSI using different virtual channel IDs. The four cameras connected on one CSI are treated as group. A group of cameras can be run concurrently using the per port grouping feature.
Ensure that the camera (MIPI or GMSL) sensor is connected to the IQ-8275-EVK device. You can connect OV9282 MIPI cameras on CSI slots. Connect OX03f10 bayer GMSL cameras to GMSL Port-0 and OX03f10 YUV GMSL cameras to GMSL Port-2.
The following command starts the camera with 720p at 30 FPS configuration. The frame coming from the camera sensor is thrown away by fakesink. If the gst pipeline status is changed to “PLAYING” as shown below, this indicates that the camera is running. Since this command dumps camera frames to fakesink, nothing will be saved on the device.
Log Output
gbm_create_device(187): Info: backend name is: msm_drmSetting pipeline to PAUSED ...Pipeline is live and does not need PREROLL ...Setting pipeline to PLAYING ...New clock: GstSystemClock
This command starts the camera with 720p at 30 FPS configuration and saves it as a video file after h264 video encoding. If the gst pipeline status is changed to “PLAYING”, this indicates the camera is running. To stop the camera, press CTRL+C.
2
Pull recorded content
/opt/mux_avc.mp4 is generated on the device. The recorded content can be pulled from the device by running the following scp command on the host PC:
Press Enter. This command will print the following menu and wait for user input.
Menu
##################################### MENU #####################################============================== Pipeline Controls==============================(0) NULL: Set the pipeline into NULL state(1) READY: Set the pipeline into READY state(2) PAUSED: Set the pipeline into PAUSED state(3) PLAYING: Set the pipeline into PLAYING state==================================== Other====================================(p) Plugin Mode: Choose a plugin which to control(q) Quit : Exit the applicationChoose an option:
3
Take a snapshot
Use the following menu steps to take a snapshot while recording video.
Menu Steps
(1) ready -> (3) Playing -> (p)Plugin Mode : Select (11)camerasrc ->(38) capture-image -> (1): still - Snapshot ->(1) Snapshot count ( 'guint' value for arg1)
4
Stop and retrieve files
To stop the camera, press Enter, press b (back), and then press q (quit). The recorded video file and snapshot images are saved in /opt/. The recorded content can be pulled from the device by running the following scp command on the host PC:
There are three MIPI CSI slots present on the IQ-8275-EVK main board. Connect OV9282 cameras to MIPI CSI ports. You can run any two OV9282 cameras concurrently.Run the following GST command in two different terminals with camera = 0, 1 to validate MIPI camera concurrency. Use different file names when saving the encoded file of each camera.
You can also run all three MIPI cameras concurrently using the offline IFE feature. Refer to Support multi-camera using offline IFE for information on three camera validation.
A single GMSL port contains four slots, allowing connection of four GMSL cameras to a single CSI using different virtual channel IDs. The four cameras connected on one CSI are treated as group. A group of cameras can be run concurrently using the per port grouping feature.
Ensure that the camera MIPI sensor is connected to the IQ15 device. You can connect IMX577 MIPI cameras on CSI slots.
The following command starts the camera with 720p at 30 FPS configuration. The frame coming from the camera sensor is thrown away by fakesink. If the gst pipeline status is changed to “PLAYING” as shown below, this indicates that the camera is running. Since this command dumps camera frames to fakesink, nothing will be saved on the device.
Log Output
gbm_create_device(187): Info: backend name is: msm_drmSetting pipeline to PAUSED ...Pipeline is live and does not need PREROLL ...Setting pipeline to PLAYING ...New clock: GstSystemClock
This command starts the camera with 720p at 30 FPS configuration and saves it as a video file after h264 video encoding. If the gst pipeline status is changed to “PLAYING”, this indicates the camera is running. To stop the camera, press CTRL+C.
2
Pull recorded content
/opt/mux_avc.mp4 is generated on the device. The recorded content can be pulled from the device by running the following scp command on the host PC:
Press Enter. This command will print the following menu and wait for user input.
Menu
##################################### MENU #####################################============================== Pipeline Controls==============================(0) NULL: Set the pipeline into NULL state(1) READY: Set the pipeline into READY state(2) PAUSED: Set the pipeline into PAUSED state(3) PLAYING: Set the pipeline into PLAYING state==================================== Other====================================(p) Plugin Mode: Choose a plugin which to control(q) Quit : Exit the applicationChoose an option:
3
Take a snapshot
Use the following menu steps to take a snapshot while recording video.
Menu Steps
(1) ready -> (3) Playing -> (p)Plugin Mode : Select (11)camerasrc ->(38) capture-image -> (1): still - Snapshot ->(1) Snapshot count ( 'guint' value for arg1)
4
Stop and retrieve files
To stop the camera, press Enter, press b (back), and then press q (quit). The recorded video file and snapshot images are saved in /opt/. The recorded content can be pulled from the device by running the following scp command on the host PC:
SCP (SSH)
$ scp -r root@[ip-addr]:/opt/<file name> .
GStreamer app support is not enabled in this release.
To use the V4L2 API, flash the Config1 image. For overlay configuration details, see Overlay Configurations.
QCS6490
IQ-9075-EVK
IQ-8275-EVK
IQ615
IQx7181
The V4L2 framework within the Linux kernel supports video devices. It provides an API that allows user space applications to interact with devices such as cameras and video capture cards.More information on V4L2 is available from kernel.org.
Qualcomm supports the V4L2 interface camera ISP driver for raw frame dump functionality in the upstream kernel.
The Qualcomm camera subsystem (CAMSS) driver in the upstream kernel implements the V4L2, media controller, and V4L2 subdev interfaces.Camera sensors using the V4L2 subdev interface in the kernel are supported.The CAMSS driver consists of:
CSIPHY module – Handles the physical layer of the CSI2 receivers. A separate camera sensor can be connected to each CSIPHY module.
CSI Decoder (CSID) module – Handles the protocol and application layers of the CSI2 receivers. A CSID can decode a data stream from any CSIPHY.
Video Front End (VFE) module – Represents the Image Front End (IFE) that contains Raw Dump Interface (RDI) input interfaces that bypass the image processing pipeline. The VFE also contains the AXI bus interface which writes output data to memory.
The CAMSS driver implements the V4L2 interface. Each CSIPHY, CSID, and VFE module is represented by a single V4L2 sub-device.As shown in the following diagram, each CSIPHY can connect to each CSID. Each CSID can connect to each VFE. Each RDI port has an individual video node.
CAMSS V4L2 drivers are in <kernel_root>/drivers/media/platform/qcom/camss. <kernel_root> is the directory of the Linux kernel.
The expected result is that the IMX412 sensor driver and qcom_camss camera subsystem modules are loaded successfully, confirming the upstream camera stack is active.
2
Check the media node number
Run the following command to print the media device node number for the CAMSS driver.If /dev/media0 does not list the qcom-camss driver, try it with /dev/media1.
The media controller utility (media-ctrl) is a V4L2 utility used to configure camera subsystem subdevices. Use media-ctl --help to print usage information.
Replace [x] with the number found via :ref. <Check the media node number>. For example, # media-ctl -d /dev/media1 --reset.
Reset all links to inactive:
Reset Links
# media-ctl -d /dev/media[x] --reset
Configure the camera sensor format and resolution on pipeline nodes:
libcamera is an open-source software framework. It handles control of the V4L2 camera interface and exposes a native C++ API to upper layers. The applications and upper-level frameworks run based on the libcamera framework.See libcamera architecture for more detail about the libcamera architecture.
This runs the utility and captures 10 raw frames in the root directory and saves them into files.Check the console log messages for information about the resolution and format of the dumped images.
Log Output
Using camera /base/soc@0/cci@ac4b000/i2c-bus@1/camera@1a as cam0 [0:15:01.067615799] [2155] INFO Camera camera.cpp:945 configuring streams:(0) 4056x3040-SRGGB10_CSI2Pcam0: Capture 10 frames
The V4L2 framework within the Linux kernel supports video devices. It provides an API that allows user space applications to interact with devices such as cameras and video capture cards.More information on V4L2 is available from kernel.org.Qualcomm supports the V4L2 interface camera ISP driver for raw frame dump functionality in the upstream kernel.
The Qualcomm camera subsystem (CAMSS) driver in the upstream kernel implements the V4L2, media controller, and V4L2 subdev interfaces.Camera sensors using the V4L2 subdev interface in the kernel are supported.The CAMSS driver consists of:
CSIPHY module – Handles the physical layer of the CSI2 receivers. A separate camera sensor can be connected to each CSIPHY module.
CSI Decoder (CSID) module – Handles the protocol and application layers of the CSI2 receivers. A CSID can decode a data stream from any CSIPHY.
Video Front End (VFE) module – Represents the Image Front End (IFE) that contains Raw Dump Interface (RDI) input interfaces that bypass the image processing pipeline. The VFE also contains the AXI bus interface which writes output data to memory.
The CAMSS driver implements the V4L2 interface. Each CSIPHY, CSID, and VFE module is represented by a single V4L2 sub-device.As shown in the following diagram, each CSIPHY can connect to each CSID. Each CSID can connect to each VFE. Each RDI port has an individual video node.
CAMSS V4L2 drivers are in <kernel_root>/drivers/media/platform/qcom/camss. <kernel_root> is the directory of the Linux kernel.
The expected result is that the IMX412 sensor driver and qcom_camss camera subsystem modules are loaded successfully, confirming the upstream camera stack is active.
2
Check the media node number
Run the following command to print the media device node number for the CAMSS driver.If /dev/media0 does not list the qcom-camss driver, try it with /dev/media1.
The media controller utility (media-ctrl) is a V4L2 utility used to configure camera subsystem subdevices. Use media-ctl --help to print usage information.
Replace [x] with the number found via :ref. <Check the media node number>. For example, # media-ctl -d /dev/media1 --reset.
Reset all links to inactive:
Reset Links
# media-ctl -d /dev/media[x] --reset
Configure the camera sensor format and resolution on pipeline nodes:
libcamera is an open-source software framework. It handles control of the V4L2 camera interface and exposes a native C++ API to upper layers. The applications and upper-level frameworks run based on the libcamera framework.See libcamera architecture for more detail about the libcamera architecture.
This runs the utility and captures 10 raw frames in the root directory and saves them into files.Check the console log messages for information about the resolution and format of the dumped images.
Log Output
Using camera /base/soc@0/cci@ac4b000/i2c-bus@1/camera@1a as cam0 [0:15:01.067615799] [2155] INFO Camera camera.cpp:945 configuring streams:(0) 4056x3040-SRGGB10_CSI2Pcam0: Capture 10 frames
The V4L2 framework within the Linux kernel supports video devices. It provides an API that allows user space applications to interact with devices such as cameras and video capture cards.More information on V4L2 is available from kernel.org.Qualcomm supports the V4L2 interface camera ISP driver for raw frame dump functionality in the upstream kernel.
The Qualcomm camera subsystem (CAMSS) driver in the upstream kernel implements the V4L2, media controller, and V4L2 subdev interfaces.Camera sensors using the V4L2 subdev interface in the kernel are supported.The CAMSS driver consists of:
CSIPHY module – Handles the physical layer of the CSI2 receivers. A separate camera sensor can be connected to each CSIPHY module.
CSI Decoder (CSID) module – Handles the protocol and application layers of the CSI2 receivers. A CSID can decode a data stream from any CSIPHY.
Video Front End (VFE) module – Represents the Image Front End (IFE) that contains Raw Dump Interface (RDI) input interfaces that bypass the image processing pipeline. The VFE also contains the AXI bus interface which writes output data to memory.
The CAMSS driver implements the V4L2 interface. Each CSIPHY, CSID, and VFE module is represented by a single V4L2 sub-device.As shown in the following diagram, each CSIPHY can connect to each CSID. Each CSID can connect to each VFE. Each RDI port has an individual video node.
CAMSS V4L2 drivers are in <kernel_root>/drivers/media/platform/qcom/camss. <kernel_root> is the directory of the Linux kernel.
The expected result is that the IMX412 sensor driver and qcom_camss camera subsystem modules are loaded successfully, confirming the upstream camera stack is active.
2
Check the media node number
Run the following command to print the media device node number for the CAMSS driver.If /dev/media0 does not list the qcom-camss driver, try it with /dev/media1.
The media controller utility (media-ctrl) is a V4L2 utility used to configure camera subsystem subdevices. Use media-ctl --help to print usage information.
Replace [x] with the number found via :ref. <Check the media node number>. For example, # media-ctl -d /dev/media1 --reset.
Reset all links to inactive:
Reset Links
# media-ctl -d /dev/media[x] --reset
Configure the camera sensor format and resolution on pipeline nodes:
libcamera is an open-source software framework. It handles control of the V4L2 camera interface and exposes a native C++ API to upper layers. The applications and upper-level frameworks run based on the libcamera framework.See libcamera architecture for more detail about the libcamera architecture.
This runs the utility and captures 10 raw frames in the root directory and saves them into files.Check the console log messages for information about the resolution and format of the dumped images.
Log Output
Using camera /base/soc@0/cci@ac4b000/i2c-bus@1/camera@1a as cam0 [0:15:01.067615799] [2155] INFO Camera camera.cpp:945 configuring streams:(0) 4056x3040-SRGGB10_CSI2Pcam0: Capture 10 frames
The V4L2 framework within the Linux kernel supports video devices. It provides an API that allows user space applications to interact with devices such as cameras and video capture cards.More information on V4L2 is available from kernel.org.Qualcomm supports the V4L2 interface camera ISP driver for raw frame dump functionality in the upstream kernel.
The Qualcomm camera subsystem (CAMSS) driver in the upstream kernel implements the V4L2, media controller, and V4L2 subdev interfaces.Camera sensors using the V4L2 subdev interface in the kernel are supported.The CAMSS driver consists of:
CSIPHY module – Handles the physical layer of the CSI2 receivers. A separate camera sensor can be connected to each CSIPHY module.
CSI Decoder (CSID) module – Handles the protocol and application layers of the CSI2 receivers. A CSID can decode a data stream from any CSIPHY.
Video Front End (VFE) module – Represents the Image Front End (IFE) that contains Raw Dump Interface (RDI) input interfaces that bypass the image processing pipeline. The VFE also contains the AXI bus interface which writes output data to memory.
The CAMSS driver implements the V4L2 interface. Each CSIPHY, CSID, and VFE module is represented by a single V4L2 sub-device.As shown in the following diagram, each CSIPHY can connect to each CSID. Each CSID can connect to each VFE. Each RDI port has an individual video node.
CAMSS V4L2 drivers are in <kernel_root>/drivers/media/platform/qcom/camss. <kernel_root> is the directory of the Linux kernel.
The expected result is that the IMX412 sensor driver and qcom_camss camera subsystem modules are loaded successfully, confirming the upstream camera stack is active.
2
Check the media node number
Run the following command to print the media device node number for the CAMSS driver.If /dev/media0 does not list the qcom-camss driver, try it with /dev/media1.
The media controller utility (media-ctrl) is a V4L2 utility used to configure camera subsystem subdevices. Use media-ctl --help to print usage information.
Replace [x] with the number found via :ref. <Check the media node number>. For example, # media-ctl -d /dev/media1 --reset.
Reset all links to inactive:
Reset Links
# media-ctl -d /dev/media[x] --reset
Configure the camera sensor format and resolution on pipeline nodes:
libcamera is an open-source software framework. It handles control of the V4L2 camera interface and exposes a native C++ API to upper layers. The applications and upper-level frameworks run based on the libcamera framework.See libcamera architecture for more detail about the libcamera architecture.
This runs the utility and captures 10 raw frames in the root directory and saves them into files.Check the console log messages for information about the resolution and format of the dumped images.
Log Output
Using camera /base/soc@0/cci@ac4b000/i2c-bus@1/camera@1a as cam0 [0:15:01.067615799] [2155] INFO Camera camera.cpp:945 configuring streams:(0) 4056x3040-SRGGB10_CSI2Pcam0: Capture 10 frames
The V4L2 framework within the Linux kernel supports video devices. It provides an API that allows user space applications to interact with devices such as cameras and video capture cards.More information on V4L2 is available from kernel.org.Qualcomm supports the V4L2 interface camera ISP driver for raw frame dump functionality in the upstream kernel.
The Qualcomm camera subsystem (CAMSS) driver in the upstream kernel implements the V4L2, media controller, and V4L2 subdev interfaces.Camera sensors using the V4L2 subdev interface in the kernel are supported.The CAMSS driver consists of:
CSIPHY module – Handles the physical layer of the CSI2 receivers. A separate camera sensor can be connected to each CSIPHY module.
CSI Decoder (CSID) module – Handles the protocol and application layers of the CSI2 receivers. A CSID can decode a data stream from any CSIPHY.
Video Front End (VFE) module – Represents the Image Front End (IFE) that contains Raw Dump Interface (RDI) input interfaces that bypass the image processing pipeline. The VFE also contains the AXI bus interface which writes output data to memory.
The CAMSS driver implements the V4L2 interface. Each CSIPHY, CSID, and VFE module is represented by a single V4L2 sub-device.As shown in the following diagram, each CSIPHY can connect to each CSID. Each CSID can connect to each VFE. Each RDI port has an individual video node.
CAMSS V4L2 drivers are in <kernel_root>/drivers/media/platform/qcom/camss. <kernel_root> is the directory of the Linux kernel.
This section describes how to capture raw frame data using an application that supports the V4L2 interface.
Connect the IMX577 MIPI camera sensor to the CAM1 (CSI1 22-pin) slot of the IQx7181 device.
Yavta is available by default as part of the image; no explicit installation is required.
1
Verify the CAMSS module
The IMX412 and CAMSS modules are loaded by default. Verify the qcom_camss and IMX412 modules are loaded by running the following lsmod commands:
Verify Modules
lsmod | grep qcom_camss lsmod | grep imx412
2
Check the media node number
Run the following command to print the media device node number for the CAMSS driver.If /dev/media0 does not list the qcom-camss driver, try it with /dev/media1.
The media controller utility (media-ctrl) is a V4L2 utility used to configure camera subsystem subdevices. Use media-ctl --help to print usage information.
Replace [x] with the number found via :ref. <Check the media node number>. For example, # media-ctl -d /dev/media1 --reset.
Reset all links to inactive:
Reset Links
# media-ctl -d /dev/media[x] --reset
Configure the camera sensor format and resolution on pipeline nodes:
libcamera is an open-source software framework. It handles control of the V4L2 camera interface and exposes a native C++ API to upper layers. The applications and upper-level frameworks run based on the libcamera framework.See libcamera architecture for more detail about the libcamera architecture.
This runs the utility and captures 10 raw frames in the root directory and saves them into files.Check the console log messages for information about the resolution and format of the dumped images.
Log Output
Using camera /base/soc@0/cci@ac4b000/i2c-bus@1/camera@1a as cam0 [0:15:01.067615799] [2155] INFO Camera camera.cpp:945 configuring streams:(0) 4056x3040-SRGGB10_CSI2Pcam0: Capture 10 frames
Qualcomm Linux devices provide driver support for USB web cameras that adhere to the USB video class (UVC) standard. The UVC video driver exposes these cameras as V4L2 video devices, which can be accessed through the character device nodes such as /dev/videoX. See USB camera configuration for an USB camera usage. The sample application gst-usb-single-camera-app can be used for USB camera validation.
A network camera can be supported with the open source GStreamer plugin. Getting a camera stream from the network depends on the network protocols supported by the GStreamer plugin. Developers can use an open source GStreamer plugin (for example, rtspsrc) to handle camera streams from the network and create a pipeline as needed. See rtspsrc for plugin details.The sample application gst-ai-multistream-inference can also be used for network camera validation. See Bring up Ethernet for instructions on setting up an Ethernet network connection.For developing a GStreamer application on the Qualcomm platform, see Qualcomm Intelligent Multimedia SDK.
