Kernel make execution creates hardware folder on my desktop

Hi,
quick question:
I noticed that after executing:

make ARCH=arm64 O=$WORKSPACE_PATH/Out -j16 --output-sync=target

from $WORKSPACE_PATH/Linux_for_Tegra/source/public/kernel/kernel-5.10/
I have a new hardware/nvidia folder on my desktop. it contains all sub directories (identical to public/hardware) but without any non directory file.

something in that make execution cause this. I saw a similar post:

of course I can delete it by myself but its kinda annoying.
Maybe I’m missing something here?

Thanks

I’m a bit confused. First, are you natively compiling, or cross compiling? Using the “ARCH=arm64” implies you are cross compiling, and if native compiling, this would be an error. If you are cross compiling, did you set up your “CROSS_COMPILE” (which is only used in cross compiling)?

I think “--output-sync” has its use, especially if figuring out a build failure, but I don’t use it. Do note that if part of a build fails, and you are building with 16 cores, that you can repeat the build multiple times, and the working build targets will build while failing ones continue to fail. Eventually, all working content is finished and built, and the final build will only put out the errors from the failing build components. I doubt that actually does anything related to any actual error, but it is worth mentioning. That and I’m not sure your build command is correct (you’d have to state if this is native or cross compile).

Note that if you always use the “O=/some/where” (and you should) to some location outside of the kernel source, then the actual source will remain pristine. You can run the “make mrproper” command within the source (without “O=/some/where”) to guarantee that the original source is pristine. I would expect that if you are building any NVIDIA content that you need more than the “kernel-5.10” top directory…you also need the subdirectories of the kernel top’s parent.

There are other subdirectories to those “other” directories. During build you will see some “ddot” macros in the build commands. Each of those is just the “..” in a path, and “..” means “the parent directory of the current directory”. When you go back into parent directories far enough (you’ll see several ddot macros in a series…they add up going to more and more parents of parents), you are no longer within the kernel source; the subsequent path which is then appended to that relative path goes into those other directories for out-of-tree content (content which the configuration system knows about, but which is not shipped with the kernel source).

As an example, if your home directory is “/home/me”, then, if there, you “cd ../../etc”, you will end up in “/etc”. This is the same thing that the kernel build is doing. Whether or not you need those other directories depends on whether or not your configuration references this external content.

Here is a suggestion: Use the “mv” command to temporarily move or rename a directory, then start a clean build and see if it works with your configuration. As an example, if you a directory you want to get rid of, and if it is named “example/”, then do this so it is reversible:
mv example BACKUP_example

Then build with your configuration (make sure it is a clean build; if content is referenced by something already built it might not betray the missing need).

Thank you for your long reply but I think I got confused by your answer.

I am cross compiling and building the kernel manually (without the nvbuild script).
I set the LOCALVERSION and CROSS_COMPILE variables before executing the make command I mentioned.

I follow all the “regular dev guide” steps:
untar the Linux_for_Tegra , sample rootfs, kernel sources inside the Linux_for_tegra/source/public, etc…
The build is finished fine but the problem is that after executing the make command I mentioned, for some reason i have a new hardware directory on my desktop. I don’t know what is the reason for that and I didn’t understand that from your answer.

I have the “regular” Linux_for_tegra/source/public/hardware directory and don’t know what is the reason for creating additional hardware directory on my desktop. I only know it happens after executing the make command mentioned before. Can I do something to prevent it? maybe something wrong with my paths/current working directory/env variables?

thanks

The sample rootfs does not go there. All of that is the filesystem which gets flashed (after a few additions of NVIDIA content). If you were flashing manually, without the use of JetPack/SDK Manager, then it would start like this for setting up (a one-time thing, but SDK Manager does this for you):

  • Unpack the “driver package” as a regular user. This produces “Linux_for_Tegra/
  • Go to “Linux_for_Tegra/rootfs/
  • Unpack the sample rootfs as root (with sudo).
  • Go back to “Linux_for_Tegra/”. Run “sudo ./apply_binaries.sh”.
  • You could optionally run “sudo tools/l4t_create_default_user.sh”.
  • From you you could flash on command line.
  • Sample rootfs never touches “Linux_for_Tegra/source/”.

The is a large package which can be downloaded for the sources. Within that package is the kernel package (a package within a package). This would be the “Driver Package (BSP) Sources” (you’d pull a package from that package, and then extract the final package). If you downloaded “Sample Root Filesystem Sources”, then you’ve downloaded the wrong one.

Which package did you download? What is the name of the file you’ve extracted from? What L4T release is this from?

Note that L4T is what gets flashed, while JetPack/SDKM is GUI front end software for flashing. If you pick one, then you’ve picked the other (their versions are tied together). On the Jetson you can find the L4T release with “head -n 1 /etc/nv_tegra_release”. Many instructions will differ depending on the L4T release and the hardware.

Note that there are places where documentation might be telling you how to update the rootfs with a new kernel build, but mostly you should ignore that during kernel build itself. I’m not sure if you have the right source package.

References for release versions:

I build everything manually without SDK.
I do as you wrote:

  • Unpack the “driver package” as a regular user. This produces “Linux_for_Tegra/
  • Go to “Linux_for_Tegra/rootfs/
  • Unpack the sample rootfs as root (with sudo).
  • Go back to “Linux_for_Tegra/”. Run “sudo ./apply_binaries.sh”.
  • You could optionally run “sudo tools/l4t_create_default_user.sh”.
  • From you you could flash on command line.
  • Sample rootfs never touches “Linux_for_Tegra/source/
  • Unpacking L4T - jetson_linux_r35.3.1_aarch64.tbz2
  • Unpacking sample rootfs inside Linux_for_Tegra - tegra_linux_sample-root-filesystem_r35.3.1_aarch64.tbz2/
  • I unpack kernel sources inside Linux_for_Tegra/source/public - kernel_source tar from public_sources.tbz2
  • I export both LOCALVERSION , CROSSCOMPILE variables
  • I use make commands to create default .config file from tegra config and to build kernel itself , modules and dtbs (I don’t use the nvbuild script)

** at this point the hardware directory is created on my desktop without any known reason **

  • I execute ./apply_binaries.sh
  • Flash

Everything works fine except for the fact that the hardware directory is create on my desktop without any reason and I wish to understand what cause this

That is unusual. Some questions to help reproduce this:

  • What is the exact L4T release this is from?
  • Was this downloaded, or was this from git? What URL for either?
  • What is the base directory path containing “Linux_for_Tegra/sources/”?
  • Does that content occur after compile, or does it occur before?
  • Did you use CROSSCOMPILE, or was it CROSS_COMPILE (the latter is correct)?
  • What exact cross compile path did you use, and what release is it? Example:
    ${CROSS_COMPILE}gcc --version
  1. L4T r35.3.1 , the package is jetson_linux_r35.3.1_aarch64.tbz2
  2. downloaded from here:
    Jetson Linux 35.3.1 | NVIDIA Developer
  3. Base directory is: /home/bsp/Desktop/Workspace_5_1_1
  4. the new desktop hardware directory occurs exatcly after executing:

make ARCH=arm64 O=$WORKSPACE_PATH/Out -j16 --output-sync=target

not before that.
5. I export both:

export CROSS_COMPILE_AARCH64_PATH=${WORKSPACE_PATH}/Toolchain
export CROSS_COMPILE_AARCH64=${WORKSPACE_PATH}/Toolchain/bin/aarch64-buildroot-linux-gnu-

I downloaded the cross compile from here:

package is: aarch64–glibc–stable-final.tar.gz

FYI, I am testing this, not in the same location. I downloaded “public_sources.tbz2” from R35.3.1. I placed this at:
~/Downloads/deleteme/R35.3.1/
(that’s the name I use for content I intend to delete! 😀)
(Note: The parent directory is empty)

From there:
tar xvfj public_sources.tbz2

After that unpacks:
cd Linux_for_Tegra/source/public/

Now I unpack kernel source:
tar xvfj kernel_src.tbz2

This now allows me to go here:
`cd kernel/kernel-5.10/

I set this to my build source location:
export TOP=$(pwd)
(I used that syntax due to difficulty excaping single backquotes in the forum)

Now I set up some convenience temp locations:

mkdir -p "${HOME}/build/kernel"
mkdir -p "${HOME}/build/modules"

export ARCH=arm64
export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu-
# Note: "${CROSS_COMPILE}gcc --version":
# aarch64-linux-gnu-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0

# The TEGRA_BUILD is just for my convenience. I sometimes script custom steps.
export TEGRA_KERNEL_OUT="${HOME}/build/kernel"
export TEGRA_MODULES_OUT="${HOME}/build/modules"
export TEGRA_BUILD="${HOME}/build"

# Note: Needed install "sudo apt-get install python3-sphinxcontrib.apidoc".
make mrproper

Note: In the following configuration I don’t know what modifications you made. I could add that if you mention what config changes you made. This is the default config though, and normally, if not changing integrated features, one would set CONFIG_LOCALVERSION to “=-tegra”.

Actual build of Image:

# Default config:
make O=$TEGRA_KERNEL_OUT tegra_defconfig
# From here you could edit `CONFIG_LOCALVERSION`.

# Note: Next step required "sudo apt-get install libssl-dev".
# I'm building Image so I don't need "modules_prepare", but I will do it anyway:
make O=$TEGRA_KERNEL_OUT modules_prepare

# Now build Image (previous step unnecessary if building Image):
make O=$TEGRA_KERNEL_OUT -j 12 Image

# Now modules:
make O=$TEGRA_KERNEL_OUT -j 12 modules

# Now device tree:
make O=$TEGRA_KERNEL_OUT -j 12 dtbs

# So far no errors. Installing to temp locations in $TEGRA_BUILD:
make O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=$TEGRA_MODULES_OUT

All steps completed. Recall that I originally unpacked in “~/Downloads/deleteme/R35.3.1”. You mentioned “/home/bsp/Desktop/Workspace_5_1_1”, which might be the same for your case, but I don’t know if this is the “kernel-5.10/” equivalent, or if that is where you unpacked from. What directory is the parent to “public/kernel/kernel-5.10/”?

I ask about that specific directory tree fragment because I have no content added to “sources/”. The “public/”, after checking timestamps, has no content which was not from unpacking; subdirectories “kernel/” and “hardware/” did have timestamp updates. The rest of those subdirectories are part of the build source for the kernel.

Note that I did not unpack the driver package, which is what populates the other parts of “Linux_for_Tegra/”, but so far as I can tell, this is also somewhere within your “/home/bsp/Desktop/Workspace_5_1_1/”.

Whenever JetPack/SDK Manager adds the driver package it puts it in “~/nvidia/nvidia_sdk/JetPack_...version.../Linux_for_Tegra/”; manual unpack is “Linux_for_Tegra/” wherever you want it to be.

If there is an error in a script, and if that error adds an extra “../” into a path (that’s the “_ddot_” macro you see in some build steps), then this would cause output to go somewhere not intended. An example error:

  • After descending lower in the directory tree, the ascending location does not exist.
  • After descending lower in the directory tree, the ascending location exists, but has inaccessible permissions.
  • One of the parent directories is missing, e.g., “public/kernel/” or “public/hardware/” is not present.

Thank you for your answer. I’ll try to iilsutrate the paths on my side:

  1. Main folder:
    /home/bsp/Desktop/Workspace_5_1_1

  2. tree command in that directory:
    tree.log (22.5 MB)

  3. As you can see, I unpack kernel sources inside:
    /home/bsp/Desktop/Workspace_5_1_1/Linux_for_Tegra/source/public
    so public content is:
    hardware kernel nvbuild.sh nvcommon_build.sh

  4. I cd into: /home/bsp/Desktop/Workspace_5_1_1/Linux_for_Tegra/source/public/kernel/kernel-5.10
    and then execute the make command I mentioned. After that specific command an empty hardware directory is created in my desktop.

That’s a lot of files to list. You could limit the tree to directory listing via “tree -d”.

Is it correct that the new directory is this?
/home/bsp/Desktop/hardware/

If so, then that is quite bizarre. The one thing I can think of which might cause this to happen is if there is a configuration of the kernel which uses the _ddot_ macro too many times. This would imply a need to check what your initial configuration is prior to running the build. First though, is the directory which is created “/home/bsp/Desktop/hardware/”? For reference, the “$TOP” would be “/home/bsp/Desktop/Workspace_5_1_1/Linux_for_Tegra/source/public/kernel/kernel-5.10”, which in turn means the “hardware/” directory should be:
/home/bsp/Desktop/Workspace_5_1_1/Linux_for_Tegra/source/public/hardware/

I understand this whole issue is not significant. My question is if you want me to send you some logs,outputs, tree output, etc or you prefer to leave this situation as is and continue with this “bug”.

The problem is exactly as you mentioned:

  • the new created dir is: /home/bsp/Desktop/hardware/

I think if that’s the case, someone else has already noticed it before me. Don’t you think?

The issue, if an unexpected directory is being created, is quite significant. It also makes me quite curious how it can happen, e.g., maybe there is some missing permission that most people don’t run into, which would make it a “corner case”. Corner cases are significant, and on the rare occasion the occur, they should be examined since an opportunity to do so may not come along for some time.

If it is a “_ddot_” macro issue, then this will change depending on configuration, and thus it might be that if nobody has had the same exact configuration, then this might not have been noticed. This might also be combined with some “perfect storm” condition, e.g., something in permissions, that makes the bug possible.

Can you provide the same “tree” log as before, but use the “-d” option? The “-d” option means the tree will show directory structure, and no individual file. Just attach it to this same forum thread.

If that seems to give more clues, then it is possible to create a log of the process which created the empty directory. We’ll see the “tree -d” first to know if that is necessary, but depending on what is seen, we might have you recreate this with steps logged (which isn’t too much different in procedure for command line).

Yes of course. I’ll be able to do it in 2 weeks from now

Hi,
I attach both the tree -d on the Linux_for_Tegra folder and the kernel build log.
tree.log (1.3 MB)
build_kernel.log (553.7 KB)

The created empty hardware folder path: /home/bsp/Desktop/hardware
The Linux_for_tegra path: /home/bsp/Desktop/Workspace_5_1_1/Linux_for_Tegra

I see output is to "/home/bsp/Desktop/Workspace_5_1_1/Out.

What is the location of the “sources/” subdirectory which contains the “kernel/kernel-5.10/” subdirectory tree? Note that I’m just using 5.10 as an example, which reminds me, which specific kernel version is this?

Manually unpacking the kernel sources will produce a “kernel/” and a “hardware/” subdirectory (and so will automatic unpack if it is from the NVIDIA kernel source). The actual kernel would exist in “kernel/kernel-5.10/” (or a different version number). The “$TOP” of the kernel build is really in the “kernel-5.10/”, and this determines if the number of “_ddot_” macros will descend into “~/Desktop/”. I need to know that (A) the out-of-tree content exists, and (B) the parent of the “kernel/kernel-5.10/” location (as mentioned, this might be a different version, e.g., “kernel-4.9/”, just let me know which release is being built and the location which contains both “kernel/” and “hardware/” subdirectories).

I used JP 5.1.1 , hence 5.10 kernel.
I’ll try illustrate the dirs structure during build process (already attached the tree -d):

  1. Created: /home/bsp/Desktop/Workspace_5_1_1 dir.

  2. Created the following sub-dirs:
    /home/bsp/Desktop/Workspace_5_1_1/Toolchain (will hold toolchain)
    /home/bsp/Desktop/Workspace_5_1_1/Out (will hold built products)
    /home/bsp/Desktop/Workspace_5_1_1/Logs (will hold build logs)

  3. Untar: Jetson_Linux_R35.3.1_aarch64.tbz2 inside Workspace_5_1_1 dir.
    As result the following path created: /home/bsp/Desktop/Workspace_5_1_1/Linux_for_Tegra

  4. Manually create public folder: /home/bsp/Desktop/Workspace_5_1_1/Linux_for_Tegra/source/public

  5. untar kernel sources into created public dir. The following dirs created:
    /home/bsp/Desktop/Workspace_5_1_1/Linux_for_Tegra/source/public/hardware
    /home/bsp/Desktop/Workspace_5_1_1/Linux_for_Tegra/source/public/kernel

  6. I build the kernel using the makefile in:
    /home/bsp/Desktop/Workspace_5_1_1/Linux_for_Tegra/source/public/kernel/kernel-5.10/Makefile

  7. As a side effect, additional hardware dir is created: /home/bsp/Desktop/hardware
    ( the “real” one is: /home/bsp/Desktop/Workspace_5_1_1/Linux_for_Tegra/source/public/hardware )

to conclude:
(A) the out-of-tree content exists in (B):
/home/bsp/Desktop/Workspace_5_1_1/Linux_for_Tegra/source/public/hardware
/home/bsp/Desktop/Workspace_5_1_1/Linux_for_Tegra/source/public/kernel

Up until step 6 it appears to be valid. Whether or not step 6 is valid depends on how you configured prior to building. When you go to step 6, within the “kernel-5.10/” subdirectory (which I will refer to as either “TOP” or “$TOP”), do you perform configuration steps prior to building from that Makefile? This is the only part of the procedure which I see as having a possibility of this problem occurring based purely on the procedure.

these the commands I execute:

cd $KERNEL_PATH
make ARCH=arm64 O=$WORKSPACE_PATH/Out tegra_defconfig
make ARCH=arm64 O=$WORKSPACE_PATH/Out -j16 --output-sync=target

while KERNEL_PATH=$WORKSPACE_PATH/Linux_for_Tegra/source/public/kernel/kernel-5.10/

after this code, the hardware dir is created on desktop

This is probably going to produce a large log file, but could you do this to post a log (and mention if this is being run as a regular user versus as root)? Copy and paste will work:

cd $KERN_PATH
echo $CROSS_COMPILE 2>&1 | tee build_log.txt
pwd | tee -a build_log.txt
echo "" | tee -a build_log.txt
echo "tegra_defconfig TARGET" | tee -a build_log.txt
echo "" | tee -a build_log.txt
make ARCH=arm64 O=$WORKSPACE_PATH/Out tegra_defconfig 2>&1 | tee -a build_log.txt
make ARCH=arm64 O=$WORKSPACE_PATH/Out -j16 --output-sync=target 2>&1 | tee -a build_log.txt

Then post build_log.txt.

This will be a really large log, let me know if it cannot be posted. You could maybe run “bzip2 -9” on the .txt file to reduce size, but I think the forums accept .bz2 files.

I executed it as root (bsp user using sudo and not root user).
this it the log:
build_log.txt (545.7 KB)