Kernel-4.9 failed to compile

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

kernel3

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

Thanks

嗨 我看到你有兩張截圖 一張是Windows 一張是Ubuntu的
你是解壓縮檔案在Windows操作 實際編譯在Ubuntu操作?
如果你沒有實體Linux環境的話 單純編譯不像燒板子 在虛擬機上應該也是可以的
我不知道Windows的壓縮工具對tar和bzip這些格式的支援度如何 如果出錯也是有可能的

另外你有使用正確的toolchain版本嗎 我們建議的是Linaro的GCC 7.3.1
我剛才測試過是可以正常編譯 不會有error的

hi
我现在jetson linux版本是32.7.3 也就是最新的支持nano版本的
对的我是Ubuntu这边编译的,我马上试试老版本的编译试试,我这边win10解压,发现官方这种压缩方式,怎么解压后还会覆盖里面文件,所以我才疑惑的

对了我们jetson nano有没有官方学习群,不然一个人走太难受了,没有jetson nano的有其他类似板子的群也可以
Thanks

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”):

Some things to always write down before starting:

  • The current result of “uname -r”. Note the suffix will usually be used for CONFIG_LOCALVERSION, and this is most commonly “-tegra”.
  • The L4T release in “head -n 1 /etc/nv_tegra_release”. I see yours is currently R32.7.3, which has downloads found here:
    https://developer.nvidia.com/embedded/linux-tegra-r3273
  • 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):

.
├── hardware
│   └── nvidia
├── kernel
│   ├── kernel-4.9
└── u-boot

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).

I downloaded this related package

And then my steps are these

Decompress first

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

Compile again at this time

vim Makefile

Modify the cross-compilation toolchain
#ARCH ?= $(SUBARCH)
ARCH ?= arm64
#CROSS_COMPILE ?= $(CONFIG_CROSS_COMPILE:“%”=%)
CROSS_COMPILE ?= aarch64-linux-gnu-

sudo -i

make distclean

make tegra_defconfig

time make -j16

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

Take a look at my new reply, there should be an official compilation document, I did not find, too difficult

There is no fatal mistake in these steps, which will cause me to not find the file

嗨 所以你照著這份guide做可以成功編譯嗎

https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3273/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/kernel_custom.html#wwpID0E0XD0HA

还是编译不成功,一直都是这个错误,我make -j16 make -j12 make -j4都不行,最后只能make,但是浪费几个小时还是编不过最新的支持nano版这个jetson linux

所以我想问问你们正式的选择哪一个版本操作的,我还是那种追新思维偏重,想要你推荐一个jetson linux的版本给我

现在我是32.7.3,但是对着那个guide我编不过去,卡在这边两天了,有点无助

你可以看看我上面的步骤,那是我此刻的步骤,有没有什么忌讳,比如该不该软链接,到底给多少并行进程-j
比较合适

我也导入了官方的配置

还有一点就是你有类似jetson nano小型的交流群吗,或者你看得多的那种nvidia群,或者有没有大佬私人群你引荐一下,非常感谢

所以你的source code裡面沒有arch/arm/boot/dts這個資料夾?
我不確定soft link會不會對編譯有影響 你可以拿掉之後重新試試看嗎
如果編不過的話不管你開幾個thread結果都不會變的

我前面幾篇應該已經回過你了… 至少就我知道的而言是沒有
就算有也不會是我們官方支援的

有啊,所以我才疑惑,不是我win下面解压,而是我当时就是下载好几次源码了,每次都编译到这一步就报这个错误,我就想看看他倒是什么样的缺失,我通过win解压一看这个覆盖,那个覆盖,我才想说官方给的这个压缩方式莫名其妙,解压后还覆盖可能就是这个原因导致我文件缺失的。但是这个win只是我测试的
我所有操作都是Ubuntu22下面操作的

所以我才想说你们推荐用哪一个linux,感觉这个32.7.3不是合适的选择。我自己不知道选择哪个合适,才请教问一下哪个合适,或者你现在用的那一个,因为这样我要是再出这个错误,我就可以直接请教你,你可以说我哪一步有问题类似的

哈哈没官方群还是比较可惜的,那就随缘等待志同道合的人吧

你可以試試這篇的解法有沒有用嗎
有人說可能是新版make的問題 我在18.04上用的是4.1版

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.

非常感谢,的确是Kbuild.include的问题需要将

the-space :=
the-space +=

改成

E =
the-space = $E $E

  1. 问题背景: 在编译内核时,通常会使用Makefile和Kconfig文件进行配置和编译。在Makefile中,使用空格来分隔命令和参数。而在Jetson Nano的编译环境中,由于一些特殊情况,原始的空格处理方式可能会导致问题。
  2. 原始的处理方式: scripts/Kbuild.include文件中的the-space变量用于插入空格。原始的处理方式是通过the-space :=the-space +=来定义空格。这样在Makefile中可以使用$(the-space)来插入空格。
  3. 问题分析: 在Jetson Nano的编译环境中,由于某些限制,如命令行长度的限制,使用空格插入可能会导致编译问题。这些问题可能包括命令行过长、链接错误等。因此,需要采取一种替代方案来处理空格,以避免这些问题。
  4. 解决方案: 修改scripts/Kbuild.include文件,将the-space :=the-space +=改为E =the-space = $E $E。这样,通过将the-space变量替换为空格,即$E $E,可以减小命令行长度,避免编译问题的发生。这种替换的做法是一种常见的技巧,可以应对特定编译环境下的问题。但需要注意的是,这种修改可能仅适用于特定的环境和工具链。在进行修改之前,建议先了解特定环境的要求,并确保对系统的影响进行评估和测试。

但是编译时间也太长了吧,别人都是一小时,我一晚上哈哈哈

我不会@,只能通过这种方式让你看一下我了,哈哈
Jetson nano bo1 pin9 and pin10 forced recovery also cannot be swiped - Jetson & Embedded Systems / Jetson Nano - NVIDIA Developer Forums

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