AGX xavier FPD link, d3 engineering board BSP

Hi, still very new to Linux and Jetson. My goal is to show video from 2x Allied Vision cameras
(Alvium 1800 C-319 Bare Board | 3.2 MP Sony IMX265 CMOS sensor - Allied Vision)

on a Jetson AGX through FPD link.

Ubuntu: 18.04
Package: nvidia-jetpack
Version: 4.6.2-b5

I used SDK manager to flash.

Serializer:
TI DS90UB953

On my Jetson, I have a:
(DesignCore® NVIDIA® Jetson AGX Xavier FPD-Link™ III Interface Card | D3 Engineering)
board with 4x TI DS90UB960 deserializers.

As I understand it, I’d need to have this BSP up and running before moving on but correct me if I’m wrong!

Following the readme, when trying “make sync” I get the following error:

rsync: mkdir “/lib/modules/4.9.140+” failed: Permission denied (13)
rsync error: error in file IO (code 11) at main.c(675) [Receiver=3.1.2]
Makefile:705: recipe for target ‘sync-modules’ failed
make: *** [sync-modules] Error 11

  1. Am I correct in trying to install the BSP?
  2. If I manage to do that, would I then need drivers for the serializer and deserializer?
  3. Any suggestions to fix the above?

Any help appriciated!

I know nothing about the particular hardware or software. In general though, if this is a dev kit AGX Xavier connected to this other device, then the default JetPack/SDK Manager software will correctly deal with the Xavier itself. This is the BSP. However, if you have a custom carrier board (and I don’t know from the picture of the product, but perhaps this is just a separate product going to a dev kit, or perhaps there is an Xavier on the back side of that PCB, which would make it a custom carrier board), then you need the manufacturer’s BSP for the custom carrier instead of the default NVIDIA dev kit BSP (the JetPack/SDKM software flashes the BSP for a dev kit; custom boards are usually the same thing, except for modifications to the device tree).

For perspective, consider that any device which is plug-n-play is able to pass its own information to a driver. For example, when a device plugs in to USB or PCIe, the device will self-describe such that drivers know if they can work with that device, and what options to use during driver load. Non-plug-n-play devices don’t have that luxury, and there must be a method to pass information to the kernel which drivers can use to find that device (a physical address) and options to pass to the driver upon load. The device tree takes care of this latter case and is basically content which a plug-n-play device might have passed automatically (it beats having a different driver for every device which has a different physical address or minor option changes). So device tree edits might be added by a custom device which is not plug-n-play.

If you run the command “uname -r”, then this is information provided by the kernel itself (which is what has drivers talking to devices). The prefix of this is the source code version of the kernel (e.g., “4.9.140”), and the suffix is set as something in a string set by whoever is compiling the kernel (e.g., “+”, though this is somewhat automated and you probably don’t want this, with more explanation below). A kernel module is a dynamically loaded part of the kernel, although it is still part of the kernel. Often this is used with a driver. One finds modules at:
/lib/modules/$(uname -r)/kernel
(try “cd /lib/modules/$(uname -r)/kernel”, then “ls”)

Only the superuser (name “root”, since “root” of the filesystem as a whole is why the name is “root” instead of something like “admin”) can modify content which is owned by root, and kernel drivers are a case of something where only root is allowed to change things. In order to have root permissions you either need to be logged in as root, or prefix your command with “sudo” ("super user do", which asks for a password, and is accepted if your user is on the list of super users). You got "Permission denied" probably because you did not use sudo(sometimes there are other reasons why evenroot` would be denied).

It is apparent that if you are installing to “/lib/modules/4.9.140+” that this is a custom kernel. If this were stock, then the suffix of “uname -r” would be “-tegra” instead of “+”. You can verify this kernel is actually up and running with “uname -r” if it replies “4.9.140+”. If not, then anything you add to that location will be ignored; if it is indeed that location, then all modules must have been built and installed there, else you risk failure to boot. Do you see “4.9.140+” when you run the command “uname -r”? If so, success at what you are doing probably only requires you to get permission to run the “make sync” command (e.g., “sudo make sync”).

Although adding modules does not have much risk, I will warn you that updating the kernel as a whole (non-module integrated content) does have a lot of risk if done wrong. You should probably clone the rootfs before you do any kind of actual kernel update (I wouldn’t bother for module updates).

Normally one would build kernels or kernel modules without “sudo”, but install with sudo.

Incidentally, installing a module is installing a driver. Installing a BSP is more or less flashing the entire system and starting over from scratch. Custom carrier boards imply a custom BSP. The Xavier AGX dev kit is the default BSP. The JetPack/SDK Manager software is a front end to flashing the actual BSP (which is in turn the “Linux for Tegra”/“L4T” content…which in turn is just Ubuntu plus NVIDIA drivers). Releases of L4T and JetPack (which is tied to a specific L4T release unless you start sdkmanager as “sdkmanager --archivedversions”) are available here:
https://developer.nvidia.com/linux-tegra
https://developer.nvidia.com/embedded/jetpack-archive

Since your kernel is a 4.x series, then this implies you are using an L4T R32.x release (well, it could be something more antique, but this is unlikely). That series is tied to JetPack 4.x. You can see your exact L4T release version with “head -n 1 /etc/nv_tegra_release”. Stick to that if you wish to keep compatibility with various APIs. If you went to the L4T 34.x+, which is JetPack 5.x+ for flashing, then your kernel would migrate to a version 5.x, which would not be compatible with a 4.9.140 series kernel (the driver might be available for 5.x, but it would have to be compiled against that kernel source instead of the 4.x version).

hello Aleks-CST,

am I understand correctly that you would like to plug two IMX265 cameras to D3’s FPD-Link III SerDes board?
as you can see in D3’s product page, IMX265 is not included in the compatible hardware options.

please see-also Jetson Ecosystem | NVIDIA Developer, both of Allied Vision and D3 Engineering are our camera partners, you may contact with them directly for your camera solutions.

@linuxdev
Thanks for your reply, will re-read it a few times and do some research. For a quick answer right now:

When I do “uname -r” it gives me:
4.9.253-tegra

@JerryChang
You’re correct, I’m trying to connect two IMX265 to D3 board. We’ve had this up and running before (12 cameras in total) but may have had someone else write drivers for us.

I’m taking over for a former colleague and I’m pretty much starting from scratch. I just need 2 cameras connected though. I will try and contact D3 directly for help. Thanks for your help so far!

If you happen to have the drivers, and are using the default kernel (which it probably is since it has “uname -r” of “4.9.253-tegra”), and if the drivers are compiled against the running kernel’s configuration, then they would go somewhere under:
/lib/modules/4.9.253-tegra/kernel
(the subdirectory thereof would be the subdirectory the module is found after module compile)

If you can find those drivers, and if they were compiled against this configuration, then it is a simple file copy plus “sudo depmod -a” to complete it (and preferably a reboot).

I do not have the drivers as of now, so I realize I’m far off my goal. At the moment I’m mostly confused if I should follow this:

hello Aleks-CST,

I’m a little confused.
don’t this meant the driver is ready? if yes, you just need to port them to the later l4t release versions.

Kind of - this was done with a Yocto build on another Jetson. So I’m not really sure how to access the drivers. This Jetson is meant for a much simpler project with just 2 cameras. So I was hoping to “start over” and get the D3 board up and running myself.

I also have this option for cameras which should make things easier:
https://www.d3engineering.com/product-tag/1000508/

I’m still unsure how to get started with the D3 board. I’ve reached out to D3 but waiting for a reply.

hello Aleks-CST,

it looks like using all their solution could make things easier, please consult with D3 team for further supports.

1 Like

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