Example - Generating DTSI and DTBO Overlay Files for SmartCam¶

In this example, the steps are shown to create a working SmartCam DTBO overlay file. First, you generate a pl.dtsi file using DTG, and then complete the modifications required to make the .dtsi file fully functional. This example is based on 2022.1 SmartCam release.

Prerequisites¶

Read through Generating DTSI and DTBO Overlay Files, and install the required tools.

Obtain the required XSA file using these instructions. They are summarized as follows:

cd $workdir
git clone --recursive --branch xlnx_rel_v2022.1 https://github.com/Xilinx/kria-vitis-platforms.git
cd $workdir/kria-vitis-platforms/kv260/platforms/vivado/kv260_ispMipiRx_vcu_DP
make xsa

The generated XSA is located at: $workdir/kria-vitis-platforms/kv260/platforms/vivado/kv260_ispMipiRx_vcu_DP/project/kv260_ispMipiRx_vcu_DP.xsa.

Generating the .dtsi File Based on the Platform .xsa File Using DTG¶

Call XSCT:

cd $workdir
xsct

In XSCT, perform the following commands to extract the hardware configuration information and generate a DTSI file:

hsi open_hw_design kria-vitis-platforms/kv260/platforms/vivado/kv260_ispMipiRx_vcu_DP/project/kv260_ispMipiRx_vcu_DP.xsa
hsi set_repo_path <path to device-tree-xlnx repository>
hsi create_sw_design device-tree -os device_tree -proc psu_cortexa53_0
hsi set_property CONFIG.dt_overlay true [hsi::get_os]
hsi set_property CONFIG.dt_zocl true [hsi get_os]
hsi generate_target -dir smartcam_dtg_output
hsi close_hw_design kv260_ispMipiRx_vcu_DP_wrapper

A smartcam_dtg_output/pl.dtsi file is created. It should look identical to pl.dtsi here. You make the modifications to it in the next step to add the necessary information that cannot be automatically generated.

Modify the Generated pl.dtsi¶

NOTE: The released kv260-smartcam.dtsi uses sugar syntax while the generated pl.dtsi uses fragmented syntax; both syntaxes work. For this tutorial, continue with the fragmented syntax.

Add the AP1302 Node¶

The AP1302 sensor is on the carrier card and not something the .XSA platform is aware of as the FPGA/PL design only can infer the generic MIPI and I2C interfaces. For the AP1302 clock and regulators, add the following required information to overlay2:

ap1302_clk: sensor_clk {
   compatible = "fixed-clock";
   clock-frequency = <0x48000000>;
};
ap1302_vdd: fixedregulator@0 {
   compatible = "regulator-fixed";
   regulator-name = "ap1302_vdd";
   regulator-min-microvolt = <2800000>;
   regulator-max-microvolt = <2800000>;
   enable-active-high;
};

ap1302_vaa: fixedregulator@1 {
   compatible = "regulator-fixed";
   regulator-name = "ap1302_vaa";
   regulator-min-microvolt = <1800000>;
   regulator-max-microvolt = <1800000>;
};

ap1302_vddio: fixedregulator@2 {
   compatible = "regulator-fixed";
   regulator-name = "ap1302_vddio";
   regulator-min-microvolt = <1200000>;
   regulator-max-microvolt = <1200000>;
};

I2C MUX¶

The I2C MUX connecting to control the AP1302 also exists outside of Zynq MPSoC and .xsa file does not have awareness, therefore they also must be added manually. The device tree binding is documented here and here.

NOTE: The port connection to mipi_csi_incapture_pipeline_mipi_csi2_rx_subsyst_0 on mipi_csi_portscapture_pipeline_mipi_csi2_rx_subsyst_0 (both names are autogenerated by DTG) corresponds to the mipi_phy_if in the platform Vivado design.

i2c_mux: i2c-mux@74 {
   compatible = "nxp,pca9546";
   reg = <0x74>;
   i2c@0 {
      reg = <0>;
      ap1302: isp@3c {
         compatible = "onnn,ap1302";
         reg = <0x3c>;
         reset-gpios = <&gpio 79 1>;
         clocks = <&ap1302_clk>;
         sensors {
            onnn,model = "onnn,ar1335";
            sensor@0 {
               reg = <0>;
               vdd-supply = <&ap1302_vdd>;
               vaa-supply = <&ap1302_vaa>;
               vddio-supply = <&ap1302_vddio>;
            };
         };
         ports {
            port@0 {
               reg = <2>;
               isp_out: endpoint {
               remote-endpoint = <&mipi_csi_incapture_pipeline_mipi_csi2_rx_subsyst_0>;
               data-lanes = <1 2 3 4>;
               };
            };
         };
      };
   };
};

mipi csi Mode¶

The mipi_csi2_rx_subsystem@80000000 node requires a few modification. The device tree binding information for AMD MIPI CSI-2 Receiver Subsystem is here.

Add the property:

xlnx,csi-pxl-format = <0x18>;
xlnx,en-active-lanes;

Remove xlnx,cfa-pattern, xlnx,video-format, and xlnx,video-width settings. These settings are no longer used by the driver, and the 2022.1 through 2023.1 DTG is not yet updated.

Connect the remote end point to camera serial output:

mipi_csi_incapture_pipeline_mipi_csi2_rx_subsyst_0: endpoint {
   data-lanes = <1 2 3 4>;
   remote-endpoint = <&isp_out>;
};

ZOCL Node¶

Finally, in 2022.1 through 2023.1, the ZOCL node needs to specify the interrupts reserved for the platform (as seen in platform setting tab in Vivado) if interrupts are directly connected to GIC (instead of through a axi_intc).

zyxclmm_drm {
   compatible = "xlnx,zocl";
   status = "okay";
   interrupt-parent = <&gic>;
   interrupts = <0 89  4>, <0 90  4>, <0 91  4>, <0 92  4>,
               <0 93  4>, <0 94  4>, <0 95  4>, <0 96  4>;
};

Final dtsi File¶

The final dtsi file should similar to pl_modify.dtsi.

Compile the .dtsi to .dtbo Using DTC¶

Now, generate the .dtbo file using the following command:

dtc -@ -O dtb -o pl_modify.dtbo pl_modify.dtsi

As a sanity test, rename the generated pl.dtbo to a unique name for tracking purposes, move it to the kv260 target, and confirm that the SmartCam app still works after replacing the kv260_smartcam.dtbo with the generated one.

^{Terms and Conditions}