Make ARCH=arm64 O=$TEGRA_KERNEL_OUT tegra_defconfig

make[1]: Entering directory ‘/home/laji/805/Linux_for_Tegra/source/public/kernel/kernel-4.9’
HOSTCC scripts/basic/fixdep
scripts/basic/fixdep.c:449:1: fatal error: opening dependency file scripts/basic/.fixdep.d: Permission denied
}
^
compilation terminated.
scripts/Makefile.host:101: recipe for target ‘scripts/basic/fixdep’ failed
make[2]: *** [scripts/basic/fixdep] Error 1
/home/laji/805/Linux_for_Tegra/source/public/kernel/kernel-4.9/Makefile:463: recipe for target ‘scripts_basic’ failed
make[1]: *** [scripts_basic] Error 2
make[1]: Leaving directory ‘/home/laji/805/Linux_for_Tegra/source/public/kernel/kernel-4.9’
Makefile:171: recipe for target ‘sub-make’ failed
make: *** [sub-make] Error 2

Maybe your folder have permission issue cause the problem. Maybe move it to ~/ folder can help.

fatal error: opening dependency file scripts/basic/.fixdep.d: Permission denied

arch/arm64/Makefile:49: LSE atomics not supported by binutils

Uploading: image.png…

Uploading: image.png…

Did you build it on TX2, This doc is for compile in x86 ubuntu host PC.

One odd possibility for permission issues is that sometimes if this is a partition mount point that the mount command itself needs to add permission to exec even if the directory itself seems accessible. The scripts in particular are prone to this. Is there a separate partition mounted at the “$TEGRA_KERNEL_OUT” location?

Thank you two. I used GitHub to set the user groups wrong. In root mode, it is also normal user permissions, and then it can operate normally. Thank you. Now I want to option.ko It is compiled and loaded into the system separately, but device or resource busy appears when the module is loaded

Uploading: image.png…

Have try below command to load unload the module.

sudo modprobe -r option
sudo modprobe option

Uploading: image.png… Sudo

modprobe - R option can execute the second command to report an error

Uploading: image.png…

Exec format error implies the module is for a different architecture than the system you are installing it to. For example, if you built the module on a PC and then copied it to the Jetson, you would get this error in every case except when a proper cross compile is specified for the Jetson’s architecture.

If you build a module natively on the Jetson, then normally it should “just work” and not have an exec format error. However, if you used some of the cross architecture options even when natively compiled, it might show as a foreign architecture and do the same thing. For example, when natively compiling you would never use “ARCH=arm64”, but if cross compiling, then you would always use this (along with a cross tool chain).

Uploading: image.png…

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/kernel_custom.html# I generated. Ko according to this method. I didn’t think the tool chain was wrong

It looks like you are right…documents for cross compile would not use the “ARCH=”, so that is for cross compile. Combine this with not specifying the toolchain. So this looks like a documentation bug.

In your compile line you will want to change it to also have the toolchain listed. Everything else will remain the same. The toolchain would have a format of something like this:
CROSS_COMPILE=/usr/bin/aarch64-linux-gnu-

This implies that whenever gcc is called, it is prefixed with “/usr/bin/aarch64-linux-gnu-”, and for the example the result would be substituting plain gcc with “/usr/bin/aarch64-linux-gnu-gcc”. Once you have that in the compile command the cross compile should produce the correct architecture.

If the situation were the reverse, and you were using native compile, then you’d build directly on the Jetson and leave out the “ARCH=arm64”.

[quote=“linuxdev, post:17, topic:169860, full:true”]
It looks like you are right…documents for cross compile would not use the “ ARCH= ”, so that is for cross compile. Combine this with not specifying the toolchain. So this looks like a documentation bug.

In your compile line you will want to change it to also have the toolchain listed. Everything else will remain the same. The toolchain would have a format of something like this:
CROSS_COMPILE=/usr/bin/aarch64-linux-gnu-

This implies that whenever gcc is called, it is prefixed with “ /usr/bin/aarch64-linux-gnu- ”, and for the example the result would be substituting plain gcc with “ /usr/bin/aarch64-linux-gnu-gcc ”. Once you have that in the compile command the cross compile should produce the correct architecture.

If the situation were the reverse, and you were using native compile, then you’d build directly on the Jetson and leave out the “ ARCH=arm64 ”.
[/quote]