Issues about installing linux-headers-$(uname -r)

Hello Nvidia support team,

Platform: Jetson Nano
System: Jetpack4.4.1, R32.4.4

For compiling my camera drive code, I need to install the v4l2 headers in /lib/modules/$(unmae -r).
I get the errors as below:

sudo apt install linux-headers-$(uname -r)
Reading package lists… Done
Building dependency tree
Reading state information… Done
E: Unable to locate package linux-headers-4.9.140-tegra
E: Couldn’t find any package by glob ‘linux-headers-4.9.140-tegra’
E: Couldn’t find any package by regex ‘linux-headers-4.9.140-tegra’

can somebody help me? thanks in advance.

You can download the source code from our r32.4.4 archive. There is no such header file from apt list.

thanks for reply.
but could you tell me exactly under the r32.4.4 archive where to find the files about v4l2 headers and how to install them. That will be very helpful.

What follows is just one long alternative way to obtain and configure the “equivalent” of headers. I use this sort of method because full source is almost always better than just headers (only it takes a lot more disk space…but not too much if you don’t build an actual kernel Image). Consider what follows to be a superset of headers, and more extensive than what the 2GB model source would provide. Keep in mind while looking at this that the key to the difference between 2GB and other modules is a combination of device tree and kernel configuration…the source itself is meaningless unless it is configured to match your running system.

Typically you would just download the full source for the kernel. This includes the headers, and if something wants to point at headers, then pointing at the full source also works. The trick is that the source needs to be configured for that particular config (including CONFIG_LOCALVERSION, which usually is “-tegra”).

L4T releases are listed here:

For R32.4.4 the URL is here:

For the Nano of that release the URL of source code shows as:
but this probably does not contain everything the non-Nano sources have. Specifically, the source code of the kernel itself should be the same for the non-Nano versions, and the source for the Nano would be only a subset of what is shown for the Nano. The kernel of the Nano would probably be ok, and there is even a “.deb” package listed which might do what you want, but I suggest looking at this (the non-Nano source):

This is a tar archive, and the package path within this archive for “source->public->kernel_src.tbz2” would be the correct content once configuration is set to match the Nano’s configuration. Notice that you’d unpack the full kernel_src.tbz2 since for some NVIDIA components, when configured in the “kernel->kernel-4.9/”, that the config will require a relative path referring to the other subdirectories (most third party configurations would never need this).

If you have a running Nano, then you should see “/proc/config.gz”. If you save a copy of this somewhere (permanent for future use), and then edit just the “CONFIG_LOCALVERSION” (this would be set ‘="-tegra"’ in the file because “-tegra” is the suffix of the output of “uname -r”), then this should be an exact match to your running system and also be the correct “.config” to use with “make prepare” and “make modules_prepare”. Those prepare statements should make the kernel configure to the exact running system if the “.config” is in place, and this in turn should make it possible to treat the full source as if it were the headers only.

Once you have this, point a symbolic link from “/lib/modules/$(uname -r)/build” to the “source->kernel->kernel-4.9/” location and it should work as if it were headers. Example, assuming native build on the Jetson:

cd /lib/modules/$(uname -r)
sudo ln -sf /where/ever/it/is/source->kernel->kernel-4.9 build
# Then verify source exists at "ls /lib/modules/$(uname -r)/build/*".

this is my original problem, “v4l2-fwnode.h” is missing.
I want to compile my camera driver code, then I get this error:

fatar error: media/v4l2-fwnode.h: No such file or directory
#include <media/v4l2-fwnode.h>
compilation terminated.

then I was recommended to install the linux-headers-$(uname -r). that’s the reason why I get this issue.

as I understand, your solution is to link a more completed linux kernel
I have downloaded and unpacked the files and tried to search the file “v4l2-fwnode.h”, but not find it. therefore I think even i link it to the downloaded files(linux kernel), it would not work.
But I’ll try…

What is the kernel version of your camera driver? The kernel running on jetson is k4.9.

If you are using a incompatible kernel version, then the header may not exist.

that’s good point. I’m checking it with my college.

If he used a newer kernel version, and I’m using k4.9.
is there still any solution to solve this problem?

Typically it would not be easy, and would probably require back porting the newer kernel feature to the older kernel. Hard to give a good answer though since it depends on the feature.

I just need this file in v4l2-core:
#include <media/v4l2-fwnode.h>

it exists in the newer version of linux kernel, but not 4.9.140-*.
Is there some solution to add it into the kernel and make the functions available?

I can’t guarantee it, but so far as I can tell this doesn’t exist prior to the 5.x kernel release. See:

I could not find any definitive information on this, so I could be wrong on the above. I do have several kernels installed in both 4.x series on Jetsons, plus 5.x on the host PC (Jetsons have not yet made their way to a 5.x series kernel), and the only existence of “v4l2-fwnode” was in the 5.x kernel series.

in jetson nano there is a file v4l2-of.h, I think this is the older version of v4l2-fwnode.h.
I just replace the functions and the parameters, it works. successfully compiled.

Now the problem is about device tree, which device tree file should I edit?
Deeply appreciate for any help:)

I couldn’t tell you which to edit. Basically the device tree is an argument passed to a driver, and so older/newer drivers might have different parameters, or they might be unchanged. The name of the driver might also change (at least for what the device tree calls it). Basically you’d want to see the old tree content, and compare to a working system’s newer tree. Perhaps nothing changed.

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