.. _SD.CameraDevelopment.JetsonVirtualChannelWithGmslCameraFramework: .. include:: /content/swdocs.rsts .. spelling:: BGGR libargus nvarguscamerasrc RG UYVY YUY Des gmsl imx muxer proc Ser tegra Jetson Virtual Channel with GMSL Camera Framework !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! **Applies to**: Jetson AGX Xavier series .. todo:: Throughout, Xavier NX and Orin TBD. This topic contains details about: - The Gigabit Multimedia Serial Link (GMSL) protocol - Hardware connectivity for the serializer/deserializer in the reference module (see `Reference Setup <#reference-setup>`__) - The software framework - Configuration, including virtual channel programming NVIDIA validates the reference module on |NVIDIA(r)| |Jetson AGX Xavier(tm)| series devices with Sony IMX390 sensors as source. However, the reference module can be used as a starting point for bringing up another GMSL module on Jetson AGX Xavier series. The software framework described in this document can be used as reference for developing **SerDes** (Serializer-Deserializer) links other than GMSL. .. note:: The reference GMSL module described here uses the CSI interface. No other interface is validated. Reference Setup @@@@@@@@@@@@@@@ The reference GMSL setup is: - Sensor: Sony dual IMX390, RAW12/1080p/30fps, CSI port A, x2 lanes - Serializer: Maxim MAX9295 - Deserializer: Maxim MAX9296 .. todo:: The first four diagrams in this topic have been redrawn from scratch for better readability. Please recheck for errors. GMSL Protocol @@@@@@@@@@@@@ Maxim Integrated supports GMSL as a communication link for video applications in the automotive industry. GMSL is based on SerDes (Serializer-Deserializer) technology; that is, it uses a serializer on the transmitting side and a deserializer on the receiving side. The following diagram shows the high-level architecture of GMSL. .. figure:: JetsonVirtualChannelWithGmslCameraFramework/GmslProtocol.svg :alt: GMSL protocol :figwidth: 650px GMSL is specifically designed for use in Advanced Driver Assistance Systems (ADAS) and Camera Monitoring Systems (CMS). It can provide video transfer speeds up to 6 GB/second. It uses STP or coaxial cable, which are both inexpensive and very robust for EMC disturbances. GMSL Camera @@@@@@@@@@@ The following diagram shows the control, data, and clock connections for the reference GMSL module validated on Jetson AGX Xavier series. .. figure:: JetsonVirtualChannelWithGmslCameraFramework/GmslCamera.svg :alt: Control, data, and clock connections for the reference GMSL module :figwidth: 650px - In this GMSL setup, two sensors are paired with their respective serializers, each streaming 1080p/30fps RAW12 pixels over x2 CSI MIPI lanes. - The serializers are connected to a GMSL deserializer device through different GMLS ports (ports A and B) and GMSL links using coaxial cables. - On the output port side, the deserializer is connected to a Jetson AGX Xavier SoC on the desired CSI port (port A in this example). - To transmit two different pixel streams from two sensors to a receiver at a shared CSI port, the deserializer assigns a unique virtual channel ID to each stream. The virtual channel ID is software-configurable via the device tree. It must match the stream’s virtual channel ID programmed on the receiver side in the NVIDIA SoC. This reference GMSL setup uses a 2x (x2/x4/x1) CSI deserializer. It can host up to two sensors via serializers. To host four sensors over single shared CSI port you must use a 4x aggregator, as shown in the following diagram: .. todo:: The text refers to "aggregators," and in r32 the diagrams had headings that did the same (and the diagrams' filenames still do), but the drawings actually show *serializers*. Which is correct? The text accompanying the first diagram agrees with the diagram. .. figure:: JetsonVirtualChannelWithGmslCameraFramework/ProposedGmslSetupWith4xAggregator.svg :alt: GMSL setup with 4x aggregator :figwidth: 650px CSI Connectivity @@@@@@@@@@@@@@@@ The table below shows the maximum number of sensor connections supported on each type |NVIDIA(r)| |Jetson(tm)| device. +---------------------+------------------+-------------------+ | | Maximum connections supported | +---------------------+------------+------------+------------+ + Configuration | Jetson | Jetson | Jetson | | | AGX Orin | Xavier NX | AGX Xavier | | | | series | series | +=====================+============+============+============+ | No aggregator | | | 6 | +---------------------+------------+------------+------------+ | Aggregator with ISP | | | 16 | +---------------------+------------+------------+------------+ | Aggregator without | | | 24 | | ISP | | | | +---------------------+------------+------------+------------+ .. todo:: Orin entries TBD above; corresponding sections TBD below. Jetson AGX Orin ############### .. todo:: TBD Jetson Xavier NX Series ####################### .. todo:: TBD Jetson AGX Xavier Series ######################## Jetson AGX Xavier series supports a maximum of 16 virtual channels with ISP, or 24 virtual channels without ISP. .. figure:: JetsonVirtualChannelWithGmslCameraFramework/CsiConnectivityJetsonAgxXavier16Cameras.svg :alt: CSI connectivity for Jetson AGX Xavier series with 16 cameras :figwidth: 650px The diagram above shows sensor connections to each of the |NVIDIA(r)| Xavier\ |tm| CSI bricks (a total of 4 CSI bricks) in x4 or /x2 or /x1 possible lane configuration. .. todo:: "x4 or /x2 or /x1" is unclear -- what do the slashes mean? .. figure:: JetsonVirtualChannelWithGmslCameraFramework/CsiConnectivityJetsonAgxXavier24Cameras.svg :alt: CSI connectivity for Jetson AGX Xavier series with 24 cameras :figwidth: 650px The diagram above shows four sensors connected to each port of CSI bricks AB and CD in x2 or x1 lane configuration, and four sensors connected to each of the remaining CSI bricks EF and GH in x4, x2, or x1 lane configuration. The CSI aggregator uses virtual channels to connect to four cameras over one CSI connection. The Jetson AGX Xavier VI muxer sends each camera frame to a different location in memory. In software, each camera appears as a separate V4L2 device. Hardware Module Connectivity @@@@@@@@@@@@@@@@@@@@@@@@@@@@ The figure below shows how two sensors are connected to a Jetson AGX Xavier device using a GMSL reference module and a MAX9295/MAX9296 SerDes. The GMSL MAX9296 deserializer is connected to a Jetson device via a MIPI adapter and MIPI white cables, which are plugged into the device’s camera connector socket. This is one of several ways the aggregator hardware module can be connected to the device. .. figure:: JetsonVirtualChannelWithGmslCameraFramework/Max9295And9296.jpg :alt: Two sensor connected to a Jetson device with MAX9295 and MAX9296 :figwidth: 650px Software Framework and Programming @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ This section describes the kernel drivers and device tree programming required for GMSL and virtual channel. The following diagram shows the high-level architecture of the kernel drivers and devices. .. figure:: JetsonVirtualChannelWithGmslCameraFramework/SoftwareFrameworkAndProgramming.svg :alt: Kernel drivers and device tree programming :figwidth: 650px .. todo:: The lines on the "Device" side have no arrowheads or signage. Omission? Driver Framework ################ As shown in the diagram above, there are separate kernel drivers for serializer and deserializer devices, apart from the sensor driver. In the reference module they are the MAX9295 serializer and MAX9296 deserializer drivers. In this framework, the sensor driver is exposed to the rest of the system as would be any other generic V4L2 sensor driver without external aggregator. All of the SerDes programming happens “under the hood” through the sensor driver. The SerDes kernel drivers are not registered as client programmable and isolated devices V4L2 or any other sensor framework. The reason for this design is that a certain fixed sequence of operations must be performed in the SerDes, and it does not quite fit the generic V4L2 framework sequence for sensors. SerDes drivers are separate, though. They can be statically linked to any sensors in the device tree, depending on hardware connectivity, but they are controlled by the sensor driver only. They do not expose any programmable functionality directly to user clients. A sensor driver internally links to the SerDes drivers to perform device and stream control operations such as power on/off, control setup/release, stream setup/release, and stream start/stop, based on device tree configuration. Driver Programming $$$$$$$$$$$$$$$$$$ The serializer/deserializer drivers control the serializer/deserializer modules through the serializer/deserializer API, described in `Jetson Linux Drive Package API Reference `__. The structure ``gmsl_link_ctx`` is the core entity which defines the entire link configuration from sensor to serializer link to deserializer link for each sensor source. It is documented in the *API Reference*. Most of the structure fields are populated by the sensor driver from the sensor’s gmsl-link node in the device tree during device boot. (See `Module Device Tree <#module-device-tree>`__ for node details.) Some of the fields are populated by the serializer and deserializer drivers. The sensor driver populates an instance of the structure and passes it to the serializer and deserializer drivers, which make use of the configuration details found in the structure context during power-on, control pipeline setup, and data streaming pipeline setup calls. As defined in this structure, the sensor and its corresponding serializer device each have a **physical I2C slave address**, assigned according to the device data sheet, and a **proxy I2C slave address**, which is user-defined. The reason for this is that all of the devices sharing the same hardware connection in the GMSL setup must be identified to the I2C bus with unique physical I2C slave addresses. The physical I2C slave address of each device is fixed, and is the same for similar types of devices, such as all sensor devices of a single make and model that are assigned to same slave. This causes address conflicts. To resolve the conflicts the driver uses a different proxy I2C slave address for each such device. The proxy I2C slave addresses are set statically in the device tree, and are assigned during device boot. The following diagram shows the call flow among the GMSL kernel drivers during device boot. .. figure:: JetsonVirtualChannelWithGmslCameraFramework/GmslCameraDeviceBoot.svg :alt: GMSL kernel driver call flow during boot :figwidth: 650px .. todo:: In this diagram & the next, the signage has been re-entered to correct some corruption problems. Please recheck. Power management is handled by the shared deserializer driver instead of the sensor driver because each sensor device’s driver is unaware of other sensor devices in the GMSL module setup, but the deserializer device is common among all of the sensors connected to it. The stream-on and stream-off calls are mapped directly to the serializer and deserializer drivers. Stream setup is required for both SerDes drivers, whereas stream-on and stream-off are controlled by the deserializer driver only. The following figure shows the call flow among the GMSL kernel drivers for a stream-on or stream-off operation. .. figure:: JetsonVirtualChannelWithGmslCameraFramework/GmslCameraStreamOnCallFlow.svg :alt: GMSL kernel driver call flow for stream-on/stream-off :figwidth: 650px Device Tree Programming ####################### The device tree describes the hardware connections to the system as well as the static device properties of the drivers. Platform Device Tree $$$$$$$$$$$$$$$$$$$$ Hardware connections and device addressing are configured in the platform device tree. As explained in `Driver Programming <#driver-programming>`__, each sensor and serializer device has two addresses: a physical I2C slave address and a proxy I2C slave address. Both are defined in the platform device tree. In the reference GMSL module both sensors have the physical I2C slave address ``0x1a``, but must be assigned distinct proxy addresses. The proxy I2C slave addresses are user-configurable, by default ``0x1b`` and ``0x1c``. Similarly, for serializer devices the physical I2C slave address is ``0x62``, and the proxy I2C slave addresses are user-configurable, by default ``0x40`` and ``0x60``. The following table shows the I2C slave address assignments for the reference GMSL setup. +----------------+------------------------------------------------------------+ | | I2C Slave Address | + +----------------+----------+----------+----------+----------+ | | Assignments | | | | | | | Sensor1 | Sensor2 | Ser1 | Ser2 | Des | +================+================+==========+==========+==========+==========+ | Physical I2C | ``0x1a`` | ``0x1a`` | ``0x62`` | ``0x62`` | ``0x48`` | | slave address | | | | | | +----------------+----------------+----------+----------+----------+----------+ | Proxy I2C | ``0x1b`` | ``0x1c`` | ``0x40`` | ``0x60`` | NA | | slave address | | | | | | +----------------+----------------+----------+----------+----------+----------+ Each sensor device initiates a ``power_on`` request to the deserializer driver to perform GMSL link configuration and power on the shared deserializer device. In this power-on call, the deserializer driver only enables the GMSL link to which the caller’s sensor device is connected, and keeps other one disabled, so that there will be no address conflict between the two links. It then updates all devices’ proxy I2C slave addresses on the active link to the ones defined in the device tree. It follows the same procedure for the other GMSL link when the deserializer driver gets a ``power_on`` request from the sensor device connected to the other GMSL link. In this way, the deserializer driver updates all of the proxy I2C save addresses of all devices hosted by the deserializer device. For example, in the reference GMSL setup, when the deserializer gets a power-on request from the sensor device connected to link A, it enables GMSL link A and disables GMSL link B. It first communicates to the serializer and the sensor devices on link A at their respective physical I2C slave addresses (``0x1a`` for ``sensor1`` and ``0x62`` for ``Ser1``), and then updates those physical I2C slave addresses to proxy I2C slave addresses (``0x1b`` for ``sensor1`` and ``0x40`` for ``Ser1``). Then it performs the same steps for GMSL link B when the sensor device on GMSL link B requests power_on of the deserializer driver. Finally, it sets up the GMSL link in dual mode. Thus, each device is identified uniquely over the I2C bus. All further device communication takes place on the proxy I2C slave addresses until reboot. The GMSL link addresses are currently programmed at boot time, during probing, due to control configuration timing constraints. The following code is an example of platform device configuration for the GMSL setup shown in the diagrams above. For full details, see the platform device tree file: - For Jetson AGX Xavier series: tegra194-p2822-0000-camera-imx390-a00.dtsi:: tca9546@70 { /* The deserializer is connected to Tegra Jetson camera connector port via MIPI adapter over pca9546 i2c expander, so all the GMSL device nodes go under here. */ compatible = "nxp,pca9546"; i2c@0 { /* As in above setup, deserializer (which hosts all the serializers and sensors) is connected to adaptor onto port A, so on i2c expander all the GMSL devices go under i2c@0, the expander assigns 0x30 unique address to port 0.*/ reg = <0>; dser: max9296@48 { /* single common deserializer at 0x48 */ compatible = "nvidia,max9296"; reg = <0x48>; csi-mode = "2x4"; /* this tells max CSI lane configuration */ max-src = <2>; /* max sources */ /* As deserializer is common among sensor devices, the reset and power rails are controlled via deserializer */ reset-gpios = <&tegra_main_gpio CAM0_RST_L GPIO_ACTIVE_HIGH>; vdd_cam_1v2-supply = <&en_vdd_cam_1v2>; }; ser_prim: max9295_prim@62 { /* Default serializer device */ compatible = "nvidia,max9295"; reg = <0x62>; is-prim-ser; /* primary ser device */ }; ser_a: max9295_a@40 { /* serializer device connected at link A at proxy address 0x40 (the proxy address are assigned runtime) */ compatible = "nvidia,max9295"; reg = <0x40>; nvidia,gmsl-dser-device = <&dser>; /* link to its deserializer device */ }; ser_b: max9295_b@60 { /* serializer device connected at link A at proxy address 0x60 (the proxy address is assigned runtime) */ compatible = "nvidia,max9295"; reg = <0x60>; nvidia,gmsl-dser-device = <&dser>; /* link to its deserializer device */ }; imx390_a@1b { /* sensor device connected at link A at proxy address 0x1b (the proxy address is assigned runtime). */ def-addr = <0x1a>; /* default slave address is 0x1a */ nvidia,gmsl-ser-device = <&ser_a>; /* link to its serializer device. */ nvidia,gmsl-dser-device = <&dser>; /* link to its deserializer device. */ }; imx390_b@1c { /* sensor device connected at link A at proxy address 0x1b (the proxy address are assigned runtime). */ def-addr = <0x1a>; /* Default slave address is 0x1a. */ /* Define clocks, io pins, power sources */ nvidia,gmsl-ser-device = <&ser_b>; /* Link to its serializer device. */ nvidia,gmsl-dser-device = <&dser>; /* Link to its deserializer device. */ }; }; /* i2c@0 closing */ }; /* tca9546@70 closing */ .. todo:: This is an appropriate place to repeat the caution that very long code samples are rarely appropriate in documents. If we are illustrating something explained in the text, a much shorter excerpt is almost always more effective. If the entire piece of code is important, we can refer the reader to the file in which it appears. As a related issue, does this sample really belong under the bullet point? In r32.6 there was a second bullet point for TX2, and it was accompanied by no code at all. Module Device Tree $$$$$$$$$$$$$$$$$$ After platform device configuration, the device module configuration must be added to the module device tree. For full details, see: - For Jetson TX: tegra186-camera-imx390-a00.dtsi - For Jetson AGX Xavier series: tegra194-camera-imx390-a00.dtsi A few snippets are shown here to illustrate the configuration. The virtual channels are set in the module device tree. The sensor device acts as controller device in the GMSL software framework, so in the module device tree each sensor device node contains a gmsl-link device node which describes the properties of the GMSL link to which the sensor is connected. In the example below, the gmsl-link node describes the sensor connected at GMSL link A:: gmsl-link { src-csi-port = "b"; /* Port at which sensor is connected to its serializer device. */ dst-csi-port = "a"; /* Destination CSI port on the Jetson side, connected at deserializer. */ serdes-csi-link = "a"; /* GMSL link sensor/serializer connected to sensor CSI node. */ csi-mode = "1x4"; st-vc = <0>; /* Sensor source default VC ID: 0 unless overridden by sensor. */ vc-id = <0>; /* Destination VC ID, assigned to sensor stream by deserializer. */ num-lanes = <2>; /* Number of CSI lanes used. */ streams = "ued-u1", "raw12"; /* Types of streams sensor is streaming. */ }; For any GMSL module configuration, all the fields shown above must be set based on the hardware connectivity. Virtual Channel Programming in the Module Device Tree ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. todo:: We are down to six levels of headings here, and our style guidelines do not allow more than five. We need to reorganize the document to avoid this. You must add the same ``vc-id`` property value to the respective CSI and VI channel nodes in the same module device tree file. This property is used for V4L2 camera use cases. You must set the ``vc-id`` property in the gmsl-link node for each sensor to match the ``vc_id`` property in the sensor mode device node. The ``vc_id`` property in sensor mode device tree nodes is used for use cases based on the ARGUS camera. For example:: mode0 { /* Mode IMX390_MODE_1920X1080_CROP_30 FPS. */ mclk_khz = "24000"; num_lanes = "2"; tegra_sinterface = "serial_a"; vc_id = "0"; . . . }. VI and CSI Channel Nodes in the Module Device Tree ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The module device tree for the reference GMSL setup also performs the port binding to VI and CSI. The number of VI and CSI channels is 2, as in any other dual-sensor setup, but the port-index field would be set based on the hardware connectivity:: vi@15700000 { num-channels = <2>; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; imx390_vi_in0: endpoint { vc-id = <0>; port-index = <0>; bus-width = <2>; remote-endpoint = <&imx390_csi_out0>; }; }; port@1 { reg = <1>; imx390_vi_in1: endpoint { vc-id = <1>; port-index = <0>; bus-width = <2>; remote-endpoint = <&imx390_csi_out1>; }; }; }; }; nvcsi@150c0000 { num-channels = <2>; #address-cells = <1>; #size-cells = <0>; channel@0 { reg = <0>; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; imx390_csi_in0: endpoint@0 { port-index = <0>; bus-width = <2>; remote-endpoint = <&imx390_imx390_out0>; }; }; port@1 { reg = <1>; imx390_csi_out0: endpoint@1 { remote-endpoint = <&imx390_vi_in0>; }; }; }; }; channel@1 { reg = <1>; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; imx390_csi_in1: endpoint@2 { port-index = <0>; bus-width = <2>; remote-endpoint = <&imx390_imx390_out1>; }; }; port@1 { reg = <1>; imx390_csi_out1: endpoint@3 { remote-endpoint = <&imx390_vi_in1>; }; }; }; }; }; In this configuration the port-index property is set to 0 for both the VI channel 0 and channel 1 nodes, so that both sensors use VI stream 0. For CSI channel 0 and channel 1 nodes too the port-index property is set to 0, meaning that both channels’ sensors are connected to CSI port A. The VI and CSI channel nodes also both contain a new property, ``vc-id``, used in V4L2 camera use cases as mentioned above. It must match the gmsl-link device node’s ``vc-id`` property. The ``bus-width`` property specifies the number of CSI lanes used. tegra-camera-platform node configuration in module device tree ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. todo:: The odd capitalization below is probably an error. The ``TEGRA-CAMERA-platform`` device node specifies details of the sensor modules’ configuration. The configuration below is for the reference GMSL module:: tegra-camera-platform { compatible = "nvidia, tegra-camera-platform"; num_csi_lanes = <2>; max_lane_speed = <4000000>; min_bits_per_pixel = <10>; vi_peak_byte_per_pixel = <2>; vi_bw_margin_pct = <25>; isp_peak_byte_per_pixel = <5>; isp_bw_margin_pct = <25>; modules { module0 { badge = "imx390_rear"; position = "rear"; orientation = "1"; drivernode0 { pcl_id = "v4l2_sensor"; /* Driver v4l2 device name */ devname = "imx390 30-001b"; proc-device-tree = "/proc/device-tree/i2c@3180000/tca9546@70/i2c@0/imx390_a@1b"; }; }; module1 { badge = "imx390_front"; position = "front"; orientation = "1"; drivernode0 { pcl_id = "v4l2_sensor"; /* Driver v4l2 device name */ devname = "imx390 30-001c"; proc-device-tree = "/proc/device-tree/i2c@3180000/tca9546@70/i2c@0/imx390_b@1c"; }; }; }; }; - ``num_csi_lanes`` is set to 2, since both sensors are connected to a single CSI port A in x2 lane fashion. This is unlike other dual sensors, where ``num_csi_lanes`` is set to the total number of CSI lanes used by both sensors, since they use different CSI ports. - ``max_lane_speed`` is set to an appropriate value for two sensors streaming through a single shared port. - The sensor device nodes are defined using sensor proxy I2C slave addresses instead of their physical I2C slave address, and their paths are set in proc-device-tree property. Similar naming is used for the devname property. For the rest of the configuration, follow the same guidelines as for other sensors. Refer to the following module device tree files: - For Jetson AGX Xavier series: ``tegra194-camera-imx390-a00.dtsi`` Plugin Manager Device Tree $$$$$$$$$$$$$$$$$$$$$$$$$$ The device tree additions for Plugin Manager are the same as for any other sensor module. For reference GMSL setup plugin manager support, see the node ``fragment-imx390@0`` in: - For Jetson AGX Xavier series: ``tegra194-camera-plugin-manager.dtsi`` Camera Modules Device Tree $$$$$$$$$$$$$$$$$$$$$$$$$$ All the device nodes in the I2C node of the platform’s camera module device tree are defined in the same way as in the platform device tree. As in the reference GMSL setup, they all go to ``i2c@0``. The camera module device tree is: - For Jetson AGX Xavier series: tegra194-p2822-camera-modules.dtsi .. todo:: In each of these sections, remove the separate listing for AGX Xavier if Orin is the same. .. note:: The ``vc-id`` property is set to 0 by default for all VI ports in all modules’ device tree files. You must assign correct values to this property in ``plugin-manager`` and the sensor-specific module device tree file. Constraints @@@@@@@@@@@ Sensor streams connected to same CSI aggregator and sharing a CSI port must use the same lane configuration. The deserializer driver fails to register a stream if its lane configuration does not match other streams that share the same deserializer device. Apart from that, CSI aggregators generally support multiple identical cameras running with the same frame rate and sensor mode. Review your aggregator data sheet for additional restrictions if you are using a more complicated configuration. Validation @@@@@@@@@@ Dual GMSL sensor streaming (preview/capture) is validated using Argus cameras, sharing CSI port A, and the V4L2 application. The 2x CSI deserializer/aggregator is validated. The 4x CSI aggregator is not validated, as its hardware module is currently not available. Known Issues @@@@@@@@@@@@ This section summarizes known issues in the GMSL camera framework. General Issues ############## - Preview flickers on scene change. - Sensor tuning and image quality are substandard. Xavier-Specific ############### .. note:: This limitation and rework only apply to older GMSL kits which do not draw on the on-board (DESER) 1.2\ |nbsp|\ V supply. The 1.2 V power supply needs rework. The MAX9296 deserializer board used in the reference setup does not draw the required on-board 1.2 V power, and the Jetson AGX Xavier Developer Kit carrier board has dropped support for supplying 1.2 V to the camera connector. The following rework is required on Jetson AGX Xavier for vendor modules that expect 1.2V from the carrier board: - Use spare LDO for the SATA controller, which can take maximum 1.21 V. The V\ :sub:`min` requirement from the IMX390 reference sensor is 1.14 V, and the range is 1.14 V to 1.26 V, so this LDO supply is enough to supply 1.2 V to the Jetson AGX Xavier carrier board’s camera connector. Plugin Manager Board ID ####################### The reference GMSL module currently does not have a unique board ID. Use the MIPI adapter’s board ID, LPRD-001. This ID is used by other sensor modules which use similar MIPI adapters, such as IMX274 and IMX185. To work around this issue until it is resolved, the IMX390 module is disabled in these sensor modules; see ``tegra186-quill-camera-plugin-manager.dtsi``.