First of all, it’s Jetson instead of Jackson…
Looks like the bootloader on the QSPI memory is corrupted, so please first try re-flashing the device with SDK Manager first.
Some trivia: Boot stage software is in QSPI memory on the Jetson module itself, and so the Jetson Nano can be flashed…it isn’t just the SD card that can be flashed. It can’t find the partition, so that is either the SD card partition or perhaps it is boot content in QSPI. Thus it is a good idea to flash not just the SD card, but also the QSPI.
If you are referring to recovery mode when you say “after recovery”, then recovery mode itself does nothing but make the Jetson temporarily able to be flashed. In and of itself recovery mode does nothing permanent. One has to flash the actual Jetson module to repair QSPI and most boot content.
Stuck at 99% recovering.
Virtual Box and VM Ware are all the same.
The same is true for Ubuntu versions 18.04 and 16.04.
Please check the attached file.
Flashing stopping in the middle is usually when a VM loses the USB, but fails to pick it back up upon reconnect. All VMs have this issue if not configured right.
Also, sometimes a cheap USB charger cable can do this, but it is usually a bit different in failure.
Recovery was successful by installing on a PC without using a virtual machine.
I would like to know how to prevent this from happening when using it in the future.
The log that occurred at that time is the log I wrote about in the first post.
This phenomenon occurred in 6 out of 14 devices, and as you mentioned, recovery was successful by installing Ubuntu on a PC rather than a virtual machine.
I will reattach the log.
[0000.125] [L4T TegraBoot] (version 00.00.2018.01-l4t-e82258de)
[0000.130] Processing in cold boot mode Bootloader 2
[0000.135] A02 Bootrom Patch rev = 1023
[0000.138] Power-up reason: pmc por
[0000.141] No Battery Present
[0000.144] pmic max77620 reset reason
[0000.147] pmic max77620 NVERC: 0x40
[0000.151] RamCode = 0
[0000.153] Platform has DDR4 type RAM
[0000.156] max77620 disabling SD1 Remote Sense
[0000.161] Setting DDR voltage to 1125mv
[0000.165] Serial Number of Pmic Max77663: 0x20052b
[0000.172] Entering ramdump check
[0000.175] GetRamDumpCarveOut = 0x0
[0000.179] RamDumpCarveOut=0x0, RamDumperFlag=0xe59ff3f8
[0000.184] Last reboot was clean, booting normally!
[0000.188] Sdram initialization is successful
[0000.192] SecureOs Carveout Base=0x00000000ff800000 Size=0x00800000
[0000.199] Lp0 Carveout Base=0x00000000ff780000 Size=0x00001000
[0000.204] BpmpFw Carveout Base=0x00000000ff700000 Size=0x00080000
[0000.210] GSC1 Carveout Base=0x00000000ff600000 Size=0x00100000
[0000.216] GSC2 Carveout Base=0x00000000ff500000 Size=0x00100000
[0000.222] GSC4 Carveout Base=0x00000000ff400000 Size=0x00100000
[0000.228] GSC5 Carveout Base=0x00000000ff300000 Size=0x00100000
[0000.234] GSC3 Carveout Base=0x000000017f300000 Size=0x00d00000
[0000.250] RamDump Carveout Base=0x00000000ff280000 Size=0x00080000
[0000.256] Platform-DebugCarveout: 0
[0000.259] Nck Carveout Base=0x00000000ff080000 Size=0x00200000
[0000.265] Non secure mode, and RB not enabled.
[0000.269] BoardID = 3448, SKU = 0x0
[0000.272] QSPI-ONLY: SkipQspiOnlyFlag = 0
[0000.276] Nano-SD: checking PT table on QSPI …
[0000.281] Read PT from (2:0)
[0000.296] Using BFS PT to query partitions
[0000.302] Loading Tboot-CPU binary
[0000.330] Verifying TBC in OdmNonSecureSBK mode
[0000.341] Bootloader load address is 0xa0000000, entry address is 0xa0000258
[0000.348] Bootloader downloaded successfully.
[0000.352] Downloaded Tboot-CPU binary to 0xa0000258
[0000.357] MAX77620_GPIO5 configured
[0000.360] CPU power rail is up
[0000.363] CPU clock enabled
[0000.367] Performing RAM repair
[0000.370] Updating A64 Warmreset Address to 0xa00002e9
[0000.375] BoardID = 3448, SKU = 0x0
[0000.378] QSPI-ONLY: SkipQspiOnlyFlag = 0
[0000.382] Nano-SD: checking PT table on QSPI …
[0000.387] Loading NvTbootBootloaderDTB
[0000.453] Verifying NvTbootBootloaderDTB in OdmNonSecureSBK mode
[0000.525] Bootloader DTB Load Address: 0x83000000
[0000.529] BoardID = 3448, SKU = 0x0
[0000.532] QSPI-ONLY: SkipQspiOnlyFlag = 0
[0000.536] Nano-SD: checking PT table on QSPI …
[0000.541] Loading NvTbootKernelDTB
[0000.607] Verifying NvTbootKernelDTB in OdmNonSecureSBK mode
[0000.680] Kernel DTB Load Address: 0x83100000
[0000.684] BoardID = 3448, SKU = 0x0
[0000.687] QSPI-ONLY: SkipQspiOnlyFlag = 0
[0000.691] Nano-SD: checking PT table on QSPI …
[0000.697] Loading cboot binary
[0000.813] Verifying EBT in OdmNonSecureSBK mode
[0000.855] Bootloader is corrupted!
[0000.858] Error in NvTbootLoadBinary: 0x14 !
[0000.862] BoardID = 3448, SKU = 0x0
[0000.865] QSPI-ONLY: SkipQspiOnlyFlag = 0
[0000.869] Nano-SD: checking PT table on QSPI …
[0000.874] PT: Partition RBL NOT found !
[0000.877] Warning: Find Partition via PT Failed
[0000.882] Error is 1
The log indicates not finding a partition, which is something that occurs in the QSPI code, so I am not surprised that it worked after flashing the actual Jetson (and it is quite common that a VM would fail, but a native Linux host PC would work). Probably the reason some failed is that they had older code in the QSPI of the module which was not compatible with that SD card content release.
Thank you as always for your quick replies.
If there was an incompatible code on the SD CARD, I wonder if there would be a reason why 8 out of 14 units were normal. (If there was incompatible code, shouldn’t this happen on all devices?)
Also, if the problem occurred due to incompatible code, I would like to know if recovery can occur and if the same SD CARD is used, booting may not occur again.
The flash of the module itself updates the QSPI code. There are many releases the modules might have arrived with. Some of those releases would be older than others, and there is no predicting if what you got was five years out of date or from within the last six months. I assume each SD card had the same release, so an incompatibility would have been with the release version of the content in the QSPI on the module itself. Once QSPI is updated you shouldn’t have problems with it again (well, at least not if you don’t go to an old SD card release).
Whenever you get a new Jetson, regardless of whether it is an eMMC model or an SD card (QSPI) model you should always flash the Jetson at least once with the most recent available release. Granted, if you are producing a product, then you might pick a specific release, but you’d still want to flash new units. People tend to not expect an SD card model gets flashed, but it does due to the QSPI performing every function that a BIOS would perform. Once that “pseudo BIOS” is updated it should work with a number of SD card releases (but this isn’t guaranteed; there are OTA updates which understand this, but that’s another topic).
Incidentally, recovery mode does nothing to alter a Jetson other than temporarily making it a custom USB device. It is in this mode one flashes QSPI of an SD card model.
Can you tell me how to apply Jetson to the latest release rather than recovery mode?
I would also like to know if I can proceed with the SDK Manager’s JETSON OS operation in the attached image (the part marked in red).
I will add that in addition to JetPack/SDK Manager being the way to apply the update, that flash through that software mandates the Jetson be in recovery mode. However, when flashing, the completion of flash automatically reboots the Jetson. Once first boot login account setup is complete, various optional packages (such as CUDA) are installed by JetPack/SDKM over ssh to that account on a fully booted Jetson. JetPack does allow you to uncheck flash, and install some compatible optional components to a fully booted Jetson. Flash, however, absolutely requires recovery mode.
SD card creation can be a separate step for SD card models. For SD card models the QSPI still gets flashed with a lot of content that needs to be compatible in release version to the SD card content. QSPI content usually works for several releases of SD card content, but when a Jetson first arrives, I always expect QSPI needs to be flashed at least once.
