[Orin AGX] Issues with BIOS/UEFI and Boot Loop after Flashing Jetson

[sietedosfede]

Hello everyone,

I’ve recently flashed my Jetson Orin AGX with anduril/jetpack-nixos.

Since then, I’ve encountered several issues:

1. No BIOS Logo/Menu or UEFI Shell: Post-flashing, I no longer see the BIOS logo or have access to the UEFI shell. This limits my ability to modify boot order or other BIOS options beyond using the efibootmgr CLI.

2. Ubuntu Boot Loop: The Ubuntu installation installed on the eMMC storage now enters a boot loop.
   I can only access Ubuntu via the /dev/ttyACM0 serial console in Recovery Mode.

Questions:

1. Would it be safe to attempt re-flashing the stock ROM? Is it possible to perform this from the serial console?
2. Can a CH341A programmer with a SOP8 clip resolve this issue? Would it be helpful in this scenario?

Any help or guidance would be greatly appreciated!

I look forward to documenting the process to help others in the future.

Thanks,

[WayneWWW]

I am not sure. Your comment sounds like you didn’t ever correctly flash your board with correct steps before?

If that is true, please put your board into recovery mode and let sdkmanger flash your board from another x86 ubuntu host.

SDK Manager

[sietedosfede]

Thanks! I’ll do that. I just bought this device with Ubuntu already installed.

So, re-starting the process would indeed help.

Many thanks!

[WayneWWW]

And I guess you would need the devkit user guide too.

Jetson Download Center

You will need to put the board into recovery mode before starting flash process.

BTW, I don’t think your board was in recovery mode. This mode won’t get entered easily. It must be something else but misled you.

[sietedosfede]

I connected the device via USB-C to a Linux host, held down the recovery and reset buttons, and executed the watch—n1 lsusb command until something like NVIDIA Corp. APX appeared. Once this was done, I compiled and ran the Nix packages from the specified repo to flash this specific Jetson model. Still, although the model seems to be supported, I lost many functionalities, so I suspect that the initial conditions of my device worked against me.

I also tried to capture the boot log by listening to the serial port, but it disappears and appears with each reboot.
Maybe I should try using screen instead of minicom, which can sometimes handle such dynamic changes more gracefully.

Another thing I was thinking about is trying to debug via UART using something like an FTDI as an adapter.

Curiously, it correctly boots live ISOs from USB drives but doesn’t boot anything else.

[WayneWWW]

I know nothing about the github you shared. Whether it can correctly work or not is not what I can guarantee.

I don’t know whether you are really correctly dumping serial log either because your comment sounds you didn’t do it correctly.

The truth is if you are using NV devkit, then serial console will be directly coming out from “micro usb port” because that port is actually a UART port with FTDI adapter integrated inside of it… You don’t need anything extra there to dump serial console log…
As you are trying to do this, I guess you didn’t correctly dump serial console log from uart either.

NVIDIA Jetson Orin - Serial Console

[WayneWWW]

Just some more explanations.

The type C port can dump log too. But it only starts since UEFI.

The micro usb port will dump the whole boot process log even before UEFI.

Your probably dumped the log from type C before.

[sietedosfede]

Indeed, trying with a different micro-USB cable did the trick!

Dumping the serial correctly allowed me to clarify the matter.

Then, from the UEFI shell, I saw the underlying issue was related to how the EFI was configured.

Now, I have remote access to the NixOS at the NVMe, and everything works correctly.

Thank you for the explanations!