Bios Jetson Orin Nano

Hi, I have a problem with my Jetson Orin Nano 4GB, I just purchased it two weeks ago… was trying to reset factory data and by mistake I just selected the “reset” option inside the BIOS, help me with a solution please. Then I enter “continue” and my screen goes black.

Hi espochtesis,

Are you using the devkit or custom board for Orin Nano?

The “Continue” and “Reset” option should be fine to be used.
Continue means keep booting up the board.
Reset means reset the board and boot up again.

Could you share the serial console log for further check?

I am using a devkit, where can I find the serial console log?

For Orin Nano devkit, please refer to the following instruction to get serial console log.
Jetson Nano & NX Style - Serial Debug Console - JetsonHacks

I have tried the steps in the recommended video but it won’t let me boot from the NVME flash drive, probably the drivers that recognize the NVME flash drive are not working. Help me with a video or instructions on how to format the NVME or SSD, make the proper partitions to reinstall the JetPack system.

We would like to check the serial console log for the boot issue.

To re-install the Jetpack on the devkit, you can get a standalone Ubuntu host PC and use SDK Manager.
I should be the simplest method to get it flashed and boot.

The notepad is all the serial console log of the Jetson Orin Nano, I noticed that the messages vary every time I start the UART communication, please help me by solving the problem, Thank you.
serial_console_jetson.txt (80.7 KB)

Is this Orin Nano one with an SD card only, or does it also have eMMC? I see things look good until it tries to mount a filesystem. It ends looking for eMMC (mmcblk01):

[   16.405207] mount /dev/mmcblk0 /mnt
mount: /mnt: special device /dev/mmcblk0 does not exist.
[   16.411224] Failed to mount /dev/mmcblk0 on the /mnt

It is mounting to “/mnt”, but if there is code in “/boot” of eMMC, then it can’t do that. It really looks like it is incorrectly set up to use external media (apparently there is an NVMe that does work). Note that sometimes boot will chain load, and use eMMC “/boot” content, then switch over to the NVMe. There may also be changes required in any initrd to change boot device. I think this is just a question of incorrect filesystem mounting while working with external media.

My Jetson Orin Nano does not have SD or eMMC. So the only bootable device would be NVME.

Developer kits have an SD card on the module itself (not the carrier board). All other Nanos (including original, TX2, Xavier and Orin) all have eMMC. Do you mean that only the NVMe was prepared? The actual setup for NVMe changes depending on model. If you have a dev kit you might not have an SD card inserted, but the slot definitely exists under the module, and procedure changes depending on model. There are no other options.

Do you have any other solution? the Jetson Orin still won’t start, it stays on a black screen or how can I mount the boot drive correctly?

[    3.605157] Mount initrd as rootfs and enter recovery mode

From the log you shared, it seems booting into recovery kernel

Have you tried to use standalone Ubuntu host PC for SDK Manager to flash the NVMe SSD?

Beware that Jetsons do not have a “traditional” BIOS. Almost every computer you know of has an actual hardware BIOS with its own operating system. It does things like bringing up power rails and clocks in the correct order before finding an entry point for the boot chain. Jetsons have this entirely in software (thus they consume less power and exist with a smaller footprint). For a model with eMMC, this content is in partitions in the eMMC; for an SD card dev kit model, this is in QSPI memory. Every time you flash the Jetson it also flashes that content, and unlike a desktop PC, normal install of an o/s also performs the equivalent of a BIOS flash.

Since the BIOS is not a traditional “in hardware” BIOS, it also means that some of the boot parameters are set at the time of flash, and not set by the BIOS. Eventually it gets to the same UEFI that a traditional BIOS would get to, but setting it up to do so differs. You might end up needing to flash again if the original flash was incorrect.

An added twist on this is that we don’t know if this is really a developer’s kit. You said it doesn’t have eMMC or SD. This cannot be correct. The module itself, which mounts on the carrier board will always have one of these:

  • No SD card on the bottom of the module, but eMMC.
  • An SD card slot on the bottom of the module, and no eMMC.

There are no other possibilities to those two conditions; one of them must be true, and the other must be false. Setting up boot and knowing the correct commands makes knowing which it is critical. Take a very very close look at the module itself. Look at the edge of the module PC board. One of the long edges will show some sort of SD card (or micro SD) slot which is under the PCB, but above the carrier board. If not, then you are guaranteed you must have eMMC, even if you don’t use it. If you have an SD card model, then only the o/s goes on the SD card. For external media, the o/s goes on the external device, except there might be software on the SD card /boot which helps in chain loading to the external device. This latter means you won’t be able to boot the external device without the SD card.

Now if it turns out you have some particular model of module, you will still have some third party manufacturer’s carrier board. Only the dev kit with the SD card slot comes with the dev kit carrier board. All other modules require adding a separate carrier board. Those third party carrier boards also have customizations (most of the time, not always) that require yet different flash commands and/or software (software difference is usually firmware, the device tree). There is no way to provide correct information if we are working with different hardware than we think it is. Most answers would end up wrong in some minor detail. Describing the specific hardware is extremely important.

Ok I understand, surely the Jetson Orin Nano has eMMC, I checked that there is no port to insert an SD card and it also seems that this happens with the new Jetson (here I attach an image showing the resources on board). To come to a solution I will provide all the data I have from my purchase, I hope it will be useful:

I’m thinking this is a third party carrier board rather than a developer’s kit carrier board, but I have not seen enough of them to identify from this picture. If there is a micro-SD slot, then it would be underneath the module on the edge which is closest to the carrier board edge (the edge without components to get in the way of the micro-SD). You’d see the slot lining up exactly with the edge of the module such that looking straight down on it would hide the slot, but looking underneath the module you’d see evidence that there is a micro-SD slot. If that is not present, then you have both a commercial module (meaning it is sold separately and not as a developer’s kit; not to be confused with “industrial” model), and a third party carrier board.

In the case of a third party carrier board with a commercial module (no SD card on the module; no commercial module has an SD card, they all have eMMC and any SD card slot would be on the carrier board itself), the software you need is provided by the third party carrier board manufacturer. It is possible that the carrier board design exactly matches the NVIDIA reference design, in which case this works with NVIDIA’s software. Here are the possibilities:

  • The carrier board exactly matches NVIDIA’s design. The third party manufacturer will state that you can use NVIDIA’s flash software.
  • The third party might offer a patch which is applied to NVIDIA’s flash software, and from then on you can flash with that (normally this patch is in the form of a device tree and perhaps a .conf file).
  • The third party will tell you to use their software (which is basically a patched NVIDIA flash software).

Identifying what hardware you have is the only way to proceed.

Hi, sorry for replying late! Precisely it doesn’t contain a SD slot, I checked it when I tried to use JetPack 6.0 (I attach 2 images for a verification), I checked many videos and indications from NVIDIA official pages and everything shows that you can’t insert a SD in the Jetson Orin. I sincerely want to use SDK manager to reinstall jetpack 6.0 and solve the boot problem and even some libraries that I deleted by mistake. But now I have another problem, following all the recommended steps to use SDK manager, it turns out that my VirtuaBox Ubuntu does not recognize the device, in fact it does not appear in the device manager as an added device, I tried from enabling the VirtualBox USB ports to check if at least the device is recognizable in a windows PC (just to check if it is recognizable) and the VirtualBox entries work correctly to detect other USB devices and are reflected in the virtual machine, but this does not happen with the Jetson, it is as if it does not show available in any way (it should be noted that the instructions were followed to induce forced recovery mode with a bridge). I very much appreciate the clarifications about being a third party manufactured product. I am very new to this and find myself confused with the information. To summarize, these are the actions that I believe resulted in the problem I am currently encountering:

  • In the UEFI environment I selected the ‘Reset’ option and apparently it reset default boot addresses and this is not done correctly (hence the screen goes black and stays in a waiting state).
  • I am now trying to use the SDK manager to reset the JetPack 6.0 that was originally found and get a secure boot. But this is not possible as the Jetson is not recognizable.
  • As additional data it is worth mentioning that the device already included Jetpack 6.0 initially, so I did not flash. I am also using Ubuntu 22.04, in my virtual machine.
    I am ignoring an important detail to proceed correctly, so thank you in advance for your patience and understanding.

You will find that VIrtualBox is not supported. The reason that the Jetson is not being identified is because the USB pass-through is incorrect. There are a lot of VMs out there, and all have different setup and configuration. If you manage to get USB set up correctly, then you’ll probably still lose USB in the middle of flash; Jetsons will disconnect and reconnect USB during the flash, which needs yet more configuration such that the USB for the Jetson always gets passed through (even after a disconnect). You might be able to get it to work, but you’ll probably need support from the VirtualBox people (it isn’t a “Jetson thing” in this case).

In the case of older Jetsons that use a micro-OTG connector, the cable is often bad if purchased being named a “charger cable”, but I have not heard of there being a problem with the USB type-C cables (the type-C tends to always be used for data; the micro-B connector which gets plugged into an OTC port for charging is often used only for charging and the data part will fail). Orin uses USB-C, and so it is unlikely the cable is an issue.

It is also possible that you didn’t get the Jetson into recovery mode. Without that, or without being fully booted with the virtual network device running, you’d never see the Jetson even if VirtualBox is configured correctly. Recovery mode is simple though: The recovery button (or header pins being shorted) is like the shift key on a keyboard, but it modifies either power on or power reset. There is no requirement hold buttons for some time length any more than typing a capital letter “C”; hold the recovery, tap power on or power reset, and you can then immediately let go of the recovery button (or unshort jumpers for models using header pins).

There is about a 99.99% chance with Orin (if you even attempted to put it in recovery mode, which is quite reliable) that VirtualBox configuration is at fault, but you’d have to have a lot of good luck to find someone on the Jetson forums who can debug VirtualBox configuration.

Ubuntu 22.04 is good for JetPack 6 (which flashes L4T R36.x). You could use Ubuntu 20.04 as well; the reason you might do that is you could also use JetPack 5 (L4T R35.x); 20.04 can also use JetPack 6. No VM is recommended though. If you want help with a VM, and you create a new thread with the VM type and ask for help on USB in the title, someone might answer, but it is unlikely you will find anyone who can specifically help with USB configuration.

I won’t recommend it (in fact I will recommend to not go this route), but there are some minimal official instructions for using WSL2 from Windows. There would be a learning curve, and this also need configuration, but I think the WSL2 instructions in the documents might give some minimal instructions for USB setup. I don’t remember which document has this, but I think it is one with the specific L4T release you are using. You can find all L4T releases here:
https://developer.nvidia.com/linux-tegra
(anything L4T R35.x is JetPack 5.x, and anything L4T R36.x is JetPack 6.x; JetPack is a GUI front end to flash software, L4T is Ubuntu plus NVIDIA drivers, and is what actually gets flashed; see “head -n 1 /etc/nv_tegra_release” on any Jetson to find the L4T release)

Your photo does show this is a commercial module. Even though you are not using it, this model does in fact have significant eMMC storage as well. Your carrier board is a modification of the reference carrier board used in developer kits, and so this will use different firmware (the device tree) before boot will be entirely functional. You really must consult the Seeed Studio documentation on what software to use for flash. If Seeed says to patch the official NVIDIA software, then after the patch you can use NVIDIA’s instructions (such patches are required only once). However, Seeed might say to use their software, in which case you’ll only end up with frustration trying to flash this board (the flash will succeed, but either some functionality will be lost, or boot won’t work at all). Comments on VMs apply to any flash software regardless of whether it is used with NVIDIA’s flash software or if it is used with third party flash software.

Incidentally, there is usually a requirement to use a command line flash called an “initrd flash” when using external media. This has an initial ramdisk as a kind of adapter between bootloader and kernel load, otherwise the Jetson might not find your NVMe. There is still optional software which the base/original can add, and the part which is not obvious is that JetPack can have flash unchecked, and then the fully running Jetson with ssh access can have JetPack add that optional content. Keep in mind that during flash the Jetson is in recovery mode, but once flash is complete, the Jetson will reboot (and go to first boot account setup); it does this automatically, and now the Jetson is no longer in recovery mode…this is when optional software gets added via ssh over the account you just added from first boot. That optional software won’t care about the carrier board unless it is altering GPIO assignments.

Hello, first of all, I really appreciate your help and especially the information about flashing processes depending on which model I am using. It is true that the model has eMMC which allowed me to safely boot from a recovery kernel, but due to my lack of experience I didn’t get it before.
This is what fixed the problem, I got it from the following link:

https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/SD/Bootloader/UEFI.html#set-the-uefi-variable-in-the-recovery-kernel-shell

I got to the section “Set the System to Normal Boot from the Recovery Kernel Boot”/“Set the Configurations in the UEFI Menu” and followed the following steps:

*After you are prompted to Press ESCAPE for boot options from the landing page of UEFI menu:

*Navigate to Device Manager and click NVIDIA Configuration → L4T Configuration → OS chain A status.

*Change the value to Normal.

*If the rootfs A/B is enabled, change the OS chain B status to Normal.

*Save the change.

*Navigate to Device Manager and click NVIDIA Configuration → L4T Configuration → L4T Boot Mode.

*Change the boot mode to ExtLinux and save it.

*Reboot the target device.

The UEFI will attempt a normal boot.

After that, everything booted without problems, there are other things I want to solve but I will bring it up in another forum. Thank you very much for the help.

1 Like