Jetson Nano 2gb is stuck in bootloop (Starting CPU & Halting co-processor)

My nvidia jetson nano 2gb developer board is stuck in a bootloop. I flashed the latest image intented for the 2gb developer board and I went through the settings. After I somehow couldn’t log in, I turned off the power and flashed the image again. From there it has been stuck in a bootloop and sdk manager can’t find the device because it doesn’t provide a ttyACM0 anymore (it did before).

The log starts with:

[0001.227] Starting CPU & Halting co-processor

64NOTICE: BL31: v1.3(release):b5eeb33
NOTICE: BL31: Built : 08:56:32, Feb 19 2022
ERROR: Error initializing runtime service trusty_fast
[0001.349] RamCode = 1
[0001.353] LPDDR4 Training: Read DT: Number of tables = 2
[0001.358] EMC Training (SRC-freq: 204000; DST-freq: 1600000)
[0001.371] EMC Training Successful
[0001.374] 408000 not found in DVFS table
[0001.381] RamCode = 1
[0001.384] DT Write: emc-table@204000 succeeded
[0001.390] DT Write: emc-table@1600000 succeeded
[0001.394] LPDDR4 Training: Write DT: Number of tables = 2
[0001.436]
[0001.437] Debug Init done
[0001.440] Marked DTB cacheable
[0001.443] Bootloader DTB loaded at 0x83000000
[0001.448] Marked DTB cacheable
[0001.450] Kernel DTB loaded at 0x83100000
[0001.454] DeviceTree Init done
[0001.467] Pinmux applied successfully
[0001.472] gicd_base: 0x50041000
[0001.475] gicc_base: 0x50042000
[0001.478] Interrupts Init done
[0001.482] Using base:0x60005090 & irq:208 for tick-timer
[0001.488] Using base:0x60005098 for delay-timer
[0001.492] platform_init_timer: DONE
[0001.496] Timer(tick) Init done
[0001.499] osc freq = 38400 khz
[0001.503]
[0001.504] Welcome to L4T Cboot
[0001.507]
[0001.508] Cboot Version: 00.00.2018.01-t210-a2f2e4b8
[0001.513] calling constructors
[0001.516] initializing heap
[0001.519] initializing threads
[0001.522] initializing timers
[0001.525] creating bootstrap completion thread
[0001.529] top of bootstrap2()
[0001.532] CPU: ARM Cortex A57
[0001.535] CPU: MIDR: 0x411FD071, MPIDR: 0x80000000
[0001.540] initializing platform
[0001.547] Manufacturer: MF = 0xc2, ID MSB = 0x25
[0001.552] ID LSB = 0x36, ID-CFI len = 194 bytes
[0001.556] Macronix QSPI chip present
[0001.560] SPI device register
[0001.563] init boot device
[0001.565] allocating memory for boot device(SPI)
[0001.570] registering boot device
[0001.578] QSPI bdev is already initialized
[0001.582] Enable APE clock

and ends with

[0000.652] No write function to write to current BFS 0
[0000.656] Clobber: returns e=0x1
[0000.659] - failover failed; Continuing with bad image …
[0000.665] Loading NvTbootKernelDTB
[0000.731] Verifying NvTbootKernelDTB in OdmNonSecureSBK mode
[0000.800] Kernel DTB Load Address: 0x83100000
[0000.804] BoardID = 3448, SKU = 0x3
[0000.807] QSPI-ONLY: SkipQspiOnlyFlag = 0
[0000.811] Nano-SD: checking PT table on QSPI …
[0000.816] NvTbootFailControlDoFailover: Doing failover: Cboot partition 0 is corrupted (ec=0x0).
[0000.824] NvTbootFailControlDoClobber:
[0000.828] Current BFS=0
[0000.830] No write function to write to current BFS 0
[0000.835] Clobber: returns e=0x1
[0000.838] - failover failed; Continuing with bad image …
[0000.845] Loading cboot binary
[0000.961] Verifying EBT in OdmNonSecureSBK mode
[0001.002] Bootloader load address is 0x92c00000, entry address is 0x92c00258
[0001.009] Bootloader downloaded successfully.
[0001.013] BoardID = 3448, SKU = 0x3
[0001.017] QSPI-ONLY: SkipQspiOnlyFlag = 0
[0001.020] Nano-SD: checking PT table on QSPI …
[0001.025] NvTbootFailControlDoFailover: Doing failover: Cboot partition 0 is corrupted (ec=0x0).
[0001.033] NvTbootFailControlDoClobber:
[0001.037] Current BFS=0
[0001.039] No write function to write to current BFS 0
[0001.044] Clobber: returns e=0x1
[0001.047] - failover failed; Continuing with bad image …
[0001.052] PT: Partition NCT NOT found !
[0001.056] Warning: Find Partition via PT Failed
[0001.060] Next binary entry address: 0x92c00258
[0001.065] BoardId: 3448
[0001.069] Overriding pmu board id with proc board id
[0001.074] Display board id is not available
[0001.078] No Bpmp FW loaded
[0001.081] Not loading WB0 as no bpmp/sc7entry fw
[0001.085] Set NvDecSticky Bits
[0001.089] GSC2 address ff93fffc value c0edbbcc
[0001.095] GSC MC Settings done
[0001.098] BoardID = 3448, SKU = 0x3
[0001.101] QSPI-ONLY: SkipQspiOnlyFlag = 0
[0001.105] Nano-SD: checking PT table on QSPI …
[0001.110] NvTbootFailControlDoFailover: Doing failover: Cboot partition 0 is corrupted (ec=0x0).
[0001.118] NvTbootFailControlDoClobber:
[0001.122] Current BFS=0
[0001.124] No write function to write to current BFS 0
[0001.129] Clobber: returns e=0x1
[0001.132] - failover failed; Continuing with bad image …
[0001.138] TOS Image length 53680
[0001.141] Monitor size 53680
[0001.144] OS size 0
[0001.159] Secure Os AES-CMAC Verification Success!
[0001.164] TOS image cipher info: plaintext
[0001.167] Loading and Validation of Secure OS Successful
[0001.183] NvTbootPackSdramParams: start.
[0001.188] NvTbootPackSdramParams: done.
[0001.192] Tegraboot started after 84906 us
[0001.196] Basic modules init took 1088926 us
[0001.200] Sec Bootdevice Read Time = 12 ms, Read Size = 61 KB
[0001.206] Sec Bootdevice Write Time = 0 ms, Write Size = 0 KB
[0001.211] Next stage binary read took 11286 us
[0001.216] Carveout took -91856 us
[0001.219] CPU initialization took 128029 us
[0001.223] Total time taken by TegraBoot 1136385 us

[0001.227] Starting CPU & Halting co-processor

Please flash the board with sdkamagner. SDcard image cannot bring the board back in current situation.

Hi Wayne, thanks for your response. I tried using the sdkmanager but unfortunately that isn’t possible. Because it is stuck in the bootloop, it can’t find the Jetson as a ttyACM0 device which it could before this bootloop problem. Therefore, sdk manager can’t connect to it.

If you have the recovery pin jumpered to ground as you apply power or reset power (then remove the recovery pin short to ground), then the Jetson should go into recovery mode. Short of hardware failure the boot loop will not occur in recovery mode.

Yes, please put board into the recovery mode as linuxdev’s suggestion.

No matter which kind of jetson, when we want to flash the board, jetson needs to be in recovery mode (RCM).
Please be aware that sdcard image is not really “flash” the board.

If your board is still able to boot into linux, then sdkmanager will access to the board directly and use software command to put the board into RCM.

But if your board is not able to boot into linux, then you need to set the board into RCM manually by using the jumper on the pin.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.