u-boot customization in NVIDIA Jetson Linux Driver Package Software Features Release 32.3 | December...

Does not work.


make p2771-0000-500_defconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf

*** Can’t find default configuration “arch/x86/configs/p2771-0000-500_defconfig”!

scripts/kconfig/Makefile:113: recipe for target ‘p2771-0000-500_defconfig’ failed
make[1]: *** [p2771-0000-500_defconfig] Error 1
Makefile:565: recipe for target ‘p2771-0000-500_defconfig’ failed
make: *** [p2771-0000-500_defconfig] Error 2

It’s trying to use a desktop PC architecture. Did you specify “ARCH=arm”? Note that the bootloader may be using 32-bit even if the o/s itself is 64-bit. You would also need to name your tool chain if doing a cross compile (unlike 64-bit, the 32-bit mode tool chain would be an arm “eabi” tool series). I have not built a boot loader in a long time, but that would be a minimum during a cross compile.

Your documentation did not say anything about ARCH=arm your documentation is giving the wrong command line to build the kernel and u-boot because p2771-0000-500_defconfig does not exist in the kernel source code dirs

result is still not working
make p2771-0000-500_defconfig ARCH=arm

*** Can’t find default configuration “arch/arm/configs/p2771-0000-500_defconfig”!

scripts/kconfig/Makefile:113: recipe for target ‘p2771-0000-500_defconfig’ failed
make[1]: *** [p2771-0000-500_defconfig] Error 1
Makefile:565: recipe for target ‘p2771-0000-500_defconfig’ failed
make: *** [p2771-0000-500_defconfig] Error 2

Where is your arm eabi cross tool chain at? When you specify “arm”, then you also must specify the tool chain which works with this. I am using Fedora, and so I have different tools than you will, but this works for me:

make <b>ARCH=arm CROSS_COMPILE=/usr/local/arm-linux-gnueabihf/gcc-linaro-5.3-2016.02/bin/arm-linux-gnueabihf-</b> p2771-0000-500_defconfig

Note that on my system I have this directory:


Within this directory is a complete set of armhf EABI tools. All tools within this begin with the name:


If I prefix this to “gcc”, which is what the compile does as it runs when those environment variables are present, this what would occur (which is conveniently the full path to the gcc compiler dedicated to running on a PC with output of arm gnueabi output):


Depending on what was installed for your host on your PC you might have this content (although it would be in a different location…I have maybe a dozen cross tool chains which are not part of Fedora’s distribution).

Cross compiling is different than native compile since your build will normally assume you are building for your own system. As soon as the target is a different computer you must also specify both the architecture and where to find the tools capable of output of that architecture.

NOTE: If you were to run this compile directly on the TX2, then you would perhaps still need to do this. The reason is that gnueabi is a 32-bit subset of the TX2’s architecture. The normal tool support on a TX2 is 64-bit, arm64. However, far more cross tools exist on a PC than exist on arm64.

I agree, but your document does not say any of those things. I am really disappointed that your documentation is not cookie cutter for u-boot custominization.

It is missing a bunch of things.



make ARCH=arm
scripts/kconfig/conf --silentoldconfig Kconfig

*** Configuration file “.config” not found!

*** Please run some configurator (e.g. “make oldconfig” or
*** “make menuconfig” or “make xconfig”).

scripts/kconfig/Makefile:37: recipe for target ‘silentoldconfig’ failed
make[2]: *** [silentoldconfig] Error 1
Makefile:565: recipe for target ‘silentoldconfig’ failed
make[1]: *** [silentoldconfig] Error 2

You are missing the .config in your kernel download, or you are missing the recipe to build the u-boot and kernel from scratch on the linux support box.

I am confused why you don’t have people rebuild the kernel and u-boot on the jetson tx2?


Please refer to https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fuboot_guide.html to build u-boot.

Waynewww You just pointed me back to the the same information that I am trying to point out does not work, Is there another place with the correct information.

Answer the previous questions, they are all based on some really poorly written r32.3 documentation!
Your ./source_sync.sh -k tegra-l4t-r32.3.1 does not provide a .config file and your documentation does not talk about creating the .config

Customers need to be spoon fed the secrets/scripts to build your system because standard kernel building does not seem to work.


Much of this is about the general development methods for cross compiling, versus native compiling (and to some extent conventions of Linux kernel builds). The particular config items and such are generally just a “Linux thing”, so it isn’t really within the scope of the docs about the Jetson unless the doc is a tutorial. On the other hand, I’d agree that sometimes docs fail to anticipate the scope of experiences of users needing the document.

What follows is in regard to the most recent error message, “Configuration file “.config” not found!”.

The “.config” is expected to be generated by the person doing the build (and I’m not sure if perhaps this is from kernel build or U-Boot build…verify you are in the U-Boot directory and not the kernel directory). The basic “make something_defconfig” is the usual method of creating that initial “.config”, where usually the full name reflects the particular piece of hardware. Note carefully that this previously mentioned command line is what would generate the “.config” (written on multiple lines with “” to clarify):

make \
 ARCH=arm \
 CROSS_COMPILE=/usr/local/arm-linux-gnueabihf/gcc-linaro-5.3-2016.02/bin/arm-linux-gnueabihf- \

Once that is done, then you will have a “.config”, and this can be edited (such as with “make menuconfig”). Or you could compile just with that configuration. Adjusted to use the CROSS_COMPILE from your previous command notes:

make \
 ARCH=arm \
 CROSS_COMPILE=<b><u><i>/home/tbuckley/l4t-gcc/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-</i></u></b> \

Your command was lacking the “p2771-0000-500_defconfig”. This is why the “.config” was not there.

Hi Terry,

May I know which link did you see?

I just checked the steps.

export CROSS_COMPILE=<cross_prefix>
make distclean
make <board_and_rev>_defconfig

and it works fine on my side. I think the issue here is the path of p2771-0000-500_defconfig is not in ““arch/arm/configs/p2771-0000-500_defconfig”” but config is actually in u-boot/configs/p2771-0000-500_defconfig.

waynewww it appears only .git in my u-boot directory so your source_sync.sh appears to be failing.

I ran ./source_sync.sh -k tegra-l4t-r32.3.1

Really needed to run ./source_sync.sh -t tegra-l4t-r32.3.1

I am in the u-boot directory and it is compiling but errored out on dtc

your documentation needs to clarify the TAG information, and define to do this build in the u-boot dir


wayneWWW your pointer at u-boot/configs/p2771-0000-500_defconfig caused me to notice source was missing

re-running source_sync.sh filled in the u-boot source.

u-boot is building correctly now.


Before Flashing
Before flashing, you must copy the updated U-Boot binary to the L4T tree.
To copy the updated U-Boot for flashing to the reference platform
•Run this command on your Linux host system:
$ cp <uboot_src_dir>/u-boot{,.bin,.dtb,-dtb.bin}
•<uboot_src_dir> is <your_L4T_root>/Linux_for_Tegra/sources/u-boot_source.
•<your_L4T_root> is the location of the L4T release package.
• is the SoC name or platform.
•<board_and_rev> is described in the section Placeholders in Commands.

I am debugging the document you sent in the above URL.

is not defined in this u-boot customization,
and <board_and_rev> is incorrect

I found u-boot.bin in JetPack_4.3_Linux_P3310/Linux_for_Tegra/bootloader/t186ref/p2771-0000/500

No clue from your document where the *.dtb, *-dtb.bin go.

How do I get this pushed back into your documentation people, hoping to help someone else who will try to use this document


For an SD card on Jetson Nano:
sudo ./flash.sh <platform> mmcblk0p1 For eMMC memory on Jetson TX2: sudo ./flash.sh mmcblk0p1

while looking for a definition for I found this where both the SD and eMMC have the same command lines this is wrong.

Sorry I missed the Nano/Tx2 so this should work, is there a way to write to SD card on the TX2?


The document points out " is the SoC name or platform."
-> and it is t186ref
“<board_and_rev> is described in the section Placeholders in Commands.”
-> and the document tells you:
• For Jetson Nano: p3450-porg
• For Jetson TX2 series devices: p2771-0000-500

No clue from your document where the *.dtb, *-dtb.bin go.
Actually, our uboot does not need dtb or dtb.bin anymore. This part was for some other users who may customize uboot.

flash with mmcblk1p1 when you are on TX2.

so after I rebuilt u-boot I ran flash.sh

got this.

[ 9.7376 ] Writing partition
[ 9.7395 ] tegradevflash_v2 --write DTB /home/tbuckley/nvidia/nvidia_sdk/JetPack_4.3_Linux_P3310/Linux_for_Tegra/bootloader/tegra186-quill-p3310-1000-c03-00-base.dtb
[ 9.7412 ] Bootloader version 01.00.0000
[ 9.7460 ] Writing partition DTB with /home/tbuckley/nvidia/nvidia_sdk/JetPack_4.3_Linux_P3310/Linux_for_Tegra/bootloader/tegra186-quill-p3310-1000-c03-00-base.dtb
[ 9.7479 ] 000000000d0d000d: o open partition %s.
[ 9.7608 ]
[ 9.7608 ]

Looks like u-boot rebuild overwrote dtb files in bootloader that do not flash.

Help, dead in the water with rebuilding u-boot now.


looks like is t186ref for some commands

in flash.sh it is jetson-tx2

Where in the document is t186ref defined?


Hi Terry,

What is the exact change you are doing here?
Do you modify anything in uboot?

This is the initial test to see if I can rebuild your u-boot no changes and get it to load and run. I want to change the initial splash screen.

Appears your documentation is wrong and your source code does not even reproduce your release.