Failed to load MB2

We have recently bought 10 jetson orin nano modules and so far I’ve flashed 4 of them. 2 of them works without issues and the remaining 2 I get the same error on boot:
[0001.841] I> Loading MB2

[0001.843] I> Slot: 1

[0001.845] I> Binary[6] block-71424 (partition size: 0x80000)

[0001.851] I> Binary name: MB2

[0001.853] I> Size of crypto header is 8192

[0001.857] I> Size of crypto header is 8192

[0001.861] I> strt_pg_num(71424) num_of_pgs(16) read_buf(0x8007e000)

[0001.868] I> BCH of MB2 read from storage

[0001.871] I> BCH address is : 0x8007e000

[0001.876] C> LOADER: Could not read binary 6.

[0001.880] E> Failed to load MB2

[0001.883] C> Task 0x46 failed (err: 0x27228e18)

[0001.888] E> Top caller module: MB2_PARAMS, error module: LOADER, reason: 0x18, aux_info: 0x8e

[0001.896] C> Boot Info Table status dump :

0111111100111000111111111111111111111111111110111011111101111111110101

(With the same error for slot 0 before this.)

This is the command that I run to flash:
sudo ADDITIONAL_DTB_OVERLAY_OPT=“BootOrderNvme.dtbo”
./tools/kernel_flash/l4t_initrd_flash.sh
–external-device nvme0n1p1
-c tools/kernel_flash/flash_l4t_external.xml
-p “-c bootloader/generic/cfg/flash_t234_qspi.xml”
–network usb0
jetson-orin-nano-devkit internal

I’ve attached my serial console logs as well as the flash logs.
jetson_serial.txt (100.5 KB)
flash_1-2_0_20250407-165336.log (49.1 KB)

A weird detail as well is that for the 2 jetson modules that wont boot, is that they both booted and worked after the first flash but when I reflashed using the same command they both stopped booting.

But from the log you shared, it looks like they didn’t work after the flash.

Could you share the log that has " they both booted and worked after the first flash"?

Also, is this test based on NV devkit or custom board?

Yes exactly didnt work after the flash.

Sorry dont have it anymore but can flash a new module and get it for you if you want?

Custom board, but I have tried changing it to devkit but same issue.

The two working ones had jetpack 5 installed before flashing jetpack 6, so I just tried flashing jetpack 5 and then jetpack 6 again onto one of the faulty ones and now it works. However, we are looking to sell our product containing the jetson in quite large quantities so would prefer to be able to flash jetpack 6 directly, do you have any idea why flashing jetpack 5 is required at the moment?

Hi,

Could you put this module to NV devkit and see if you could reproduce the same behavior with Sdkmanager? Not even trying with manual command. Just sdkmanager with jeptack5.1.5 or 5.1.4.

Yes I got the same behavior

Please RMA this module.

But I mean it seems like I get the same issue for all jetson orin nano production modules (the ones without sd-cards), do you have any idea why it works when I first flash jetpack 5 then jetpack 6?

Hi,

Just to clarify that it seems I didn’t get your scenario correctly.

To make my questions more clearly
→ Is there any jetpack version that could be used on those modules and make them work for now?

It sounds like some versions are still working. My question here is if you revert back to those versions, then will it work again? or even that one is dead now?

Hi,

Yes the problem is that if I flash L4T 36.2 directly (on a brand new module) it wont boot, but if I instead flash L4T 35.3.1 it boots just fine. It also boots fine if I flash L4T 36.2 after flashing L4T 35.3.
So basically, as long as L4T 35.3.1 has been flashed at some time in the modules history then L4T 36.2 works as intended.

Do you still have “brand new modules” that can do the test?

I just want to clarify what thing could you do for now so that I could provide you the next steps.

Yes we have a few extra that we haven’t touched yet.

Could you use those new modules on devkit and directly flash with rel-36.4.3 (jp6.2) with sdkmanager and capture the UART log during flash and first boot?

I have no way of capturing the UART log on the devkit since I don’t have the tools. Our own board has an usb port for that specific purpose.

Could you get the usb-ttl cable for devkit to use to check log? Those should be simple one and should not cost much.

I have ordered one now, will conduct the experiment when I get it and get back to you!

sdkm-2025-04-16-13-58-49.log (928.9 KB)
jetson_new_module_jp6_2.log (100.6 KB)

I installed a fresh module as well as a nvme ssd on the devkit carrier board and tried to directly flash with rel-36.4.3 (jp6.2) with sdkmanager but wasn’t able to. I attached the UART log as well as the log from sdk manager. Got any idea what’s wrong?

I notice the error happened in the very end of the flash process. Not related to any MB2 or bootloader here.

It is already trying to flash the NVMe.

14:14:19.281 - info: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_ORIN_NANO_TARGETS: Copied 16896 bytes from /mnt/internal/gpt_secondary_3_0.bin to address 0x03ffbe00 in flash
14:14:19.282 - info: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_ORIN_NANO_TARGETS: [ 231]: l4t_flash_from_kernel: Successfully flash the qspi
14:14:19.289 - info: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_ORIN_NANO_TARGETS: [ 231]: l4t_flash_from_kernel: The device size indicated in the partition layout xml is smaller than the actual size. This utility will try to fix the GPT.
14:14:19.290 - info: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_ORIN_NANO_TARGETS: [ 231]: l4t_flash_from_kernel: Error flashing external device
14:14:19.293 - info: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_ORIN_NANO_TARGETS: Flash failure

What is the nvme SSD size in use here?

And also some nvme error from your uart log.

[ 44.427215] usb usb2-port2: Cannot enable. Maybe the USB cable is bad?
[ 55.160672] blk_update_request: critical medium error, dev nvme0n1, sector 32 op 0x0:(READ) flags 0x80700 phys_seg 8 prio class 0
[ 55.509075] blk_update_request: critical medium error, dev nvme0n1, sector 32 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 55.509088] Buffer I/O error on dev nvme0n1, logical block 4, async page read
[ 55.858645] blk_update_request: critical medium error, dev nvme0n1, sector 32 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 55.858659] Buffer I/O error on dev nvme0n1, logical block 4, async page read
[ 56.209221] blk_update_request: critical medium error, dev nvme0n1, sector 32 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 56.209230] Buffer I/O error on dev nvme0n1, logical block 4, async page read
[ 56.558465] blk_update_request: critical medium error, dev nvme0n1, sector 32 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 56.558480] Buffer I/O error on dev nvme0n1, logical block 4, async page read
[ 56.908407] blk_update_request: critical medium error, dev nvme0n1, sector 32 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 56.908422] Buffer I/O error on dev nvme0n1, logical block 4, async page read
[ 57.257939] blk_update_request: critical medium error, dev nvme0n1, sector 32 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 57.257950] Buffer I/O error on dev nvme0n1, logical block 4, async page read
[ 57.607253] blk_update_request: critical medium error, dev nvme0n1, sector 32 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 57.607268] Buffer I/O error on dev nvme0n1, logical block 4, async page read
[ 57.957740] blk_update_request: critical medium error, dev nvme0n1, sector 32 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 57.957755] Buffer I/O error on dev nvme0n1, logical block 4, async page read
[ 58.539704] blk_update_request: critical medium error, dev nvme0n1, sector 32 op 0x0:(READ) flags 0x80700 phys_seg 8 prio class 0
[ 58.889346] Buffer I/O error on dev nvme0n1, logical block 4, async page read
[ 59.238156] Buffer I/O error on dev nvme0n1, logical block 4, async page read

The nvme SSD is 256 GB, the specific model is SP256GIMEM3K5EV0 and it’s the same one we have used for the other ones as well.
I did format it to ext4 after failing the flash and after attempting to flash again (using SDK manager just as before) I got the same error. I also tried changing the m.2 port as there are two (m.2 2230 and 2280 I believe) and that also gave me the same result.

Hi,

Instead of trying other m.2 port, could you also test other kind of NVMe SSD?