Newly flashed SD card not loading

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
1

I tried following the instructions in https://developer.nvidia.com/embedded/learn/get-started-jetson-orin-nano-devkit#intro to flash an SD card to put into a new Jetson Orin Nano. I first tried flashing (đŸ“„ Jetson Orin Nano Developer Kit JetPack 6.2.1) using Belana Etcher which seemed to flash fine but then I got the following error when I connected it to the Orin Nano and powered it up. It stops at the ‘Reached target OEM Configuration’ line.

OK ] Finished resolvconf-pull-resolved.service.
OK ] Started Bluetooth service.
OK ] Reached target Bluetooth Support.
OK ] Started Network Manager.
Starting Hostname Service

OK ] Started Hostname Service.
15.238690] using random self ethernet address
15.238698] using random host ethernet address
Starting Network Manager Script Dispatcher Service

OK ] Started Network Manager Script Dispatcher Service.
Starting WPA supplicant

OK ] Finished NVIDIA specific script.
Starting nvpmodel service

OK ] Started WPA supplicant.
OK ] Finished Configure USB flashing port for device mode.
OK ] Finished nvpmodel service.
OK ] Reached target Network.
OK ] Started Download data for packages that failed at package install time.
OK ] Started Check to see whether there is a new version of Ubuntu available
OK ] Reached target Timer Units.
Starting Permit User Sessions

OK ] Finished Permit User Sessions.
Starting Set console scheme

OK ] Finished Set console scheme.
[FAILED] Failed to start Configure bootloader service.
See ‘systemctl status nv-l4t-bootloader-config.service’ for details.
[DEPEND] Dependency failed for End-user configuration after initial OEM installation (GUI).
[ OK ] Finished NVIDIA specific early first-boot script.
[ OK ] Started nvfancontrol service.
[FAILED] Failed to start End-user configuration after initial OEM installation.
See ‘systemctl status nv-oem-config.service’ for details.
[ OK ] Reached target OEM Configuration.

I checked the firmware version and it was over 36.x.

The belana etcher version was balenaEtcher-2.1.4.

I even tried dd commands from WSL2, but it is the same problem.

I haven’t tried the sdk manager approach because I can’t find clear instructions on how to do that online.

How can I fix this issue? It is a brand new device and should work perfectly fine.

image
image1247×1663 334 KB

3

*** Please note that this reply is generated by LLM automatically ***

The issue you’re experiencing with your Jetson Orin Nano device is related to the bootloader configuration and OEM configuration services failing to start. This is likely due to the firmware version being over 36x, which is not compatible with the instructions you’re following.

To resolve this issue, you’ll need to update the instructions to match the firmware version of your device. Here are a few possible solutions:

  1. Update the firmware version: If you’re using a firmware version over 36x, you’ll need to update the instructions to match the new firmware version. You can try using the sudo nvbootctrl dump-slots-info command to check the current slot bootloader version in the QSPI. If the output Current version is less than 35.6.0, you can try updating the firmware version to match the instructions.

  2. Use the correct flashing method: You’ve tried using Belana Etcher and dd commands from WSL2, but you haven’t tried the SDK manager approach. You can try using the SDK manager to flash the SD card, as it may provide more detailed instructions and support for your firmware version.

  3. Check the SD card image: Make sure you’re using the correct SD card image for your device and firmware version. You can try downloading the latest SD card image from the JetPack SDK website and flashing it to the SD card using the SDK manager or other methods.

  4. Disable secure boot: If you’re using a firmware version over 36x, you may need to disable secure boot to boot from the SD card. You can try disabling secure boot in the UEFI menu and then booting from the SD card.

Here are some additional tips to help you troubleshoot the issue:

  • Check the UEFI menu: Make sure the UEFI SD Device is on the top of the list in the Boot Manager. If it’s not, refer to Customizing the Default Boot Order in the UEFI Menu for more information about changing the boot order in the UEFI menu.
  • Check the OEM configuration: Make sure you’ve completed the oem-config if needed. You can try running the sudo oem-config command to complete the OEM configuration.
  • Check the bootloader configuration: Make sure the bootloader configuration service is started. You can try running the sudo systemctl status nvl4tbootloaderconfigservice command to check the status of the bootloader configuration service.

In comparison to the provided context, the issue you’re experiencing is similar to the one described in the “Updating Jetson Orin Nano Devkit from JetPack 5 to JetPack 6” section. However, the instructions provided in that section are for updating the device from JetPack 5 to JetPack 6, whereas you’re trying to flash an SD card to put into a new Jetson Orin Nano device.

To fix the issue, you’ll need to update the instructions to match the firmware version of your device and try the correct flashing method. You can also try disabling secure boot and checking the UEFI menu, OEM configuration, and bootloader configuration to troubleshoot the issue.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

5

A few things to unpack here.

You mentioned that the OEM configuration services not starting is probably because my firmware version is over 36x and that is not compatible with the instructions I am following. Here is a link to the instructions I followed from nvidia’s page, along with a screenshot.

(Initial Setup Guide for Jetson Orin Nano Developer Kit | Jetson AI Lab)

image
image1046×742 44.5 KB

Correct me if I am wrong, but there is a tab with the words Firmware < 36.0 and one that says Firmware 36.x. If my firmware, a pic of which I will post below, is over 36, then I need to pick Firmware 36.x which I did as per your website’s instructions.

image
image1663×1247 284 KB

This is why I picked the Jetpack version suggested by your website. If this is not what is meant to be followed, kindly update your instructions.

Regarding using the correct flashing method, since you recommend using sdkmanager, I will try that out (but if balena etcher and dd commands don’t work, please inform us on the instructions that those methods are unreliable or simply don’t work).

I am currently trying sdkmanager, where I connected the Jetson O.N. to a windows pc with a USB C. After battling through a number of errrors, now I am stuck with a whole new one. When trying to flash, the following error pops up.

The connected Jetson device is not ready for flash.

The issue is likely related to a non-optimal USB connection.

To fix this issue, please follow the step-by-step instructions below:

Unplug the USB cable from the host computer.

Unplug the power supply cable from the Jetson device.

Check USB connectivity and consider:

Replacing the USB cable.

Add/Remove a USB hub between the Jetson and the host.

Connect the Jetson device to a different USB port on the host computer.

Plug the USB cable to the host computer.

Plug the power supply cable to the Jetson device.

Manually set the Jetson device to recovery mode (again).

If still not work, please try to click the below button to reset the USB Controller, or reboot your host machine.

Reset USB Controller

Click ‘OK’ and then try to flash again.

I’ve tried unticking ‘Allow the computer to turn off this device to save power’ from the USB properties in device manager and tried using both USB ports in my PC but no luck. Funny thing is that the error message is asking me to change the USB cable, which happens to be the one that I just took out of a brand new nvidia jetson AGX Orin.

I have tried different USB ports but the problem persists. May I know whether this USB error is a common one and if there is a solution to it.

6

I am attaching the log file for your reference from sdkmanager.

sdkm.log (294.2 KB)

SDKM_logs_JetPack_6.2.2.zip (348.5 KB)

7

Hi @chamathkv,

I reviewed your SDK Manager logs in detail. Both flash failures point to the WSL2/USBIPD USB passthrough being unreliable for the Jetson flash protocol — the first attempt returned empty EEPROM data (all null bytes), and the second hit a USB write timeout.

Recommended solution: flash from native Ubuntu instead of WSL2

Please run SDK Manager from a native Ubuntu 20.04 or 22.04 installation (dual-boot or a dedicated machine) with a direct USB-C connection to the Jetson in recovery mode. This bypasses USBIPD entirely.

A successful SDK Manager flash will also resolve your SD card boot issue (“Failed to start Configure bootloader service”), since it updates both the QSPI firmware and rootfs together — eliminating the version mismatch that caused nv_update_engine to fail.

If the flash still fails from native Linux with the same empty EEPROM error, that would indicate a hardware issue on the module — please let us know.

Hope this helps!

10

Hi,

Thanks for reviewing the logs and for your output. I am afraid I don’t have a native Ubuntu device to try this out with. If I do manage to get one, I will give it a go.

What I did try was I went to the Jetpack archive ( JetPack Archive | NVIDIA Developer ) and flashed a slightly older version. That seemed to work and loaded the OS. I am getting an error when trying to do an update (details in the txt file) so I am not sure whether this will pose a problem in the future.

update.txt (16.0 KB)

11

Hi @chamathkv,

Thanks for sharing the full apt upgrade output. To confirm that’s what’s happening on the running system, could you share two quick pieces of information?

  1. Full contents of /etc/nv_boot_control.conf

    cat /etc/nv_boot_control.conf

    The snippet in your log shows TNSPEC ----1-0-jetson-orin-nano-devkit- with the BOARDID/FAB/BOARDSKU/BOARDREV fields empty, and no COMPATIBLE_SPEC line. Seeing the whole file confirms exactly what’s missing.

  2. Kernel boot messages related to the module EEPROM

    sudo dmesg | grep -iE 'eeprom|cvm|board.id|i2c.*tegra'

Once we see those two outputs, we’ll know whether this is something we can work around in software or whether the module needs to be RMA’d.

Thanks.

12

Hi,

I’ve pasted the output below.

m@JetsonON-OG:~$ cat /etc/nv_boot_control.conf
TNSPEC ----1-0-jetson-orin-nano-devkit-
TEGRA_CHIPID 0x23
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
m@JetsonON-OG:~$ sudo dmesg | grep -iE ‘eeprom|cvm|board.id|i2c.*tegra’
[ 10.785956] at24 0-0050: 256 byte 24c02 EEPROM, read-only
[ 10.788725] at24 0-0057: 256 byte 24c02 EEPROM, read-only

13

Hi @chamathkv,

Thanks for those outputs. Before drawing a conclusion on the next step, could you run one more command on the running system and paste the output?

sudo apt install -y i2c-tools
sudo i2cdump -y 0 0x50 b

Thanks.

14

Hi,

I have attached the outputs in this reply.

output.txt (12.2 KB)

15

Hi @chamathkv,

Thanks for trying that. The EEPROM device is detected by Linux, but the direct i2cdump read was blocked because the kernel driver is already using that address.

Please read it through the driver sysfs node instead:

sudo od -Ax -tx1 -v /sys/bus/i2c/devices/0-0050/eeprom

If that file does not exist, please run these commands and paste the output:

ls -l /sys/bus/i2c/devices/0-0050/
ls -l /sys/bus/i2c/drivers/at24/0-0050/
find /sys/bus/i2c/devices -name eeprom -print

Please also avoid running further apt install / apt upgrade commands for now, since they will keep retrying the same failed nvidia-l4t-* post-install scripts until the board identification issue is resolved.

Thanks.

16

Hi,

I’ve tried your commands. Please let me know what you make of these outputs.

output.txt (2.9 KB)

17

What do you see from:
ls -ld /sys/bus/i2c/devices/*
(I ask because find can have some quirks related to crossing filesystems which means some files won’t show up when expected unless the right flags are used to find)

18

Hi @chamathkv,

Thanks for sharing the sysfs EEPROM dump.

The EEPROM device is readable, so this is not simply an I2C access issue. However, the module identification field in the EEPROM does not contain a valid Jetson Orin Nano module part number. For a Jetson Orin Nano module, the EEPROM product part-number field should identify the Orin NX/Nano module family (3767) and the appropriate SKU, as described in the Jetson EEPROM layout documentation: Jetson EEPROM Layout — NVIDIA Jetson Linux Developer Guide 1 documentation. In your dump, that field is effectively missing/corrupt, which matches the earlier symptoms:

  1. /etc/nv_boot_control.conf has an incomplete TNSPEC:

    TNSPEC ----1-0-jetson-orin-nano-devkit-

  2. The COMPATIBLE_SPEC line is missing.

  3. The NVIDIA post-install scripts fail with:

    Error: Unsupported board ID: .

  4. SDK Manager cannot reliably identify the target board during flash.

Recommendation:

Please proceed with an RMA/replacement for the Jetson device, following the NVIDIA Jetson RMA process here: Jetson FAQ | NVIDIA Developer. At this point, the evidence points to malformed/corrupt module EEPROM identification data, not a normal SD card image issue or a package update issue. A native Ubuntu flash host may avoid the separate WSL2/USB timeout, but it will not correct invalid module identification data in the EEPROM.

When contacting NVIDIA Customer Care, please include this forum topic link and the following outputs:

cat /etc/nv_boot_control.conf
sudo od -Ax -tx1 -v /sys/bus/i2c/devices/0-0050/eeprom

Hope this helps!

19

Hi,

These are the permissions for files in that directory.

m@JetsonON-OG:~$ ls -ld /sys/bus/i2c/devices/*
lrwxrwxrwx 1 root root 0 Apr 29 05:33 /sys/bus/i2c/devices/0-0050 → ../../../devices/platform/bus@0/3160000.i2c/i2c-0/0-0050
lrwxrwxrwx 1 root root 0 Apr 29 05:33 /sys/bus/i2c/devices/0-0057 → ../../../devices/platform/bus@0/3160000.i2c/i2c-0/0-0057
lrwxrwxrwx 1 root root 0 Mar 24 13:52 /sys/bus/i2c/devices/1-0025 → ../../../devices/platform/bus@0/c240000.i2c/i2c-1/1-0025
lrwxrwxrwx 1 root root 0 Mar 24 13:52 /sys/bus/i2c/devices/1-0040 → ../../../devices/platform/bus@0/c240000.i2c/i2c-1/1-0040
lrwxrwxrwx 1 root root 0 Mar 24 13:52 /sys/bus/i2c/devices/4-003c → ../../../devices/platform/bpmp/bpmp:i2c/i2c-4/4-003c
lrwxrwxrwx 1 root root 0 Apr 29 05:33 /sys/bus/i2c/devices/i2c-0 → ../../../devices/platform/bus@0/3160000.i2c/i2c-0
lrwxrwxrwx 1 root root 0 Apr 29 05:33 /sys/bus/i2c/devices/i2c-1 → ../../../devices/platform/bus@0/c240000.i2c/i2c-1
lrwxrwxrwx 1 root root 0 Apr 29 05:33 /sys/bus/i2c/devices/i2c-2 → ../../../devices/platform/bus@0/3180000.i2c/i2c-2
lrwxrwxrwx 1 root root 0 Apr 29 05:33 /sys/bus/i2c/devices/i2c-4 → ../../../devices/platform/bpmp/bpmp:i2c/i2c-4
lrwxrwxrwx 1 root root 0 Mar 24 13:52 /sys/bus/i2c/devices/i2c-5 → ../../../devices/platform/bus@0/31b0000.i2c/i2c-5
lrwxrwxrwx 1 root root 0 Mar 24 13:52 /sys/bus/i2c/devices/i2c-7 → ../../../devices/platform/bus@0/c250000.i2c/i2c-7
lrwxrwxrwx 1 root root 0 Jan 1 1970 /sys/bus/i2c/devices/i2c-9 → ../../../devices/platform/13800000.display/i2c-9

20

The reason for the “ls -ld” was twofold: (A), find can have issues in “/sys” from crossing filesystems, and (B), I wanted to see if anything pointed to the eeprom file. This is the file I was wondering about (which is not an actual file but a driver interface):
/sys/bus/i2c/devices/0-0050/eeprom

An earlier od command showed it was there and had content, but other commands tend to say the i2c isn’t returning what is expected. This might be from programming of the chip, which in turn might be an issue of the flash. Be careful when thinking of issues of flash because this can be from the Jetson, but it also can be from anything in the flash procedure (and usually is flash related). I see @wichiu already mentioned the WSL2 passthrough being unreliable, and it definitely is. Even a native Ubuntu host PC would have issues if the cable itself is low quality (about 2 out of 3 “charger” cables are incapable of sustained data; the one which comes with dev kits is quite reliable). Although the flash environment is not verified as the cause it still looks like something in the flash started to write to the EEPROM, but perhaps did not send valid data (or read).

WSL2 is quite problematic for a lot of people. A VM in general tends to be problematic due to USB disconnect/reconnect behavior often not being configured correctly to deal with that. On top of that you have actual cable issues (the USB-C cables tend to not be such a problem, it is the older micro-OTG cables which are the biggest issue, but sometimes USB cables are still a problem with USB-C).