Auvidea J120 and Intel RealSense D435

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
21

Silly me - I copied in the newly built Image, but not the zImage - after copying both it seems to be working flawlessly - I can’t thank you both enough for the help and insight.

My final list of steps to get here:

  • Patch Jetpack with corresponding Auvidia firmware and flash device
  • Download the matching L4T kernel source package
  • Copy /proc/config.gz to .config in the source tree on the host computer
  • Apply the realsense kernel patches from librealsense (following the patching script from buildLibRealsense2TX)
  • Apply the config modifications from buildLibRealsense2TX from JetsonHacks
  • Build the kernel Image and zImage and copy to /boot on the device
  • Use the scripts from buildLibRealsense2TX to patch the librealsense source for jetson, and build.

Phew!

22

Hi @haljarret,

cool that you got it working :) my difference from your steps was that I flashed TX2 second time as well using Jetpack with my new kernel cross-compiled from source and dtbs from Auvidea. You followed a slightly different path and just replaced the kernel in the target machine. Well now we know that both methods work :)

I have an IMU on Auvidea as well and just tested using it and it also work flawlessly. If you have one, then it will be good to test it as well while you are at it.

23

Hello,

I want to use my D435 device on my TX2 with J120 auvidea carrier board.
Without patching anything, my D435 is recognized as an USB2 device and I cannot use it (same story as yours). I have to patch the kernel and I want to follow yours steps but I’m a newbie in this kind of operations.

So I would like to have more explanation about how to proceed for some steps :

  • Patch Jetpack with corresponding Auvidia firmware and flash device
  • Download the matching L4T kernel source package
    * Copy /proc/config.gz to .config in the source tree on the host computer
    ==> In which folder do I have to put .config in the source tree on the host computer, when I’m in 64_TX2 folder of the jetpack ?
    * Apply the realsense kernel patches from librealsense (following the patching script from buildLibRealsense2TX)
    ==> Is this step done on the TX2 device ?
  • Apply the config modifications from buildLibRealsense2TX from JetsonHacks
  • Build the kernel Image and zImage and copy to /boot on the device
  • Use the scripts from buildLibRealsense2TX to patch the librealsense source for jetson, and build.

Thank you in advance for help

Christophe

24

The file “/proc/config.gz” is a gzip compressed pseudo file. This isn’t really on the disk, it is the kernel pretending this is a file and reflecting what its running configuration is. If the kernel changes, so does the config.gz here. If you copy it somewhere else, then use “gunzip config.gz”, and then rename the resulting “config” file to “.config”, then the kernel build can use that as its configuration.

There is an exception, but other than the one exception, the “/proc/config.gz” is an exact match of that running kernel. The exception is that the “CONFIG_LOCALVERSION” of config.gz is not filled in. You need to do that yourself, e.g., through one of the kernel config editors after the file is set up as “.config” in the right place, or directly with a text editor.

The significance of CONFIG_LOCALVERSION is that it helps determine where the kernel searches for modules. If the kernel version is 4.4.38, and if the CONFIG_LOCALVERSION is “-tegra”, then the command “uname -r” will respond “4.4.38-tegra”. Without CONFIG_LOCALVERSION “uname -r” would just respond “4.4.38”. Modules are searched for here:

/lib/modules/$(uname -r)/

If your original kernel is “4.4.38-tegra”, and if your new kernel is also “4.4.38-tegra”, then the new kernel will use the module directory which already exists. If the “uname -r” changes, then you have to create a complete new set of kernel modules at “/lib/modules/$(uname -r)/”.

When you get the kernel source and unpack it somewhere, the top level directory of the source (where you see the “Makefile”, “README”, and “MAINTAINERS” file) is where you place “.config”. Be sure to save a copy somewhere else as well where it is safe…you may want to refer to this again later when running a different kernel.

I can’t help with realsense, someone else need to reply. Generally speaking though, if this is a kernel patch, then it patches some file within the kernel source…one or more subdirectories to where you put the .config file will have files which the patch can modify. Depending on what you are doing, then this eventually reaches the Jetson regardless of where you build the kernel. Patches might modify a module, or they might modify the base kernel Image. If only a module changes, then you only need to install a new module. If only the Image changes, then possibly only the Image file needs replacement when “uname -r” is not modified (but if Image itself changes it could possibly invalidate modules and require you to rebuild those as well…which is when you would purposely change “uname -r” so you can keep both old and new module directories).

25

linuxdev has explained the kernel config bit in detail. Jetsonhacks has published the kernel config and patch scripts to build the kernel on Jetson device but you can use the config and patch procedures to do it on host computer like I did and build the kernel. Once built I used Jetpack installer to flash the kernel image to my device.

To install realsense sdk I did the whole process on jetson device. Downloaded sources then build the sdk on device and install.

26

Sorry for the necroposting,I have a very newbie question. I followed almost all the steps, but my issue occurs when I try to build the kernel Image/zImage. I try this commands:

make prepare
make modules_prepare
make Image

But the last command don’t find a Image rule on the Makefile.
@linuxdev can i ask you what is the way to do it? Thanks

27

The first note is that if you prepare, but have not first configured, then this won’t help.

The second note is that if you are building from outside of the kernel tree, for example to build a third party module, then you cannot build “Image” from there…you need the full source to build Image. The combination of “make prepare” and “make modules_prepare” is normally only performed for people doing only module build, but “Image” is a full kernel build.

Here is a more detailed note on kernel compile:
https://devtalk.nvidia.com/default/topic/1038175/jetson-tx2/tx2i-wifi-support/post/5274619/#5274619

Do note that information on extlinux.conf is probably out of date there, but this is related to install of the Image and not the build of Image. Actual install procedure will depend on your particular L4T/JetPack release, and that thread was written when U-Boot had more participation in boot.

28

Thank for your reply. I’m a bit confused…
I try to explain my situation. I have the TX2/J120 working with the Auvidea provided firmware.
So I copied the /proc/config.gz from tx2 (zcat config.gz > .config) on my host computer in kernel-4.4 (28.2.1 sources).
I set the environmental variables for cross-compile.
I applied the realsense’s patch, I adjust .config with make nconfig.
Now when i try make O=$TEGRA_KERNEL_OUT Image, it’s restart all the config, I don’t understand why…

make O=$TEGRA_KERNEL_OUT Image
make[1]: ingresso nella directory "/home/xxxx/Image/output"
  GEN     ./Makefile
scripts/kconfig/conf  --silentoldconfig Kconfig
warning: (SPI_TEGRA186_AON && TEGRA_BPMP && TEGRA_BPMP) selects TEGRA_HSP which has unmet direct dependencies (ARCH_TEGRA)
warning: (SPI_TEGRA186_AON && TEGRA_HV_MANAGER && TEGRA_BPMP && TEGRA_BPMP) selects TEGRA_IVC which has unmet direct dependencies (ARCH_TEGRA)
*
* Restart config...
*
*
* Linux/arm64 4.4.38 Kernel Configuration
*
Tegra 21x family SOC (ARCH_TEGRA_210_SOC) [N/y/?] (NEW)
29

The problem is likely that the “.config” must be in the “$TEGRA_KERNEL_OUT” location, and not in the actual “kernel-4.4/” subdirectory (unless you are outputting to the input, which wouldn’t make sense). Within the “kernel-4.4/” you should probably do a “make mrproper” (no “O=$TEGRA_KERNEL_OUT” since you are cleaning up the original source tree), recursively delete all content in the “$TEGRA_KERNEL_OUT”, add the “.config” to the “$TEGRA_KERNEL_OUT”, and then continue as you did (with even the “make O=$TEGRA_KERNEL_OUT nconfig” having the “O=…” content…every command needs the “O=…” added).

The idea is to keep the original kernel source pristine, and to have all configurable or temporary output go to “O=$TEGRA_KERNEL_OUT”.

30

Thanks, now it’s compile, but the build fails…

drivers/built-in.o: nella funzione "nvs_remove":
/home/xxxx/test/kernel/kernel-4.4/drivers/misc/nvs/nvs_iio.c:1804: riferimento non definito a "devm_iio_kfifo_free"
drivers/built-in.o: nella funzione "nvs_init":
/home/xxxx/test/kernel/kernel-4.4/drivers/misc/nvs/nvs_iio.c:1846: riferimento non definito a "devm_iio_kfifo_allocate"
/home/xxxx/test/kernel/kernel-4.4/Makefile:959: set di istruzioni per l'obiettivo "vmlinux" non riuscito
make[1]: *** [vmlinux] Errore 1
make[1]: uscita dalla directory "/home/xxxx/Image/output"
Makefile:150: set di istruzioni per l'obiettivo "sub-make" non riuscito
make: *** [sub-make] Errore 2

It’s the same error of nouman.hanif, but I don’t know how to resolve it…

31

I solve this error marking in the kernel configuration “Industrial I/O buffering based on kfifo” like (*) built-in instead of module (in the jetsonhack’s configure script was a module). What can be the difference? Will it be a problem?

Do you suggest to use a localversion different from “-tegra”?

32

When a feature is integrated the feature is always available. Nothing related to the feature will be listed in “lsmod” because no module is used. During boot this implies the feature is available even before modules are loaded (loading modules requires reading an ext4 filesystem, but the Image is loaded prior to ext4).

If you are merely adding to the kernel Image in such a way that the original configuration is otherwise preserved, then typically you will not need to build new modules unless the “-tegra” is not preserved.

If you were to remove functionality, or to build a conflicting configuration where the previous module configuration becomes a conflict, then it would be mandatory to change the “-tegra” and build everything. This would include new modules to go in a new alternate module location as “uname -r” changes.

If you were the one which added the kfifo feature, but other features still exist without conflict, then you are done after adding the Image with a correct matching “uname -r” (the “-tegra”). If the kfifo feature already existed as a module, then maybe you could get away without rebuilding all of the modules, but there is a significant chance you’d need to also rebuild modules.