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:
cd /lib/modules/$(uname -r)/kernel”, then “
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
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:
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).