Jetpack 4.4 goes in restart loop after emmc flash using sdk manager v (4.2) or ./flash.sh

I removed all the Nvidia sdk related directory from my host machine and installed new SDK manager as mentioned above in this thread . Following are steps .

After successful install Nano restarts multiple times with following messages:

Really dont understand whats happening here .

Update : It tried both sdk manager and flash.sh and same issue still persist , not sure whats wrong .

I have the save problem like you, does anyone have solutions ?

No even I am stuck and waiting for someone’s reply , not sure whats happening here , if this is an issue JP4.4

First boot after flashing SoM until oem-config seems to work fine , problem comes when I restart it.

@linuxdev any pointers to debug this issue ?

Can we verify that this is the eMMC model, and not the microSD model? If so, then the easiest way to proceed would be to use a command line flash, and if that works, then you could add optional packages (SDKM can be used with a running Jetson without flash steps if the Jetson is fully booted and not in recovery mode…sometimes it looks like you have to flash just because it is checked, but this is not the case). Command line flash has fewer complications and the log is quite useful.

Also, assuming an eMMC Nano, we need to verify that for a dev kit carrier board you are using the b01 revision (a02 was an earlier release and won’t work with eMMC models).

Assuming your host PC has about 40GB or so of free space (“df -H /where/ever/u/flash/from/Linux_for_Tegra”), the following would both flash and log an eMMC model of a Nano (I’m also assuming this is a dev kit carrier board):
sudo ./flash.sh jetson-nano-emmc mmcblk0p1 2>&1 | tee log_flash.txt
…then the “log_flash.txt” can be uploaded/attached to the forum thread.

Preferably have a monitor/keyboard attached to the Jetson at the time of flash.

Yes , it is a eMMC model.
No it is not a dev kit carrier board. This is production carrier board taken from a vendor. https://smartcow.ai/en/products/cerberus-nx/. I can flash it on dev kit if that is needed.

After flash , everything boots normally to the screen where we are supposed to setup user name password (with trail of error as posted above ). However initial setup is a success. log_flash.txt (325.2 KB) Once that is done on next reboot nano goes on infinite reboot.

Thank you so much for your response.
Following is the log_flash.txt

This may or may not have meaning, and someone knowing details will have to answer:

[ 188.0579 ] Warning: EKS partition magic header mismatch!
[ 188.0940 ] Writing partition EKS with eks.img

Other than this I saw nothing wrong with the flash. It is quite possible the warning has no real meaning in these circumstances (which is why it might be labelled as a “warning” and not “error”).

Regarding which carrier board it is flashed from: This won’t matter during the flash, so long as the right content is flashed for the carrier board which the module will run on. There is unlikely any specific reason you would need to use another carrier board for flash.

The real problem is usually related to flashed content relative to the specific carrier board being used. You would have needed to have used the third party board support package, and you would need to verify that this carrier board works with the eMMC model (it probably does, but it is worth checking), plus verify that your specific release version used from NVIDIA and the carrier board manufacturer release version are compatible. Since the flash process itself seems to be valid this is the first thing anyone else will ask.

If flash was with compatible versions from NVIDIA and the carrier board, then a serial console boot log would be needed. Unlike the screenshot, serial console works earlier on in boot when the monitor can’t see anything, and also is searchable. Even up until some fatal error the serial console will be able to log boot when the monitor is long dead. Serial console information can be found here:
https://www.jetsonhacks.com/2019/04/19/jetson-nano-serial-console/

do you use custom image provided by the vendor or the default sdkmanager default stock image?
you should be using custom supplied OS image, in my opinion
Upd, upon checking it seems that the stock default image should be used;
Nano eMMC image needs to be flashed with sdkmanager

1 Like

No BSP is required unless if you want to use 36 PIN MIPI-CSI connector, any jetpack should support it.

1 Like

@harshit2
could you put the device into the recovery mode,
then could you execute the following from the Host PC?

sudo sdkmanager --cli install --user youruser@mail.com --logintype devzone --product Jetson --version 4.4 --targetos Linux --target P3448-0002--flash all --targetimagefolder /home/username/Downloads/nvidia/installation_nano--downloadfolder /home/username/Downloads/nvidia/

If the above doesn’t work, I suggest trying to flash the board with flash.sh
folder paths & email address will need to be customized in the comand above

Hey , thank you for your reply. I am using default sdk manager and default image. how do I verify if the image is sdcard image or emmc image?

what is the output of executing of the command above?
does it flash?
boots?
flashes but doesn’t boot?
else?

Let me try this command

@harshit2
lets determine which exactly hardware is being used
cerberus_nx carrier board was mentioned, right? was it purchased together with jetson module? without jetson module? With nano jetson module or nx jetson module? If the module is nano, is it of a02 or b01 type?
could you point out to exact configuration that you obtained?

Login succeeded.
Loading user information…
User information loaded successfully.
Loading server data…
Server data loaded successfully.
Target Image is already installed on this host machine (/home/harshit/Downloads/nvidia/nvidia_target/JetPack_4.4_Linux_JETSON_NANO). Please use SDK Manager to uninstall the Target Image, or select a different location using ‘targetimagefolder’.

yes, lets uninstall it first;
in the command line
change the values from

 --cli  install

to

 --cli  uninstall

then execute it once again;
after installation is complete; try again;

the complication is that it is required to know which exactly hardware version of the module is being used.

It is b01 type

1 Like

it is written A2 on the top of it;
Model P3448 in the right bottom corner

Login succeeded.
Loading user information…
User information loaded successfully.
Loading server data…
Server data loaded successfully.
Session initialized…

===== UNINSTALLATION COMPLETED SUCCESSFULLY. =====
- Drivers for Jetson: Uninstalled
- File System and OS: Uninstalled

===== Uninstallation completed successfully - Total 2 components =====
===== 2 succeeded, 0 failed, 0 up-to-date, 0 skipped =====