Multiple jetson nx (core boards on the development kit) cannot be started

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
#1

Multiple jetson nx (core boards on the development kit) cannot be started. The serial port loop printing information is shown below. What is the reason and how to solve it?

0000000000011111111110111000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
??
[0000.024] W> RATCHET: MB1 binary ratchet value 4 is too large than ratchet level 2 from HW fuses.
[0000.033] I> MB1 (prd-version: 1.5.1.3-t194-41334769-d2a21c57)
[0000.038] I> Boot-mode: Coldboot
[0000.041] I> Chip revision : A02P
[0000.044] I> Bootrom patch version : 15 (correctly patched)
[0000.049] I> ATE fuse revision : 0x200
[0000.053] I> Ram repair fuse : 0x0
[0000.056] I> Ram Code : 0x0
[0000.058] I> rst_source : 0xb
[0000.061] I> rst_level : 0x1
[0000.065] I> Boot-device: QSPI
[0000.067] I> Qspi flash params source = brbct
[0000.071] I> Qspi using bpmp-dma
[0000.074] I> Qspi clock source : pllp
[0000.078] I> QSPI Flash Size = 32 MB
[0000.081] I> Qspi initialized successfully
[0000.085] E> LOADER: Failed to verify SMD.
[0000.089] I> Primary SMD copy is invalid, try with secondary copy…
[0000.095] E> LOADER: Failed to verify SMD.
[0000.099] E> LOADER: Failed to verify SMD & SMD_b.
[0000.103] E> Error: SMD: Load failed
[0000.107] E> Load SMD failed
[0000.109] E> LOADER: Failed to get slot for boot chain from SMD.
[0000.115] E> LOADER: Failed to get storage info for binary 0 from loader.
[0000.121] E> LOADER: Failed to get info for binary 0 from loader.
[0000.127] C> LOADER: Could not read binary 0.
[0000.131] C> Fail to load mb1-bct bin
[0000.134] E> Task 24 failed (err: 0x1d1d1318)
[0000.138] E> Top caller module: LOADER, error module: LOADER, reason: 0x18, aux_info: 0x13
[0000.146] I> MB1(1.5.1.3-t194-41334769-d2a21c57) BIT boot status dump :
0000000000011111111110111000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

#2

It was good at the beginning, but the problem appeared after a period of use.

#4

hello 1316886298,

may I know which JetPack release it is.
could you please share the details about what’s the software modification you’d done?
thanks

#5

Jetson NX Developer Kit SD Card Image - JP 4.4 DP. The software did not make any changes.

#6

hello 1316886298,

JetPack-4.4 DP is Developer Preview release,
please access JetPack SDK for JetPack-4.4 / l4t-r32.4.3, which is the latest production release.
thanks

#7

Jetpack SDK for jetpack-4.4 / l4t-r32.4.3 also cannot be started. Whether the Jetson NX developer kit will fail to start due to sudden power failure. Through repeated power-on and power-off test, it was found that one board failed to start.

#8

hello 1316886298,

according to https://developer.nvidia.com/embedded/jetson-xavier-nx-devkit, are you working with 19V power supply?

#9

There is no update from you for a period, assuming this is not an issue any more.
Hence we are closing this topic. If need further support, please open a new one.
Thanks

Is this still an issue to support? Any result can be shared?

#11

I have started to experience this issue also.

[0000.024] W> RATCHET: MB1 binary ratchet value 4 is too large than ratchet level 2 from HW fuses.
[0000.033] I> MB1 (prd-version: 1.5.1.3-t194-41334769-d2a21c57)
[0000.038] I> Boot-mode: Coldboot
[0000.041] I> Chip revision : A02P
[0000.044] I> Bootrom patch version : 15 (correctly patched)
[0000.049] I> ATE fuse revision : 0x200
[0000.053] I> Ram repair fuse : 0x0
[0000.056] I> Ram Code : 0x0
[0000.058] I> rst_source : 0xb
[0000.061] I> rst_level : 0x1
[0000.065] I> Boot-device: QSPI
[0000.067] I> Qspi flash params source = brbct
[0000.071] I> Qspi using bpmp-dma
[0000.074] I> Qspi clock source : pllp
[0000.078] I> QSPI Flash Size = 32 MB
[0000.081] I> Qspi initialized successfully
[0000.085] E> LOADER: Failed to verify SMD.
[0000.089] I> Primary SMD copy is invalid, try with secondary copy…
[0000.095] E> LOADER: Failed to verify SMD.
[0000.099] E> LOADER: Failed to verify SMD & SMD_b.
[0000.103] E> Error: SMD: Load failed
[0000.107] E> Load SMD failed
[0000.109] E> LOADER: Failed to get slot for boot chain from SMD.
[0000.115] E> LOADER: Failed to get storage info for binary 0 from loader.
[0000.121] E> LOADER: Failed to get info for binary 0 from loader.
[0000.127] C> LOADER: Could not read binary 0.
[0000.131] C> Fail to load mb1-bct bin
[0000.134] E> Task 24 failed (err: 0x1d1d1318)
[0000.138] E> Top caller module: LOADER, error module: LOADER, reason: 0x18, aux_info: 0x13
[0000.146] I> MB1(1.5.1.3-t194-41334769-d2a21c57) BIT boot status dump :
00000000000111111111101110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

This same block of text keeps spitting out nonstop from the console port. I’m using the production version of the NX on a custom carrier board. I have verified that it’s the NX itself and not the boards. The NX modules that work function without issue on all of the carrier boards and power supplies that I have tested, and the NX modules that present the issue produce the same behaviour and output on all of the same carrier boards and power supplies.

Reflashing the NX modules does not help, it just does the same thing regardless.

#12

Hi cbstryker,

Please help to open a new topic for your issue. Thanks

#13

Actually, I solved the issue. I’ll just leave it here instead of opening a new (and solved) issue.

It seems this output occurs when the boot partition (or another) gets corrupted. I use a standard image that I flash to Jetson boards to clone our application. Cloning the image to the board again did not solve the problem.

What I did to solve it was to reflash the board through the Nvidia SDK Manager. My guess is that it flashed all of the partitions fresh, thus eliminating the problem. From there I could flash my own image and everything works.

1 Like
#14

Note that flashing signs the content prior to the flash. A signed partition on one Jetson will probably fail on another even if the non-signature part is correct. If you are interested in the topic, here are some URLs:

#15

Although it has been solved, why is there such a problem. We have more than 20 sets with this problem. I did to solve it also was to reflash the board through the NVIDIA SDK manager.At present, there are no problems with the repaired ones, but we dare not use new ones.

#16

I’m having the same issue as cbstryker, although on the dev version.

It started happening intermittently, and now happens all the time.

I have reflashed SD cards, a number of them, but it makes no difference. Also get the same errors whether the SD card is inserted or not.

I have ordered a replacement dev kit, but the shipping time is going to set us back a week, so any suggestions which we could try to get this working in the mean time would be much appreciated.

Log:

[0000.024] W> RATCHET: MB1 binary ratchet value 4 is too large than ratchet level 2 from HW fuses.
[0000.033] I> MB1 (prd-version: 1.5.1.3-t194-41334769-d2a21c57)
[0000.038] I> Boot-mode: Coldboot
[0000.041] I> Chip revision : A02P
[0000.044] I> Bootrom patch version : 15 (correctly patched)
[0000.049] I> ATE fuse revision : 0x200
[0000.053] I> Ram repair fuse : 0x0
[0000.056] I> Ram Code : 0x0
[0000.058] I> rst_source : 0xb
[0000.061] I> rst_level : 0x1
[0000.065] I> Boot-device: QSPI
[0000.067] I> Qspi flash params source = brbct
[0000.071] I> Qspi using bpmp-dma
[0000.074] I> Qspi clock source : pllp
[0000.078] I> QSPI Flash Size = 32 MB
[0000.081] I> Qspi initialized successfully
[0000.085] E> LOADER: Failed to verify SMD.
[0000.089] I> Primary SMD copy is invalidC try with secondary copy..
[0000.095] E> LOADER: Failed to verify SMD.
[0000.099] E> LOADER: Failed to verify SMD & SMD_b.
[0000.103] E> Error: SMD: Load failed
[0000.107] E> Load SMD failed
[0000.109] E> LOADER: Failed to get slot for boot chain from SMD.
[0000.115] E> LOADER: Failed to get storage info for binary 0 from loader.
[0000.121] E> LOADER: Failed to get info for binary 0 from loader.
[0000.127] C> LOADER: Could not read binary 0.
[0000.131] C> Fail to load mb1-bct bin
[0000.134] E> Task 24 failed (err: 0x1d1d1318)
[0000.138] E> Top caller module: LOADERC error module: LOADERC reason: 0x18C aux_info: 0x13
[0000.146] I> MB1(1.5.1.3-t194-41334769-d2a21c57) BIT boot status dump :
0000000000011111111110111000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
#17

I wonder if there are some non-volatile bits being set on the board which are separate from the flash storage used for the OS which aren’t being ‘sticky’ enough. This could be a problem in the wild when we come to ship products based on this module, so like you I would be very interested in getting more feedback from NVidia staff as if my guess here is right this could be a serious impedement to actually shipping based on the current units.