Orin Jetpack 5.0.2 L4T 35.1 as-shipped kernel doesn't boot

Hi Nvidia Support, I need help getting an unmodified L4T 35.1 kernel built from Nvidia source to run on a new Orin. I’ve followed the instructions here:
https://docs.nvidia.com/jetson/archives/r35.1/DeveloperGuide/text/SD/Kernel/KernelCustomization.html#to-build-the-kernel

I’ve downloaded L4T 35.1, installed the bootlin gcc 9.3 toolchain, built a stock, “as-shipped” kernel from the L4T 35.1 public_sources.tbz2 archive and this kernel fails to boot. No device tree changes. No changes to tegra_defconfig.

AGX Orin devkit, p3737, purchased off Amazon. Flashed with Jetpack 5.0.2 to set up a base line. No changes. Graphical/desktop disabled as it is unneeded. Serial console to the shell is more than adequate. AGX Orin devkit info:
Serial No 1422122016757
Part No 945-13730-00000-000

The bootlin-gcc-93 kernel image is 33262080 bytes.
The Jetpack 5.0.2 installed kernel image is 33657344 bytes.
That seems to suggest some defconfg change didn’t get pushed into the release source.

I’ve edited /boot/extlinux/extlinux.conf, and tested booting kernel options 0 or 1 using the default Jetpack 5.0.2 installed kernel. Both 0 and 1 boot options work. No issue with extlinux.conf. It appears to work fine. Again, no device tree changes, using the as-shipped device tree.

Serial port /dev/ttyACM0 shows Orin is very unhappy in booting this stock kernel. See below. The console hangs after this output.

Some help would be appreciated.

L4TLauncher: Attempting GRUB Boot
L4TLauncher: Attempting Direct Boot
L4T boot options
0: primary kernel
1: rcarter kernel
Press 0-1 to boot selection within 3.0 seconds.
Press any other key to boot default (Option: 0)
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services and installing virtual address map...
��I/TC: Secondary CPU 1 initializing
I/TC: Secondary CPU 1 switching to normal world boot
I/TC: Secondary CPU 2 initializing
I/TC: Secondary CPU 2 switching to normal world boot
I/TC: Secondary CPU 3 initializing
I/TC: Secondary CPU 3 switching to normal world boot
I/TC: Secondary CPU 4 initializing
I/TC: Secondary CPU 4 switching to normal world boot
I/TC: Secondary CPU 5 initializing
I/TC: Secondary CPU 5 switching to normal world boot
I/TC: Secondary CPU 6 initializing
I/TC: Secondary CPU 6 switching to normal world boot
I/TC: Secondary CPU 7 initializing
I/TC: Secondary CPU 7 switching to normal world boot
I/TC: Secondary CPU 8 initializing
I/TC: Secondary CPU 8 switching to normal world boot
I/TC: Secondary CPU 9 initializing
I/TC: Secondary CPU 9 switching to normal world boot
I/TC: Secondary CPU 10 initializing
I/TC: Secondary CPU 10 switching to normal world boot
I/TC: Secondary CPU 11 initializing
I/TC: Secondary CPU 11 switching to normal world boot
��debugfs initialized
WARNING: clock_disable: clk_power_ungate on gated domain 35 for gpusysclk
WARNING: clock_disable: clk_power_ungate on gated domain 35 for gpc1clk
WARNING: clock_disable: clk_power_ungate on gated domain 35 for gpc0clk

Hi,

  1. So If you fallback to the kernel provided from jetpack, then you can boot up?

  2. What is your method to update the kernel image?

Hi,

1/ extlinux.conf appears to support only two entries, primary and backup. Primary entry supports graphical login (desktop) and serial console. For the backup (second) entry, the bootargs passed to the kernel are trimmed. Any bootargs for the second entry appear to be ignored.

This sounds like a bug. We will check. Thanks.

What is the original issue about booting? Is that also got resolved after you put it in primary kernel?
I am not pretty sure about it after reading your comment. You only said about “graphic is gone/ serial gone”. So do you mean “actually it boots, but serial is gone so you cannot tell whether it boots afterwards”?

Hi,

We tried to reproduce issue but that error didn’t happen.

  1. Add 2nd kernel option in extlinux.conf but no error.

  2. 3rd kernel option also takes effect.

Is the attachment the extlinux you are using?

Okay. I’ve made a mistake here and I’ll own it. Somehow I’ve accidently added a carriage return into extlinux.conf in the backup kernel bootargs. This explains the mangled boot args and loss of the serial console. 100% on me. I really jumped the gun and should have double checked (again) everything I did.

extlinux.conf works as expected. Alternate kernels boot.

@WayneWWW , thank you for your time. Close this out.

I’ll scrape the Nvidia Jetpack 5.0.2 kernel to see if I can account for the size difference when compared to the kernel built from unmodified, as-shipped source.

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