How to use make menuconfig for TX2 core configuration

step1: Tegra 18x family SOC (Downstream options);

step2: …
step3: …

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.

Start with tegra_defconfig. If you need something special, then after tegra_defconfig use menuconfig.

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?

1 Like

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 tegra_defconfig adjusts. 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 tegra_defconfig. 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 menuconfig.

Don’t forget to correctly set (in “.config”, possibly indirectly via menuconfig) the CONFIG_LOCALVERSION. Usually:

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

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 Image once.

Once config is propagated (either by target Image or target modules_prepare) you could build target modules.

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