When I followed guildline of 35.1 “kernel customization”, (see below link) Kernel Customization — Jetson Linux<br/>Developer Guide 34.1 documentation
I downloaded the BSP and extract them based on guildline, but when I start build kernel ,I found it takes much more longer than 4.6.2,
I tried command “./nvbuild.sh -o $PWD/kernel_out” and " make ARCH=arm64 O=$TEGRA_KERNEL_OUT -j8", either of them takes almost two hours to finish building,
is there anyway to optimize the procedu
By the way, what’s the chip series refer to t19x,t23x? can I remove all t23x fold and files if I use Xavier NX only?
How many CPU cores does your computer have? The “
-j 8” could be increased to the number of cores available, e.g., if you have 12 cores, then it could be “
-j 12”. Also, monitor RAM usage during a build, and if it shows RAM running out, then you probably shouldn’t use that many cores (you can use something like
htop to monitor).
Btw, some later SoC series contain subsets of the prior SoC’s hardware. For example, even though a GPU is upgraded, you might find the serial UARTs to be the same model and layout on the newer SoC. In those cases it is correct to have some older SoC files. However, you did not say which files you are speaking of, e.g., device tree, kernel source, so on. It isn’t really possible to say what you need, but on the host side during a compile it is best to just leave them there (the configuration determines what to use during build, and if the configuration uses those files, then it is part of what is needed).
thanks for your reply,
I modified device tree based on our customized carrier board,
I just find there maybe something wrong on my PC, there is only 1 core operating :( , I will check it first.
and is there any document introduce the packages of 35.1 BSP source ? If there is something like “Package Manifest” in the develoepr guideline will be more clear
The documents and downloads of most interest would be from the particular L4T release download page. A list of L4T versions is here:
(then see “
head -n 1 /etc/nv_tegra_release” for your Jetson’s L4T version)
One thing you might consider is that if you have an existing binary device tree, then you can convert it to source without going to the kernel source. This might be useful for testing variations, and when you get what you want, only then editing the device tree files of the kernel source.
If your host PC or Jetson does not already have the program “
dtc”, then you can install via “
sudo apt-get install device-tree-compiler”. This probably works with any device tree you are interested in, but also gets created the first time you build the
dtbs target in kernel source (and that version is guaranteed to work with that particular kernel and device tree release).
To convert an existing binary tree into source:
dtc -I dtb -O dts -o human_readable.dts some_tree.dtb
To convert a dts back to binary:
dtc -I dts -O dtb -o edited_binary.dtb source_tree.dts
To extract a running system’s idea of the final device tree, in source format:
dtc -I fs -O dts -o extracted.dts /proc/device-tree
This is much faster than building from kernel source, especially if the kernel source build is also building
dtc (but it should need to build
dtc only once unless you made the
Note that I am uncertain if a device tree can be built with multiple threads/cores, it might run on only one CPU. The job server (the “
-j 8” or similar option) only works with code which can be built separately, e.g., a lot of “
.o” object files can be built at the same time, but only one CPU core can link them into a single kernel file once the “
.o” files are created. Just depends on the nature of the code being built.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.