step1: Tegra 18x family SOC (Downstream options);
Thank you !!
I would suggest just modify the …/kernel/kernel-4.9/arch/arm64/configs/tegra_defconfig for kernel feature configuration.
Isn’t the configuration of tegra_defconfig implemented using make menuconfig?
I don’t know if there is any other mandatory configuration required besides the one selected above.
Suppose the menuconfig is base on tegra_defconfig.
You can select what you want and deselect what you don’t and save it. Or just modify the tegra_defconfig.
tegra_defconfig” is a preset list of features the Jetson works with, and is what a default dev kit ships with. “
menuconfig” is for customizing and is not generally used for mass edit. Normally one just uses “tegra_defconfig``”, and then perhaps add a driver.
menuconfig without a prior base configuration is almost guaranteed to fail.
tegra_defconfig. If you need something special, then after
Excuse me, is there a detailed introduction to the tegra_defconfig file? I am using TX2, but the file has been compiled with several versions at the end, for example:
CONFIG_ARCH_TEGRA_18x_SOC=y TX2 base platform
CONFIG_ARCH_TEGRA_19x_SOC=y Xavier base platform
CONFIG_ARCH_TEGRA_23x_SOC=y Orin base platform
Yes, what I’m trying to say is that since I chose tegra_defconfig, doesn’t that mean the TX2 platform? Why are other platforms also compiled in?
This configure for both of them.
I may not have expressed clearly. What I’m trying to say is, why aren’t those two equal to n, for example:
Suppose some device driver share the same driver but use ifdef to isolate some specific code.
Not a purely correct answer, but you’ll find that various parts of the platforms share a lot of silicon, and rather than changing the chip itself for each release, one might for example double the number of some device, e.g., a UART, instead of creating a single new dual port UART in silicon. The result is that you will find some drivers and configurations going back well over a decade are still in use. When you see a newer config, then often this will simply be additional support for something new, but not conflicting with the older platform.
The way to do this is to just configure for
tegra_defconfig in the kernel build line, followed by using something like
menuconfig to make minor tweaks or changes.
Thank you, I have another question, you said to use menuconfig to adjust, is it done right after tegra_defconfig? But menuconfig is not a modification or supplement to tegra_defconfig, because the configuration interface obtained by using menuconfig after tegra_defconfig does not have the configuration items of tegra_defconfig
Use make ARCH=arm64 O=$TEGRA_KERNEL_OUT tegra_defconfig to generate the .config file;
When using make menuconfig configuration, always let the clear command (make mrproper) be executed;
But after executing the make mrproper command, the options previously configured with tegra_defconfig are invalid
menuconfig only makes specific adjustments. There are thousands of parameters which
menuconfig is just to modify one or two of the current config state, and the config state only starts as valid if you’ve run
menuconfig does not delete or erase anything from
tegra_defconfig unless you specifically and manually do so.
The actual configuration during compile is in the file “
.config” of the source code output location. When you “
make tegra_defconfig”, the “
.config” becomes a copy of “
tegra_defconfig”. When you modify a single entry via
menuconfig, then a single entry in “
.config” changes to match. “
tegra_defconfig” is read-only and not intended for direct modification…only the resulting “
.config” is intended for modification (some experts will modify
tegra_defconfig, but that is rare). So one must run
tegra_defconfig to get a correct “
.config” before using
Don’t forget to correctly set (in “
.config”, possibly indirectly via
If you use
mrproper you are starting over. Its purpose is to erase all prior configurations. Build is no longer valid after this unless you run
tegra_defconfig again (and presumably following this run
Normally I set a kernel intermediate build output location separate from the kernel source itself. My kernel source is owned by root, and no other user is allowed to write to it. I use
mrproper on the source itself. Then all future operations are by a regular user. This guarantees the source tree is always pristine. Only the temporary intermediate output location (owned by the regular user) is ever written to. Once you’ve configured just don’t use “
mproper”, it is a giant eraser.
Thanks, I should have understood.
Each time you use tegra_defconfig in the source code directory, generate .config in the intermediate directory of the kernel build, and then use make menuconfig in the generated .config directory for fine-tuning, so as to ensure the cleanliness of the kernel source code
Then, after the adjustment is complete, execute the following command in the intermediate directory to build the kernel, including all DTBs and modules:
$ make ARCH=arm64 O=$TEGRA_KERNEL_OUT -j8
That compile command is “sort of correct”, but you need to specify a particular make target. There is a lot which you won’t want to build, and building everything is a bad idea.
I always suggest that even if you are only interested in a module that you build
Image. When you do this it will propagate configuration. You could also propagate configuration via “
make modules_prepare”, but it is quite useful as an acid test to build
Once config is propagated (either by target
Image or target
modules_prepare) you could build target
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.