Wiki

This version (12 May 2024 20:52) was approved by Alin-Tudor Sferle.The Previously approved version (11 May 2024 08:38) is available.Diff

AD-GMSL2ETH-SL System Setup & Evaluation

Required hardware

  • 1 x AD-GMSL2ETH-SL board
  • 8 x Tier IV C1 cameras
  • 8 x Fakra cables
  • 2 x Quad-based mini-Fakra cables
  • 1 x 16GB SD card
  • 1 x PC with 10G ethernet card
  • 1 x SFP+ Ethernet cable

FPGA SD Card Image

SD-card images for the FPGA:

In case of using the increased mtu-related image, the default BOOT.BIN in the root of the partition one (named bootfs) will be the one that support transfer rates up to 16334 (this BOOT.BIN file being also located in the boot_bin_16334 directory) (that can be changed by using the ip command - ip link set mtu 16334 dev eth0). If you want to change to the version that supports up to 9000, you can copy the BOOT.BIN file from the tier4_8cam directory.

After downloading the file, extract the compressed image and write it to the SD-card using Balena Ethcher or Win32-Disk-Imager.

More details on how to extract a compressed image and write it on the SD card on Linux and Windows can be found here: Writing an image onto the SD card


System Setup

In order to boot using SD card, you will need to set the boot mode's switches to the corresponding position, as indicated in the following image:

Connect the Quad-based mini-Fakra cables to the corresponding connectors on the board. These will connect the cameras to the corresponding deserializers.

Connect a SFP+ cable to the corresponding SFP port on the board.

Finally, you will need to connect an USB/micro-USB cable to the micro-USB port located on the board. After that, you will be able to connect to the first USB com port that appears on the serial terminal, with a baud rate of 115200.

Ubuntu credentials user:analog/pass:analog
#eth0 - 10G ethernet interface
 
$ ls -l /sys/class/net/
total 0
lrwxrwxrwx 1 root root 0 Mar 20 16:32 eth0 -> ../../devices/platform/axi/a0000000.ethernet/net/eth0
lrwxrwxrwx 1 root root 0 Mar 20 16:32 lo -> ../../devices/virtual/net/lo
lrwxrwxrwx 1 root root 0 Mar 20 16:32 sit0 -> ../../devices/virtual/net/sit0
Both server and client should have the same MTU
#Set the eth0's MTU and IP address
$ sudo ip link set mtu 9000 dev eth1 up
$ sudo ifconfig eth0 10.42.0.1
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
    link/ether a2:78:c4:14:da:c2 brd ff:ff:ff:ff:ff:ff
    inet 10.42.0.1/8 brd 10.255.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::a078::c4ff:fe14:dac2/64 scope link 
       valid_lft forever preferred_lft forever
#Configure the video pipeline and the cameras
$ cd /home/analog/Workspace/K26
$ ./media_cfg_des1/2/12.sh (depending on the desired deserializer or 12 for the case when there are two deserializers with 4 cameras)
 
#Start streaming to another host
$ cd /home/analog/Workspace/gstreamer
$ ./stream_1des_4cams/2des_8cams.sh (depending on the number of cameras - 4 or 8 cameras - 1 or 2 deserializers) [HOST_IP_ADDRESS of the x86-based workstation can be modified/by default is set to 10.42.0.106 in this script]
In order to stop all this processes generated by the streaming-related scripts, you can use the Linux pidof command to see what are the IDs of this gstreamer-related instaces, and after that kill these ones by using Linux kill command, in the following way:
$ pidof gst-launch-1.0 [That is the command to show the ID numbers of the opened processes and will show you 8 numbers - like in the following line]
$ 800 799 798 797 796 795 794 793
$ sudo kill 800 799 797 796 795 794 793

Now the streams are running on ports 5004 to 5007, depending on the configured number of cameras


Client-side optional configurations

The system can be configured in two ways: one default way in which the created 10GE interface will have a static configuration and will be like a router for the client side, assigning IP addresses from a given PoolOffset in the corresponding [DHCPServer] field of the corresponding 21-dhcp.network file avaialble in the /etc/systemd/network directory. The second way would be the one where the client side will be like a router by having the direct Shared_to_Others option set in the Network Manager utility of your Linux-based distro. In case of board setup, the corresponding config will be 20-wired.network in the etc/systemd/network directory. To change the way in which the system is configured you will need to change the [Match] field in the config files to eth0 in the desired config-related file and to ethX (X - anything different than 0 - eth0 being the single interface used in the system):

Setup for the second mentioned configuration:

/20-wired.network file
 
[Match]
Name=eth0
 
/21-dhcp.network file
 
[Match]
Name=eth1

More than that, the following screenshot presents the menu of NetworkManager, in which the user will need to set up the Shared-to-Others option for the corresponding interface of the 10GE connection. [Note: e.g. in earlier Ubuntu versions like Ubuntu 18*, the option is available only by using nm-applet]. In additional, the pool of possible addresses than can be assigned to a connected system can be reduced by using PoolOffset to a smaller subset.

For an automatic setup of MTU to 9000 by using systemd's network configuration file, the following property can be added:
[Link]
MTUBytes=9000

Using increased mtu to 16334

#Set the eth0's MTU
$ sudo ip link set mtu 16334 dev eth1 up

In stream_1des_4cams/2des_8cams.sh scripts, you will need to update the mtu field to 16334.

e.g. : gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw,framerate=30/1,width=1920,height=1080,format=UYVY ! rtpvrawpay mtu=16334 ! udpsink host=$HOST_IP port="5004" &

Displaying the Video

On the receiving side, Gstreamer must be installed

Single Deserializer (4 cameras)

Now open 4 instances of Gstreamer for each port(5004-5007)

(Click) On x86 workstation

(Click) On x86 workstation

$ gst-launch-1.0 udpsrc caps=“application/x-rtp, sampling=YCbCr-4:2:2, depth=(string)8, width=(string)1920, height=(string )1080” port=“5004” ! rtpvrawdepay ! videoconvert ! fpsdisplaysink video-sink=xvimagesink text-overlay=true sync=false

$ gst-launch-1.0 udpsrc caps=“application/x-rtp, sampling=YCbCr-4:2:2, depth=(string)8, width=(string)1920, height=(string )1080” port=“5005” ! rtpvrawdepay ! videoconvert ! fpsdisplaysink video-sink=xvimagesink text-overlay=true sync=false

$ gst-launch-1.0 udpsrc caps=“application/x-rtp, sampling=YCbCr-4:2:2, depth=(string)8, width=(string)1920, height=(string )1080” port=“5006” ! rtpvrawdepay ! videoconvert ! fpsdisplaysink video-sink=xvimagesink text-overlay=true sync=false

$ gst-launch-1.0 udpsrc caps=“application/x-rtp, sampling=YCbCr-4:2:2, depth=(string)8, width=(string)1920, height=(string )1080” port=“5007” ! rtpvrawdepay ! videoconvert ! fpsdisplaysink video-sink=xvimagesink text-overlay=true sync=false

2 x Deserializers (8 cameras)

Now open 8 instances of Gstreamer for each port(5004-5011)

(Click) On x86 workstation

(Click) On x86 workstation

$ gst-launch-1.0 udpsrc caps=“application/x-rtp, sampling=YCbCr-4:2:2, depth=(string)8, width=(string)1920, height=(string )1080” port=“5004” ! rtpvrawdepay ! videoconvert ! fpsdisplaysink video-sink=xvimagesink text-overlay=true sync=false

$ gst-launch-1.0 udpsrc caps=“application/x-rtp, sampling=YCbCr-4:2:2, depth=(string)8, width=(string)1920, height=(string )1080” port=“5005” ! rtpvrawdepay ! videoconvert ! fpsdisplaysink video-sink=xvimagesink text-overlay=true sync=false

$ gst-launch-1.0 udpsrc caps=“application/x-rtp, sampling=YCbCr-4:2:2, depth=(string)8, width=(string)1920, height=(string )1080” port=“5006” ! rtpvrawdepay ! videoconvert ! fpsdisplaysink video-sink=xvimagesink text-overlay=true sync=false

$ gst-launch-1.0 udpsrc caps=“application/x-rtp, sampling=YCbCr-4:2:2, depth=(string)8, width=(string)1920, height=(string )1080” port=“5007” ! rtpvrawdepay ! videoconvert ! fpsdisplaysink video-sink=xvimagesink text-overlay=true sync=false

$ gst-launch-1.0 udpsrc caps=“application/x-rtp, sampling=YCbCr-4:2:2, depth=(string)8, width=(string)1920, height=(string )1080” port=“5008” ! rtpvrawdepay ! videoconvert ! fpsdisplaysink video-sink=xvimagesink text-overlay=true sync=false

$ gst-launch-1.0 udpsrc caps=“application/x-rtp, sampling=YCbCr-4:2:2, depth=(string)8, width=(string)1920, height=(string )1080” port=“5009” ! rtpvrawdepay ! videoconvert ! fpsdisplaysink video-sink=xvimagesink text-overlay=true sync=false

$ gst-launch-1.0 udpsrc caps=“application/x-rtp, sampling=YCbCr-4:2:2, depth=(string)8, width=(string)1920, height=(string )1080” port=“5010” ! rtpvrawdepay ! videoconvert ! fpsdisplaysink video-sink=xvimagesink text-overlay=true sync=false

$ gst-launch-1.0 udpsrc caps=“application/x-rtp, sampling=YCbCr-4:2:2, depth=(string)8, width=(string)1920, height=(string )1080” port=“5011” ! rtpvrawdepay ! videoconvert ! fpsdisplaysink video-sink=xvimagesink text-overlay=true sync=false


Configure the system

Copy the devicetree from the folder that matches the desired system's setup:

Default environment : tier4_4cam_des1's setup
$ sudo mount /dev/mmcblk0p1 /mnt
$ cd /mnt
$ ls
   tier4_4cam_des1  tier4_4cam_des2 tier4_8cam tier4_4cam_des1_fsync tier4_4cam_des2_fsync tier4_8cam_fsync
$ sudo cp tier4_4cam_des1/system.dtb .
$ sudo reboot

Camera triggering functionality

If you want to change the cameras' operation mode to the fsync-based capture, you will need to kill all the gstreamer-related instances, and restart the streaming by using the corresponding script, in this way the cameras will redo a stream-on at start time and the new operation mode will be applied. In case, you are changing the parameters of the trigger pins, you can let the gstreamer-related instances open, and the settings will be applied directly.

The video capture of the GMSL cameras can be controlled through a hardware trigger block implemented in the FPGA logic. This block allows independent control of the triggering for each of the 8 cameras with user specified period, duty cycle and offset, by using the FSYNC signal of the GMSL serializers. The triggering functionality can be accessed through a web application running on the device, at the IP address of the 10GEthernet interface, on port 3000 : e.g. 10.42.0.124:3000.

The default setup of the web application is the one with 8 cameras (in terms of cameras' trigger/non-trigger mode setup in applyTriggerMode function - server.js file from the backend directory of the application). In case of using only one deserializer (dtb for the deserializer 1/2), you can configure the subdevs' numbers from the applyTriggerMode function to the corresponding values (subdev_11/12/13/14).

The frequency of the triggers is specified in Hz, in the range of 1Hz to 200Hz, while the phase offset is set in ns. Since the FPGA trigger logic runs on a 100MHz clock, the minimum increment for the phase offset if 10ns.

The system starts by default in Free running mode and this can be changed by selecting the Triggered mode in the web GUI. All the settings specified in the web GUI are applied only when pressing the Apply button.

The command shell. Below is an example of how to control the trigger settings for camera 0 through Linux commands. Each camera has an associated /sys/class/pwm/pwmchipX channel that can be controlled in the same way. Trigger-related settings can be controlled by directly writing the into the driver of the FPGA-based trigger block from the Linux pwm-device's sysfs interface:

Example of fsync mode setup for camera 1 (des1 dtb approach) + pwm0 channel setup

sudo v4l2-ctl -d /dev/v4l-subdev11 --set-ctrl=fsync_source=1
 
sudo echo ${value} > /sys/class/pwm/pwmchip0/pwm0/period
sudo echo ${value} > /sys/class/pwm/pwmchip0/pwm0/duty_cycle
sudo echo ${value} > /sys/class/pwm/pwmchip0/pwm0/phase
sudo echo "nanosecond" > /sys/class/pwm/pwmchip0/pwm0/time_unit
sudo echo 0> /sys/class/pwm/pwmchip0/pwm0/enable
sudo echo 1> /sys/class/pwm/pwmchip0/pwm0/enable

Example of free-running mode setup for all cameras (des1 dtb approach)

sudo v4l2-ctl -d /dev/v4l-subdev11 --set-ctrl=fsync_source=0
sudo v4l2-ctl -d /dev/v4l-subdev12 --set-ctrl=fsync_source=0
sudo v4l2-ctl -d /dev/v4l-subdev13 --set-ctrl=fsync_source=0
sudo v4l2-ctl -d /dev/v4l-subdev14 --set-ctrl=fsync_source=0
Location of the GMSL-Trigger-Control Web App is: /home/analog/Workspace/gmsl-10gbe-webgui. To start this NodeJS-based application, you can follow the instructions from the README file located inside the application's directory. All the dependencies for the application are pre-installed in the provided gmsl-10g-fsync Image.
Default setup of the gmsl-10g-fsync Image: des1_fsync-related dtb. To change to 8cams_fsync setup you could copy the system.dtb from the tier4_8cam_fsync directory, as indicated in the Configure the System chapter

Displaying the Video

On the receiving side, Gstreamer must be installed

Single deserializer-based transmission with different fsync periods


playground/gmsl-kria-guide.txt · Last modified: 12 May 2024 20:52 by Alin-Tudor Sferle