NVIDIA custom carrier board stuck at boot logo

NanoLog4.txt (25.0 KB)
Attaching the serial console log file

We made our own carrier board and built a new Linux kernel with our DTB files but the OS is stuck at boot logo ?

  1. any solutions to check the logs after the boot logo is displayed ?
  2. the console log looks fine and didn’t contain any major error we have compared it with the original dev kit log they are similar but still did we miss anything

The kernel gets hang and cannot boot.

It is possible that there is something wrong but the console cannot print it out.

Please set console to none and also add console=none and keep_bootcon to your kernel commandline. Boot up and use the full log to make sure your change really takes effect.

Below example is for Xavier AGX. To use jetson nano, you shall use p3448-0000.conf.common and remove the “ttyS0”.

+++ p2972-0000.conf.common
@@ -172,7 +172,7 @@ BPFDTB_FILE=tegra194-a01-bpmp-p2888-a01.dtb;
-CMDLINE_ADD="console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4";
+CMDLINE_ADD="fbcon=map:0 net.ifnames=0 rootfstype=ext4 console=none keep_bootcon";
 ROOT_DEV="mmcblk0p12 ------------ internal eMMC.
         sda1 ----------------- external USB devices. (USB memory stick, HDD)

extlinux.conf (830 Bytes)
using this extlinux file is it correct or am i doing something wrong ?

new_log_keepup_bootcon.txt (36.8 KB)
attaching the log after adding “fbcon=map:0 net.ifnames=0 rootfstype=ext4 console=none keep_bootcon”

our finding :

  1. Kernal is loading DTS File Name: "arch/arm64/boot/dts/…/…/…/…/…/…/hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0000-p3449-0000-b00.dts "dts file but when we generated our dts files we got two files 1) tegra210-XXXXXX-pinmux.dtsi 2)tegra210-XXXXX-gpio-default.dtsi with which have build the DTB files and pasted them in L4T package and building the OS again
  2. OS set in device tree is not L4T. what does this line in the log means ?
  3. please help us in naming the DTB file correctly .


I am not sure what kind of “naming” you tried to say here.

It seems you are not familiar the device tree…

From the beginning, the device tree in use are all ending with “dts”. Something like “dtsi” is more like a file that will be included in another dts.

If you really look into your pinmux dtsi files from the spreadsheet, you will notice it only has the info related to pinmux and gpio. A board is not possible to boot up with just this info.
For example,

I don’t think you need to worry about “OS set in device tree is not L4T.”. You can compare your log with devkit. I think devkit has that log too.

I agree that i don’t have enough knowledge about the device tree .
regarding " A board is not possible to boot up with just this info."

→ we are building the DTB files and replacing the gipo , pinmux DTBs from the folder <path_to_L4T>/kernel/dtb with the newly generated DTB files

We have a pinmux generator excel sheet modified according to our custom carrier board schematic . It outputs 2 dtsi files gpio-default.dtsi , pinmux.dtsi .
Can you please provide us a link or some resource where we can learn how to use this dtsi files to add them to current device tree (or build a new device tree) and get our custom carrier board working .

Firstly, understand which device tree is in use on your board.

For example, we won’t flash a jetson nano devkit’s dtb to jetson AGX Xavier. This won’t able to make it boot.

The board config under your Linux_for_Tegra will tell.

For example, if you use “sudo ./flash.sh jetson123 mmcblk0p1” to flash your board. It means there should be a “jetson123.conf” defined under your Linux_for_Tegra folder. The dtb should be defined in this conf file.

from link : https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3271/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/adaptation_and_bringup_nano.html#wwpID0E0QQ0HA

we are rebuilding everything .The documentation asks us to name the file ->" tegra210-porg-pinmux-p3448-0001-.dtsi" and then rebuild the device tree image,
In the next step it asks to copy tegra210-p3448---0000.dtb file that is obtained from the build but after the build in the folder specified there is no file with that name
our SKU = 0000 and carrier is p3449 and ver is b00

  1. we couldn’t understand why documentation is asking to name it 0001 ?
  2. There is no reference in the document to rename the gpio-default.dtsi file ?

I don’t have the source code now.

I would suggest you can just read the dts file itself instead of reading the document. It is already open source and just trace some codes can find out which file to modify.

tegra210-p3448—0000.dtb file that is obtained from the build but after the build in the folder specified there is no file with that name

Then what are the exact things you see under the folder?

instead of this tegra210-p3448—0000.dtb we find tegra210-p3448—0000-b00.dtb
and also just rebuilt everything still getting same error we just checked that our board is using → tegra210-p3448-0000-p3449-0000-b00.dts file

from logs :
[ 0.744400] DTS File Name: arch/arm64/boot/dts/…/…/…/…/…/…/hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0000-p3449-0000-b00.dts
[ 0.758222] DTB Build time: Mar 13 2022 16:05:12

I guess the document missing to add this suffix. Just follow the board config. There is no standard answer for this.

then there might also be a mistake here because there is no explanation for using 0001 where few lines they clearly state that is the SKU of the Jetson Nano device: for original Jetson Nano, 0000 or 0002. so shall we change that to ? and rename it as per board config .

If your jetson nano module has sdcard slot on it, then it is 0000. If it does not have one, then it is a emmc module, it would be 0002.

1 Like

built the image with 0000 still the log is same and the jetson is stuck at logo
can you help me in verifying that the kernel is finding the rootfs that i created . Is there anything in logs that assures that rootfs is fine then i can check for other issues one by one

One jetson doc says “Certain Debug Configurations Can Reveal Bugs” do you have any link for reference to setup these debug configurations .

  1. If you just directly move your module with current setting to the devkit board, will it boot up?

  2. If you change anything, share the new log. Do not just tell me “it stuck at logo”. Honestly, this is a useless info. Lots of reasons can make boot process get stuck in logo…

  1. no the dev is not booting

  2. This is the log after renaming dtsi file according to documentation and rebuilding the device tree .
    new_log.txt (37.0 KB)

Are you saying that the image you just shared here is from the NV developer kit but not your custom board?

  1. is the NV dev kit picture
  2. is the custom carrier board log
  1. If you just directly move your module with current setting to the devkit board, will it boot up?
    → No our customer carrier board boots up gives the log which i have shared above and get hang at boot logo

If you just flash the “dtb” only to your module when it is on the devkit, would it boot up?