Jetson Nano on custom carrier board stuck at nvidia logo


We are using jetson nano L4T 32.3.1 customized BSP emmc flashing on a custom built carrier board.

We are able to work with other boards but one of the boards can not boot to desktop. it stuck at nvidia logo, it will auto reset after long time if we wait,it shows the messge screen attached (JEDEC ID 000) once logo disappears, it auto restarts, after auto-reset logo appears again. attached the picture that comes after nvidia logo disappears

We have checked the voltage etc from Hardware side and looks fine.

Open your extlinux.conf from your driver package, remove the “quiet” keyword from the kernel cmdline and then dump the log from uart serial console.

can you specify the path?


1 Like

DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs}

just remove quiet like this? or entire line?

Just quiet. Reflash and dump the uart log.
Removing this is just for enabling log.


I have attached the log files from two boards, one is working fine and another board is showing above discussed errors for boot. same module

Working_board_console.log (113.0 KB)
no_boot_board_console.log (140.8 KB)

Looks like it directly hits cpu error and it is from display driver.

[   32.650778] Workqueue: events_freezable tegra_dc_vpulse2
[   32.650780] Call trace:
[   32.650786] [<ffffff800808bdb8>] dump_backtrace+0x0/0x198
[   32.650791] [<ffffff800808c37c>] show_stack+0x24/0x30
[   32.650796] [<ffffff800845d820>] dump_stack+0x98/0xc0
[   32.650800] [<ffffff80081c2198>] panic+0x11c/0x298
[   32.650807] [<ffffff80081824b0>] watchdog_unpark_threads+0x0/0x98
[   32.650811] [<ffffff800813a738>] __hrtimer_run_queues+0xd8/0x360
[   32.650815] [<ffffff800813b088>] hrtimer_interrupt+0xa8/0x1e0
[   32.650820] [<ffffff8008bf51b0>] tegra210_timer_isr+0x38/0x48
[   32.650824] [<ffffff8008123260>] __handle_irq_event_percpu+0x68/0x288
[   32.650827] [<ffffff80081234a8>] handle_irq_event_percpu+0x28/0x60
[   32.650831] [<ffffff8008123530>] handle_irq_event+0x50/0x80
[   32.650835] [<ffffff80081272f8>] handle_fasteoi_irq+0xc8/0x1b8
[   32.650838] [<ffffff800812224c>] generic_handle_irq+0x34/0x50
[   32.650841] [<ffffff8008122930>] __handle_domain_irq+0x68/0xc0
[   32.650844] [<ffffff8008080d44>] gic_handle_irq+0x5c/0xb0
[   32.650847] [<ffffff8008082be8>] el1_irq+0xe8/0x18c
[   32.650852] [<ffffff80085a6200>] tegra_dc_vpulse2+0x0/0x90
[   32.650855] [<ffffff80080d5258>] worker_thread+0x50/0x4c8

What is the difference between these two boards? Are they both custom board?

Yes, both of them are custom boards and of same type

Do you mean same module, custom board A and B, working fine on A and failing on B but A and B are same type?

If so, could you check if hotplug case would work fine on B? Boot up the device without any monitor connected, plug it after kernel is up.

Yes,both the boards are same. used same modules on both the boards, working fine in board A and issue with board B. I will try hotplugging and let you know.
this is the board picture, both are identical:

You can also try to boot it more times and see if this is an issue that is not 100% reproducible in each time.

When hot plugged after boot, behavior is same. attached the log file for this boot. it is 100% reproducible each time, no inconsistency in it. it never booted to the desktop
noboot board no hdmi console.log (61.0 KB)

What time do you hotplug the cable? I just saw another kernel panic but this time it is not from display driver.

Will it boot up fine if you just not connect any monitors and even no hotplug?

I missed to highlight, if we wait for some time, System can’t bootup to ubuntu, and will have auto-reboot

If kernel hits panic, then WDT will reboot the system, it is common.

It stuck in below stage and after some time it auto reboots even if no HDMI connected

Can you just share me the full log? It is really not a good habit to share partial log in an image. Not able to search and not able to know what happens previously.

thats my bad, it is the same log…

Then I think you can do some hardware cross comparison here.

For example, prepare few more modules, flash with same software, plug into this board and see if all of them will hit this issue.