Kernel make execution creates hardware folder on my desktop cont

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
1

Hi,
I followed the steps without using sudo but got the same result - the hardware dir is created on desktop.

Sorry for the late response resulted in closing the discussion :

2

Did you configure and set up like this prior to the issue?
https://forums.developer.nvidia.com/t/kernel-make-execution-creates-hardware-folder-on-my-desktop/262213/27

I want to be sure you are not just building “everything”, and are building specific targets.

3

yes.
I verified that only after building the dtbs, the folder appears.
I used sudo only with make mrproper as you said.
these the command I used:

KERNEL_PATH=$WORKSPACE_PATH/Linux_for_Tegra/source/public/kernel/kernel-5.10/
cd $KERNEL_PATH
pwd
ls -l
export ARCH=arm64
export CROSS_COMPILE=$CROSS_COMPILE_AARCH64
sudo make mrproper
echo $WORKSPACE_PATH
ls $WORKSPACE_PATH/Out
ls -l $WORKSPACE_PATH/Out/.config
make O=$WORKSPACE_PATH/Out tegra_defconfig
make O=$WORKSPACE_PATH/Out -j 16 Image
make O=$WORKSPACE_PATH/Out -j 16 modules_prepare
make O=$WORKSPACE_PATH/Out -j 16 modules
make O=$WORKSPACE_PATH/Out -j 16 dtbs # this creates the desktop hardware folder

build log:
build.log (554.4 KB)

4

Let’s try a different test. Right now this is where your kernel source is:

/home/bsp/Desktop/Workspace_5_1_1/Linux_for_Tegra/source/public/kernel/kernel-5.10/

Can you move the source and the output locations to another directory deeper in? Invent some empty location that is not part of the “~/Desktop”. For example:

mkdir -p ~/tmp1/tmp2/tmp3

I used several subdirectories because I want to see if the extra file output goes to “~/Desktop”, or if it keeps descending an exact number of parent directories. If the excess goes to “~/Desktop”, then we know that it is something “wired” to the environment. On the other hand, if the excess goes to somewhere in “~/tmp1/tmp2/tmp3”, then we know it is “wired” to the number of “../” "(_ddot_) of the Makefile.

You could use “mv” of “Workspace_5_1_1/” to that location, or you could download and unpack the kernel source there. Just make sure you know any extra files have been eliminated from “~/Desktop” before you start so you can identify if they end up populating that location again.

5

I moved Workspace_5_1_1 into /home/bsp/tmp1/tmp2/tmp3.
So now $WORKSPACE_PATH is /home/bsp/tmp1/tmp2/tmp3/Workspace_5_1_1

The new hardware dir is created inside tmp3 next to the Workspace_5_1_1 folder

6

Then the number of cd .. (_ddot_ macros) is causing this. Too many exist in a row. This could be:

  • Added _ddot_ such that there are too many.
  • The directory the compiler thinks it is in is wrong, and had failed to go into a subdirectory; as a result, it would descend down too far into parent directories. An example would be if there is a permission issue which does not stop compile.

Are there both files and subdirectories created in tmp3/? If you start at tmp3/, what do you see from:

  • ls -aldF * .
    (note that the “* .” is not a mistake, be careful to copy and paste the above exactly)
  • cd ...name of subdirectory..., then “tree -d”?

You can log either to a file:

  • ls -aldF * 2>&1 | tee parent.txt
  • From the subdirectory, "tree -d 2>&1 | tee subdir.txt

Hopefully kernel-5.10/ is owned by root, and writable only by root, but all output locations are owned by a regular user.

7

I attached all the information you requested.
the Out dir is owned by user, the kernel dir is owned by user as well

Out_dir.log (347 Bytes)
parent.txt (105 Bytes)
tree_hardware.log (702 Bytes)
tree_Workspace_5_1_1.log (559.1 KB)
kernel-5.10.log (354 Bytes)

8

I wish I had suggested also pairing the command used and the directory from which a command is used to the output logs. However, let me ask specifically about the output of tree_hardware.log:

.
└── nvidia
    └── platform
        ├── t19x
        │   ├── galen
        │   │   └── kernel-dts
        │   ├── galen-industrial
        │   │   └── kernel-dts
        │   ├── jakku
        │   │   └── kernel-dts
        │   └── mccoy
        │       └── kernel-dts
        └── t23x
            ├── concord
            │   └── kernel-dts
            ├── mandalore
            │   └── kernel-dts
            ├── p3768
            │   └── kernel-dts
            └── prometheus
                └── kernel-dts

20 directories

Was this from tmp3/? I ask because in the tree_Workspace_5_1_1.log file I only see subdirectory “hardware/” (which was added to tmp3/?) in other subdirectories. In the case of the tree_hardware.log/ I could see this being put somewhere not expected since it is a firmware output function (firmware can be told to install to an alternate location, and this is the firmware). Sorry to keep asking for details, but it is a bit confusing compared to sitting down and performing the build and just watching as it appears. If it turns out that the “hardware/” is part of tmp3/, and that this is firmware, then we are getting closer, but if not, it is just strange.

9

Its ok thank you for your help.

I just want to summarize the process we’ve done so far:

  1. At first I told you that when I build the kernel I noticed that an extra unnecessary hardware dir is created on my desktop (my workspace folder was on the desktop as well)

  2. With your help we saw that this is happens only after building the dtbs (make command with dtbs)

  3. You told me to copy the workspace dir from the desktop into ~/tmp1/tmp2/tmp3. I’ve done it and built again. Then we saw that the extra hardware dir was created in tmp 3 (again, near the workspace dir)

  4. All this time the extra hardware dir is what you see from tree_hardware.log the only difference is that sometimes it created on the desktop and sometimes on tmp3 (and now we know its probably related - it will always be created next to the workspace dir)

So to answer your questions:

  1. ~/tmp1/tmp2/tmp3 contains:
    hardware (tree_hardware.log)
    workspace (tree_workspace_5_1_1.log)

you can see the tmp3 files in the parent.txt file (as you told me to send you) which is actually the output of ll ~/tmp1/tmp2/tmp3

  1. Inside the workspace dir I have another hardware dir as you said but that hardware dir is the “good” one. that’s the folder I get from unpacking the kernel_source tar.

The difference between the “good” hardware dir (inside workspace dir) and the extra unnecessary one (near workspace dir), is that there are no files inside the bad hardware dir - only subfolders.

10

At this point it does look like an error of how the dtbs target is set up. One option you might try to force it to a new empty directory location is to include the “INSTALL_FW_PATH=...somewhere...”. Example (using a simplified build line just to provide an example…adjust anything not actually matching your setup):

mkdir -p ~/jetson/device_tree
mkdir -p ~/jetson/output

export TOP=/home/bsp/tmp1/tmp2/tmp3/Workspace_5_1_1/Linux_for_Tegra/source/public/kernel/kernel-5.10
export TEGRA_FIRMWARE_OUT=~/jetson/device_tree
export TEGRA_KERNEL_OUT=~/jetson/output

cd $TOP
make -j 12 O=$TEGRA_KERNEL_OUT INSTALL_FW_PATH=$TEGRA_FIRMWARE_OUT dtbs

There are more steps involved, but notice that build command now includes “INSTALL_FW_PATH”. This should aim firmware output to a specific location. Try that from tmp3 and see if it resolves software going to the wrong place. It is possible that firmware would end up in both locations and not be fixed, but if this does fix it, then specifying the firmware output path would work from then on as a workaround.

11

I tried adding the “INSTALL_FW_PATH=$TEGRA_FIRMWARE_OUT” flag but it doesn’t work.
The new folder with path $TEGRA_FIRMWARE_OUT remains empty and the new hardware folder is still created in tmp3

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.

13

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