FPD Link ||| interface Card issue with Jetson AGX Xavier


I followed the BSP v4.0.0 Release Notes to configure the Jetson AGX kit with FPD-LINK card to run some camera based applications.


  1. I Flashed Jetpack 4.4 (L4T32.4.3) in AGX Xavier.

  2. Ran the following command to install new Linux Kernel and D3 DTBs.-

sudo apt update && sudo apt install

  1. Restart the AGX to install further d3 utilities to access the camera.


After Restart D3 logo is there but soon after the Monitor screen goes blank and it continues to restart again and again…(Does not Boot).

I reflashed Jetpack 3 times and tried the above steps again but with the same result.

Not sure what the problem is here.


Whenever I run the above mentioned command, it says warning of a mismatched version of Jetpack but I have installed the correct version.

@D3_jenslin , Please suggest me the way to setup the FPD Link ||| card with Jetson AGX Xavier.



D3-Jetson-BSP-Release-Notes.pdf (8.5 MB)

Have you tried to contact with D3 Tech Support: support@D3Engineering.com ?

I have already mailed them in getstarted@d3engineering.com but did not get reply. I will do with support email also…
Till then if possible can i get some reply here?

Hi Sharma,

One of our engineers will be in touch with you shortly to help. I can also confirm we have received your email to support. The email to getstarted unfortunately got filtered out by mistake.


HI Sharma,

This sounds like the Ubuntu unattended-upgrade issue that we’ve seen a few times before on JP 4.4. If you disconnect the monitor that should stop the boot-loop and you’ll be able to access the system via SSH. If so, you can use the following command to see if an unattended upgrade has occurred.

# List l4t packages, exclude kernel since it follows a different version format
dpkg -l | grep nvidia-l4t | awk -F ' ' '{print $2}'

If the versions you get back don’t match what is in /etc/nv_tegra_release then unattended upgrade is very likely the issue. To fix this you can either manually roll back the packages, or re-flash and disable unattended-upgrade. Either way you’ll need to disable unattended-upgrade (see command below). If you go the “re-flash and disable” route make sure to run the command below before doing anything else on the system.

sudo systemctl disable --now apt-daily-upgrade.timer apt-daily.timer

Let me know how things go, I’m happy to help further if needed.




I ran the command and got the following results-
dpkg -l | grep nvidia-l4t | awk -F ’ ’ '{print $2}'

and for cat /etc/nv_tegra_release

R32 (release), REVISION: 4.4, GCID: 23942405, BOARD: t186ref, EABI: aarch64, DATE: Fri Oct 16 19:37:08 UTC 2020

Not sure to interpret the results.

Also if this is the issue and i need to go reflash step again so should i follow this? -
*)reflash jetpack4.4 with jetson SDK components.
*)run the command -
sudo systemctl disable --now apt-daily-upgrade.timer apt-daily.timer
*) run the command-
sudo apt update && sudo apt install

or anything else

Please suggest.


The command I provided was slightly off. If you run the command below it will give you the full output.

 dpkg -l | grep nvidia-l4t

You should be able to see the versions after the package names, and they should start with 32.4.4 based on the contents of nv_tegra_release. If the versions are different then we are on the right track with re-flashing and disabling upgrades.

The procedure you outlined looks good.

This is following output-

dpkg -l | grep nvidia-l4t
ii nvidia-l4t-3d-core 32.4.4-20201027211332 arm64 NVIDIA GL EGL Package
ii nvidia-l4t-apt-source 32.4.4-20201016123640 arm64 NVIDIA L4T apt source list debian package
ii nvidia-l4t-bootloader 32.4.4-20201027211332 arm64 NVIDIA Bootloader Package
ii nvidia-l4t-camera 32.4.4-20201027211332 arm64 NVIDIA Camera Package
ii nvidia-l4t-configs 32.4.4-20201016123640 arm64 NVIDIA configs debian package
ii nvidia-l4t-core 32.4.4-20201016123640 arm64 NVIDIA Core Package
ii nvidia-l4t-cuda 32.4.4-20201027211332 arm64 NVIDIA CUDA Package
ii nvidia-l4t-firmware 32.4.4-20201027211332 arm64 NVIDIA Firmware Package
ii nvidia-l4t-graphics-demos 32.4.4-20201027211332 arm64 NVIDIA graphics demo applications
ii nvidia-l4t-gstreamer 32.4.4-20201016123640 arm64 NVIDIA GST Application files
ii nvidia-l4t-init 32.4.4-20201027211332 arm64 NVIDIA Init debian package
ii nvidia-l4t-initrd 32.4.4-20201016123640 arm64 NVIDIA initrd debian package
ii nvidia-l4t-jetson-io 32.4.4-20201016123640 arm64 NVIDIA Jetson.IO debian package
ii nvidia-l4t-jetson-multimedia-api 32.4.4-20201027211332 arm64 NVIDIA Jetson Multimedia API is a collection of lower-level APIs that support flexible application development.
ii nvidia-l4t-kernel 4.9.140-tegra-32.4.4-20201027211332 arm64 NVIDIA Kernel Package
ii nvidia-l4t-kernel-dtbs 4.9.140-tegra-32.4.4-20201027211332 arm64 NVIDIA Kernel DTB Package
ii nvidia-l4t-kernel-headers 4.9.140-tegra-32.4.4-20201027211332 arm64 NVIDIA Linux Tegra Kernel Headers Package
ii nvidia-l4t-multimedia 32.4.4-20201027211332 arm64 NVIDIA Multimedia Package
ii nvidia-l4t-multimedia-utils 32.4.4-20201027211332 arm64 NVIDIA Multimedia Package
ii nvidia-l4t-oem-config 32.4.4-20201016123640 arm64 NVIDIA OEM-Config Package
ii nvidia-l4t-tools 32.4.4-20201027211332 arm64 NVIDIA Public Test Tools Package
ii nvidia-l4t-wayland 32.4.4-20201027211332 arm64 NVIDIA Wayland Package
ii nvidia-l4t-weston 32.4.4-20201027211332 arm64 NVIDIA Weston Package
ii nvidia-l4t-x11 32.4.4-20201027211332 arm64 NVIDIA X11 Package
ii nvidia-l4t-xusb-firmware 32.4.4-20201016123640 arm64 NVIDIA USB Firmware Package

cat /etc/nv_tegra_release

R32 (release), REVISION: 4.4, GCID: 23942405, BOARD: t186ref, EABI: aarch64, DATE: Fri Oct 16 19:37:08 UTC 2020

Should i consider nvidia-l4t-kernel/nvidia-l4t-kernel-dtbs are changed because others are same.


Thank you for providing that output. Since the package version numbers are 32.4.4*, and that matches nv_tegra_release I don’t think unattended upgrade is the issue. The kernel version being slightly different is expected, the important part is the 32.4.4 in there.

Looking at the contents of nv_tegra_release, I think you are installing JP 4.4.1 (L4T 32.4.4). I think it is worth-while to try installing JP 4.4 (L4T 32.4.3), even minor upgrades from NVIDIA sometimes cause problems with our release.

Thanks for the support.
As you suggested, it is working now.

One last general query-
I have D3RCM-OV10640 camera and also running with “argus_camera” utility.

  1. I just used deepstream to check if i can run some video analytics on top of this camera with v4l utils. I am able to see the node /dev/video0 but it is not running as ffplay also not with deepstream beside providing correct parameters of camera like-

v4l2-ctl -d /dev/video0 --list-formats-ext
Index : 0
Type : Video Capture
Pixel Format: ‘BA12’
Name : 12-bit Bayer GRGR/BGBG
Size: Discrete 1280x1080
Interval: Discrete 0.033s (30.000 fps)

Index       : 1
Type        : Video Capture
Pixel Format: 'BG12'
Name        : 12-bit Bayer BGBG/GRGR
	Size: Discrete 1280x1080
		Interval: Discrete 0.033s (30.000 fps)

Any suggestions? if i can run this camera with Deepstream ? if not so anything there for some video analytics example to get started?



I’m glad we could get to the bottom of the setup issues. As far as streaming goes, just to confirm, you are able to stream with both v4l2 (see command) and argus_camera?

v4l2-ctl -d /dev/video0 --stream-mmap  --stream-count=60

These Gstreamer examples may also be helpful: Jetson Linux

For video analytics I think Deepstream would be your best bet, though I’m not sure how much support I can provide in that area. At the camera access level Deepstream depends on Gstreamer, which is supported with our cameras. The easiest way to test Gstreamer functionality would be with nvgstcapture.

# N is the camera idx, 0 -> /dev/video0
nvgstcapture --sensor-id 0

I ran v4l-ctl command as you mentioned also as given in the Release notes, but no output no error is there. It hangs after i hit Enter.

nvgstcapture --sensor-id 0 runs but it is giving light purple video output although video is running.

If i set camera resolution in gst-launch command then it runs fine. like-
gst-launch-1.0 nvarguscamerasrc ! ‘video/x-raw(memory:NVMM), width=1920, height=1080, format=NV12, framerate=30/1’ ! nvoverlaysink.

Hi @jkiggins ,

I made it work with Deepstream.

The only thing is the command v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=60 does not gave me any output.

BTW Thanks for the support.


I’m glad you were able to get things working!

It looks like the command I provided was slightly off, to stream w/ v4l2 after streaming with Argus the bypass mode control needs to be set.

v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=60 -c bypass_mode=0

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.