Booting Jetson AGX Orin devkit with Jetpack 6.1

[sapiippo]

Describe the bug
After updating to Jetpack 6.1 (on master branch), I'm unable to get the Jetson AGX Orin devkit to boot with the tegraflash image.

Flashing goes trough without errors, but after device goes into boot loop with last output as

Jetson System firmware version v36.4.0 date 2024-10-02T18:07:54+00:00
ESC   to enter Setup.
F11   to enter Boot Manager Menu.
Enter to continue boot.
......����
Shutdown state requested 1
Rebooting system ...

Additional context

The default Ubuntu image from NVIDIA's SDK Manager boots correctly.

[dwalkes]

Have you attempted to reproduce on tegra-demo-distro with demo-image-base or similar? If not I'd start there and see if you can reproduce. If you can't you can compare this setup to your layer to help determine any relevant differences.

[ichergui]

@sapiippo Are you sure about the build and flashing ?
As @dwalkes mentioned. It should work without issue when using tegra-demo-distro. I'm not having any issue with AGX Orin devkit

[sapiippo]

I have not tried with tegra-demo-distro, will do that next.
We have been using our own distro with just meta-tegra layer and that has been working fine until Jetpack6.

[sapiippo]

I got same result with meta-tegra-distro and demo-image-base.
flashed with initrd-flash, device ends up in boot loop.

[ichergui]

Could you please explain why you are using initrd-flash ?
initrd-flash is recommended to be used when having external device e.g. NVMe
Jetson AGX Orin have eMMC. So, please use doflash.sh script

[sapiippo]

solely based on #1714 (comment), but using doflash.sh script makes no difference.

[ichergui]

Unrelated subject. The comment you shared is about Orin NX.

[dwalkes]

Can you confirm you don't have any NVMe installed on the devkit and it's as delivered from NVIDIA from a hardware perspective?
I don't have one to test with myself but given @ichergui says it's working for him I'm not sure what it could be.
Enabling UEFI logs to see why it's crashing and shutting down is probably the next step. EDK2_BUILD_MODE is useful for this , you can do something like EDK2_BUILD_MODE:pn-edk2-firmware-tegra = "DEBUG" in your local.conf.

I've also got a patch at Trellis-Logic@cf93c9f which I've been meaning to upstream and which is useful for fine tuning print error levels if you want to give that a try.

[madisongh]

Another thing to check is which AGX Orin dev kit you have. Unlike stock L4T, which has pre-built binaries that cover every variation, and chooses the right binaries to use depending on which one it's talking to at flashing time, you have to know at build time exactly which SKU you're building for.

We have three different machine configurations for non-industrial AGX Orin modules in the AGX Orin dev kit carrier:

• The jetson-agx-orin-devkit machine configuration is for the original 32GiB AGX Orin dev kit, which came bundled with a P3701-0000 module.
• The p3737-0000-p3701-0004 machine configuration is for a 32GiB AGX Orin module (P3701-0004) installed in the dev kit carrier.
• The p3737-0000-p3701-0005 machine configuration is for the newer 64GiB AGX Orin dev kit.

[sapiippo]

Parsing module EEPROM:
--- Parsing board ID (3701) succeeded.
--- Parsing board version (500) succeeded.
--- Parsing board SKU (0000) succeeded.
--- Parsing board REV (J.0) succeeded.
jetson-agx-orin-devkit found.

This is from the flashing logs of NVIDIA's L4T image.

jetson-agx-orin-devkit machine config is still working for this board from scarthgap-l4t-r35.x branch.
The board is a stock item from NVIDIA. I'm not sure about NVMe, does that make a difference?

Unfortunatly, I won't have access to the device for a while, so cannot get logs from UEFI. Will do that at next opportunity.

[sapiippo]

So, it turned out someone had installed NVMe disk to the Orin board and that was causing the issue. Same thing happens also with Jetpack 5 based images.

Changing the boot order doesn't help when NVMe disk is attached.

Attached is log from demo-image with UEFI logging enabled.
demo_with_nvme_not_booting.log

[madisongh]

How are you changing the boot order? Through the UEFI menus? That should work, assuming the ESP on the eMMC is valid, and that you save the boot order change before exiting UEFI.

Oh, but the script in tegra-minimal-initrd, by default, just looks for a partition named APP to boot from, so if you have an APP partition on the NVMe, it could mount that one instead of the eMMC one. The logic in there could probably be improved. So UEFI could be loading the kernel off the eMMC, but the initrd would still picking up the wrong rootfs.

You could customize the script to avoid this, or set KERNEL_ARGS:append = " root=/dev/mmcblk0p1" to override the default in the initrd scripts, or remove the APP partition from your NVMe if you don't need it. There's also an --erase-nvme option on initrd-flash that can be used to wipe the entire NVMe drive during flashing.