Kernel make execution creates hardware folder on my desktop cont

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
12

@bsp_dev, you might try this too just to verify for anyone reproducing this. I might have found the issue in a missing _ddot_. However, the issue might still exist. You’ll have to try this.

While trying to recreate this issue I discovered a bug during module build (perhaps this is already fixed in newer releases?):

/home/nvidia/Downloads/deleteme/test/tmp1/tmp2/tmp3/kernel/nvidia/drivers/media/i2c/ar1335_common.c:29:10: fatal error: ./include/./../../../nvidia/drivers/media/platform/tegra/camera/camera_gpio.h: Permission denied
   29 | #include "./../../../nvidia/drivers/media/platform/tegra/camera/camera_gpio.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

An include path listed in “kernel/nvidia/drivers/media/i2c/ar1335_common.c” line 29 is incorrect. It needs an extra “../” (known in macros as a _ddot_) since it has too few of them. The original line 29, and the corrected line 29:

// Original:
#include "./../../../nvidia/drivers/media/platform/tegra/camera/camera_gpio.h"
// Corrected:
#include "./../../../../nvidia/drivers/media/platform/tegra/camera/camera_gpio.h"

(corrected has 4 “../”, original has 3 “../”)

Make that edit, and try building again. This might or might not solve the issue. Maybe there are more errors like this one.

 

Test procedure for reproducing this follows. Edit the above mentioned kernel/nvidia/drivers/media/i2c/ar1335_common.c first before actually configuring or building:

 

To summarize for an attempt to make this reproducible. Summary to reproduce follows. Note that since the file edit mentioned at the start may not be a fix that this procedure should be followed whenever trying to make this reproducible (or the case might be solved, need @bsp_dev to confirm if this is fixed or not with the file edit given):

  • Go to L4T R35.3.1 downloads (provides public_sources.tbz2). Note: I did not check if a newer release fixes this.
  • Download the “Driver Package (BSP) Sources” (public_sources.tbz2) from that URL, and extracting kernel source:
    • Obtain Linux_for_Tegra/source/public/kernel_src.tbz2 via:
      tar -vx 'Linux_for_Tegra/source/public/kernel_src.tbz2' -f ./public_sources.tbz2
    • You now have Linux_for_Tegra/source/public/kernel_src.tbz2, so you can remove public_sources.tbz2 (this takes up a lot of disk space and for this test you don’t need public_sources.tbz2 once you have kernel_src.tbz2).
    • Go to an empty directory, at least two empty directories deep, e.g.:
      mkdir -p ~/tmp1/tmp2/tmp3
    • mv the kernel_src.tbz2 here to the tmp3 location; you can delete the original download and extracted content, only this file is needed. kernel_src.tbz2 would have been created at the “Linux_for_Tegra/source/public/” location. That location is no longer needed once kernel_src.tbz2 is in its own separate location. I mention this because (A) the other content takes up a lot of disk space, and (B) we want this kernel source all by itself where any bug creating incorrect directories will be spotted.
    • Unpack: tar xvfj kernel_src.tbz2, producing ~/tmp1/tmp2/tmp3/Linux_for_Tegra/source/public/kernel_src.tbz2
    • Do not use any tar options to strip leading directories when extracting kernel_src.tbz2.

From there you will now have new content. The content we are interested in:

  • cd ~/tmp1/tmp2/tmp3/kernel/kernel-5.10/
  • For convenience, from there:
    export TOP=$(pwd)
    (verify with “echo $TOP”)

The goal is to configure this source, then build, and see if any of these now have an extra hardware/ subdirectory (there is a valid hardware/ subdirectory at another location, but this should not exist in any of the tmp directories)

  • ~/tmp1/tmp2/tmp3/
  • ~/tmp1/tmp2/
  • ~/tmp1/

Note: We also need to use a temporary output location, so:

  • mkdir ~/output
  • export TEGRA_KERNEL_OUT=~/output

I am assuming this is cross compiled. Adjust this for your cross tool path if it differs:

  • export ARCH=arm64
  • export CROSS_COMPILE='/usr/lib/aarch64-linux-gnu-'

To configure (the “-j 12” can be adjusted for the number of CPU cores you want to use):

  • cd $TOP
  • make mrproper
  • make O=$TEGRA_KERNEL_OUT tegra_defconfig
  • make -j 12 O=$TEGRA_KERNEL_OUT Image

Now verify nothing extra has appeared in:

  • ~/tmp1/tmp2/
  • ~/tmp1/

Note: ~/tmp1/tmp2/tmp3/ is where content was unpacked to. It is expected that this location will have:

  • hardware/
  • kernel/
  • kernel_src.tbz2 (if you didn’t remove it)
  • nvbuild.sh
  • nvcommon_build.sh

 
However, if anything is in “~/tmp1/” or “~/tmp2/” other than what was put there originally, then this is a bug.
 

Continuing on to build modules from “$TOP”:

  • make O=$TEGRA_KERNEL_OUT -j 12 modules

Sadly, I get a build error here, and this is eliminated by making the edit to add an extra “../” mentioned at the start of this post in ar1335_common.c, line 29; the error message about “Permission denied” is a bad message, and what it should really say is that the path does not exist or is missing:

/home/nvidia/Downloads/deleteme/test/tmp1/tmp2/tmp3/kernel/nvidia/drivers/media/i2c/ar1335_common.c:29:10: fatal error: ./include/./../../../nvidia/drivers/media/platform/tegra/camera/camera_gpio.h: Permission denied
   29 | #include "./../../../nvidia/drivers/media/platform/tegra/camera/camera_gpio.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

One must edit kernel/nvidia/drivers/media/i2c/ar1335_common.c and include one more “../” in the include statement for camera_gpio.h. Then delete and recreate “~/output” so that you can start over with a clean directory (normally I would not completely delete for this, but we are testing something).

Again, no extra content should be found in the tmp1 or tmp2 locations. It is the next step which builds the dtbs target which might cause issues. From $TOP:

  • make O=$TEGRA_KERNEL_OUT -j 12 dtbs

After this edit there should be no added content to “tmp1/” or “tmp2/”. Some computers will behave differently to a missing path than others at times (it sometimes depends on environment; something as simple as a different character set can change results). Maybe this fixes added content.

Let me know if the build works or fails based on extra content. If it works, then that file needs to be patched. If not, I can try again to find the cause.