This is definitely not a log from 4.6.3 because this is jp 5 boot flow.
Note that if you have a newer SDK Manager, then you can start like this to see older releases:
Ok, so I tried with jetpack 4.6.1 and this is the log:
log461.txt (20.0 KB)
It’s worth mentioning that I did it with balena etcher because my computer is running with ubuntu 20.04 and to flash the jetson with jp 4.6.3 I need ubuntu 18.04
You cannot use sdcard image. That method does not really flash anything.
The board itself has bootloader component on it. Your method to keep changing sdcard 10000 times won’t ever change the bootloader on the board even once…
It has to be done by sdkmanager.
Thank you @WayneWWW for your help. I will install ubuntu 18.04 in a computer and flash the jetson with jetpack 4.6.3 via sdkmanager. I will let you know when this is done to share log I get from it.
So I installed kubuntu 18.04 and sdkmanager, but the boot process got stuck in this point for a couple of hours.
What could be wrong?
Export your log file. There is a export LOGS button in your sdkmanager.
Also, dump the serial console log when the flash error happened too.
Here is the serial console:
seriallog.txt (3.9 KB)
and here is the sdkmanager logs:
log.zip (428.2 KB)
Are you sure that is NX developer kit? The log looks abnormal.
Is it sdcard module or emmc module?
Do you have other host/usb cable to try to flash the board?
Yes I can try it with other cable and other pc. I’ll be back with the results.
So I tried to flashed the board in another PC and with multiple USB cables and I’m getting the following logs:
SDKM_logs_2023-05-05_16-00-51.zip (398.7 KB)
I don’t know if it is important but this is the log I’m getting from the following command: dmesg --follow
dmesg.txt (1.5 KB)
I don’t know what is happening that now I can’t even flash the jetson, but before it used to flash it.
I get it that it says that the USB comunication failed but I bought a new cable and still same issue.
What is the serial console log from device when flash error happened?
That’s what I got:
minicom.txt (3.4 KB)
Looks like just garbled log. Please make sure the setup is correct. Make sure baud rate and console are set correctly.
In addition to what @WayneWWW is asking (an incorrect bit rate or stop bit setting would garble output, and it should be 115200 8N1), it is possible that if you are using a wildly different language encoding (e.g., a 16-bit UTF), then this would also be garbled. What do you see on the host PC side for “
echo $LANG”? Most people would see “
Is this still an issue to support? Any result can be shared? Thanks
Yep, it is still an issue. I have not managed to get the jetson to work