hi.
When I was compiling kernel-4.9, I imported the official configuration (make tegra_defconfig), but there was an error. I clearly did not modify it, and even deleted the source code and downloaded it again.
arch/arm64/boot/dts/Makefile:132: target ‘arch/arm64/boot/dts/ddot’ given more than once in the same rule
arch/arm64/boot/dts/Makefile:132: target ‘arch/arm64/boot/dts/ddot’ given more than once in the same rule
make[1]: *** No rule to make target ‘arch/arm64/boot/dts/…//hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0000-p3449-0000-a00.dts’, needed by ‘arch/arm64/boot/dts/ddot//hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0000-p3449-0000-a00.dtb’. Stop.
make[1]: *** Waiting for unfinished jobs…
DTC arch/arm64/boot/dts/ddot
cc1: fatal error: arch/arm64/boot/dts/…: No such file or directory
compilation terminated.
make[1]: *** [arch/arm64/boot/dts/Makefile:133: arch/arm64/boot/dts/ddot] Error 1
make: *** [arch/arm64/Makefile:154: dtbs] Error 2
make: *** Waiting for unfinished jobs…
Is it possible that the official BSP source package has a problem, because I win10 decompression actually have file replacement problem, obviously this is not in line with the normal structure, there may be device tree file missing is due to this reason
Basically, there is a redefinition, no device tree found. I don’t know how to solve, because my friends they all compile successfully at once
You might find any of these of use (some might use a 5.x kernel release, always use the one for your L4T release; L4T is the release of Ubuntu plus NVIDIA drivers, and can be found with “head -n 1 /etc/nv_tegra_release”):
It doesn’t hurt to save a copy of “/proc/config.gz”. Note that if your Nano is not customized, then this should be a copy of the tegra_defconfig target, but not necessarily. tegra_defconfig is your kernel telling you how it is currently configured, with the exce
│ ├── platform
│ └── socption that it fails to show the CONFIG_LOCALVERSION (which is what produces the suffix of the “uname -r”).
This might or might not matter, but NVIDIA ships more than the kernel itself. I see notes about the “_ddot_” in the build. That “_ddot_” is the same as this in a file name directory path: ..
Note that “.” is the current directory, and that “..” (what they call _ddot_) is the parent directory of the current directory. The reason this becomes important is because configurations which NVIDIA makes sometimes points to out-of-tree software. When you unpack a normal kernel source not from NVIDIA, then the source generally starts right at the unpack subdirectory. When you get the source from NVIDIA, it starts with this directory tree (which happens to contain the same source from the regular kernel releases, but also contains that extra from NVIDIA):
It actually has other subdirectory levels, but the “kernel/kernel-4.9/” is the “TOP” of the kernel source. Some configurations use _ddot_ to reach back into “hardware/” and/or “u-boot/” (it depends on what was configured). This is one of the biggest reasons why you have to download from NVIDIA, and since configurations change, to make sure you download from the release on your Jetson (which is found on the L4T release URL).
tar -xvf Jetson-210_Linux_R32.6.1_aarch64.tbz2
tar -xvf public_sources.tbz2
sudo tar -xvf Tegra_Linux_Sample-Root-Filesystem_R32.7.3_aarch64.tbz2 -C ~/Desktop/bsp/Linux_for_Tegra/rootfs
Create soft link
Because the kernel-4.9 directory is too deep
ln -s /home/zzy/Desktop/bsp/Linux_for_Tegra/source/public/kernel/kernel-4.9/
Enter the kernel through the soft link
So I would like to ask the corresponding jetson linux 32.7.3 kernel-4.9 official compilation manual where to find, generally NVIDIA release these, there will be an official compilation instructions, but I did not find
He will teach you step by step how to compile the corresponding kernel-4.9 until the Image is generated
If you go to the top of your kernel source (the “kernel-4.9/”), can you:
cd arch/arm64/boot/dts/
If you don’t have that, then there is a problem with the source. If you do have this, then the error might be related to where you’re compiling at somehow getting confused (e.g., via a symbolic link; I realize that is unlikely, but it is a starting point if that’s the issue).
Some additional notes…
I’d use “make mrproper” before starting instead of “distclean”. I’d also use a temporary output location with the “O=/some/where”, and keep the source owned by root and readable by all, but no write permission. The “O=/some/where”, if that is owned by a regular user, guarantees keeping the source itself pristine and not mixing in configurations.
I don’t know if your “CROSS_COMPILE ?= aarch64-linux-gnu-” is a compatible release, but you might check that if it isn’t from the official cross compile instructions.