I bought a Jetson Orin Nano Super Developer Kit. I’ve updated the system with
JP513-orin-nano-sd-card-image_b29
jp61-rev1-orin-nano-sd-card-image
The system started flawlessly Ubuntu Desktop.
Then, in Bios, I switched from Tree Mode to ACPI, but afterwards the devkit didn’t start anymore with a video signal.
I’ve read that the system can be resetted. But how on this specific flavor?
I’ve attached an usb-to-serial-converter to the laptop, and the TXD, RXD and GND pin cables to the pins 10,9 and 6.
When attaching the power supply, the usb cable is detected as com3. Connecting with putty with a serial session on com3, I get the following output. terminal-output.txt (70.3 KB)
But afterwards, there is still no video signal.
With a jumper on pins GND+RST, the system does NOT boot up.
How to reset the bios settings of this type of Jetson Orin Nano (0955:7523, P3767-0003 ?
Recovery mode is a mode that makes this board able to be reflashed by another x86 host PC. It does not “recover” anything here unless the x86 PC start the flash process.
Then, in Bios, I switched from Tree Mode to ACPI, but afterwards the devkit didn’t start anymore with a video signal.
If you want to configure it back again, you could press ESC in your serial console when entering UEFI stage and it will show the UEFI panel in your console.
Please be aware that you already misconfigured the setting so no matter how many times you try to reboot, it won’t come back unless you configure the setting back.
Also, reset means reboot here. Does not really “reset to original”.
@WayneWWW Thank you for your reply. Really appreciate your help.
Actually pressing ESC either in the putty window or on the keyboard attached to the system is not detected. Nothing happens. No interaction is possible. The output attached above simply scrolls down on the putty window and that’s it.
How do I activate recovery mode correctly? In the forum most people are advising to use a female-to-female jumper on pins FCREC+GND. On 0955:7523 it’s on port 3+4, right? But if the jumper write is connected, and the power supply is attached, nothing happens on the serial console and again, no interaction is possible.
Which keyboard are you trying to use to press ESC here? The “keyboard” you should use is for the putty so it should be the host PC one. Not the USB keyboard connected on Jetson.
If nothing happened, it means your TX/RX connection of the pin has some issue.
Yes, after you put the board into recovery mode, you need to use sdkmaanger to flash the board from your host PC. SDK Manager | NVIDIA Developer
The TX/RX connection displays something. Either using windows putty on the windows11 laptop, and, on the ssh screen setserial console inside the wsl2 Ubuntu 24.04 session.
My assumption was, that the TX/RX connection is fine. I’ve used a new Delock usb-ttl6 cable. As said, no interaction (laptop keyboard) seems to be possible inside a serial console window. But, the system is NOT in recovery mode, because the jumper wire is not connected because IF connected, the system does not boot.
Ok. It looks like UEFI is in a dead status so pressing ESC won’t trigger it.
For the recovery mode, I think you still have some misunderstanding about the recovery mode.
Could you check some videos about how recovery mode would be working first? It might be more practical for you to know how things work here.
For example,
When your board is in recovery mode, it won’t print any log to your serial. All you can do now is start sdkmanager and flash. (but of course you still need to have power cable connected) If the board is in recovery mode and you have type C cable connected, it will be a usb device shown in lsusb (Ubuntu command).
Unfortunately WSL is not supported well, you better finding a native Ubuntu host.
BTW, I don’t know what you think you are doing here. Sdkmanager is a executable binary/program. It won’t work just because you install it. You have to run sdkmanager and operate the GUI on it…
Ok. It looks like UEFI is in a dead status so pressing ESC won’t trigger it.
I think the usb-ttl cable is the problem so I switched to an attached usb-a-to-usb-c cable + jumper on pins 2+3 (GND+FC REC) wired connected.
This is still wrong… USB-ttl cable and everything you just told here (type C cable/ jumper on pins GND +FC REC) are not conflicting to each other… they could be connected altogether. USB-TTL is just for dumping log. It has nothing to do with recovery mode.
There is a “EXPORT LOGS” button on the GUI, please click it and attach full zip file here.
It’s still the wsl2 Ubuntu24.04 with usb redirection. I haven’t switched to another host yet because the issues do not seems to be wsl2 related. E.g. in sdkm-2025-01-04-15-48-23.log at 15:49:41.566 is a docker.socket issue.
Just want to say this again… USB-TTL is just for dumping the log. It has nothing to do with your flash or usb detection…
You don’t need to remove it or add it back. It will not affect whether your Jetson would be detected or not.
The usb detection here is only from recovery mode. If the board is not in recovery mode, then it would not be detected.
As I already mentioned, we don’t guarantee WSL2 would be able to work here. Please try to get a native ubuntu 22 or 20.04 host.
Okay, the clarification about USB-TTL makes sense. As soon as the flashing starts, a message appears ‘NVIDIA USB Device was removed (APX)’, and then an error appears.
On wsl2 Ubuntu 24.04 desktop, well, sudo apt install bind9-dnsutils for the digcommand was missing, but I guess the APX disconnection is intentionally
Hence, I will stage a physical host.
So far the product itself makes a solid impression, good material, especially the SD card eject function is much better than on RaspberryPi. The board gets quite warm, but even with the heatsink fan off, it is still “touchable”. I think an usb-a-to-usb-c cable with a jumper would be a help even with 10$ more expenditure. I like the SDK manager. It supports a bunch of boards and packs. In addition, in comparison to the Raspberry Pi Imager, it could be worth to add a custom flash option e.g. to stage a board with an own os. The issue (not solved, but now clear how to proceed) started by trying to make boot Photon OS. Therefore the change from tree to acpi. Of course this is not supported. But I guess beside NVidia AI tinkering, the board is versatile to use it for various purposes. Yes, support billing still goes with ‘best effort’. Again - many thanks @WayneWWW . Thankful.
I will post an update as soon as the issue has been solved 100%.
It took a while to stage a to-go-Ubuntu on an usb stick with installed SDK manager. It seems that a trial-Ubuntu is not enough because “reboots” are mandatory and without these, SDK manager fails on the first phase assembling the image.
After having assembled the image, SDK manager successfully starts flashing. The usb-a-to-usb-c cable setup is much more stable. SDK manager triggers disconnects/connects of APX multiple times but the flashing progresses steadily.
Somewhere at 96% the flashing fails.
1:44:35 INFO: Flash Jetson Linux - flash: 16896+0 records in
21:44:35 INFO: Flash Jetson Linux - flash: 16896+0 records out
21:44:35 INFO: Flash Jetson Linux - flash: 16896 bytes (17 kB, 16 KiB) copied, 0.0393959 s, 429 kB/s
21:44:35 INFO: Flash Jetson Linux - flash: Writing primary_gpt partition done
21:44:35 ERROR: Flash Jetson Linux - flash: Error: Invalid argument during seek for read on /dev/mmcblk0
21:44:35 ERROR: Flash Jetson Linux - flash: [ 29]: l4t_flash_from_kernel: Error: partprobe failed. This indicates that:
21:44:35 INFO: Flash Jetson Linux - flash: - the xml indicates the gpt is larger than the device storage
21:44:35 INFO: Flash Jetson Linux - flash: - the xml might be invalid
21:44:35 INFO: Flash Jetson Linux - flash: - the device might have a problem.
21:44:35 INFO: Flash Jetson Linux - flash: Please make correction.
21:44:35 INFO: Flash Jetson Linux - flash: Flash failure
21:44:35 INFO: Flash Jetson Linux - flash: Either the device cannot mount the NFS server on the host or a flash command has failed. Check your network setting (VPN, firewall,...) to make sure the device can mount NFS server. Debug log saved to /tmp/tmp.1B9cqVBbD3. You can access the target's terminal through "sshpass -p root ssh root@fc00:1:1:0::2"
21:44:35 INFO: Flash Jetson Linux - flash: Cleaning up...
21:44:35 ERROR: Flash Jetson Linux - flash: [exec_command]: /bin/bash -c /home/dcasota/.nvsdkm/replays/scripts/JetPack_6.1_Linux/NV_L4T_FLASH_JETSON_LINUX_COMP.sh; [error]: chown: warning: '.' should be ':': ‘root.root’
21:44:35 INFO: Flash Jetson Linux - flash: [ Component Install Finished with Error ]
21:44:35 INFO: Flash Jetson Linux - flash: [host] [ 15.88 GB used. Disk Avail on Partition /dev/sda1: 10.80 GB ]
21:44:35 INFO: Flash Jetson Linux - flash: [ NV_L4T_FLASH_JETSON_LINUX_COMP Install took 18m29s ]
21:44:35 ERROR: command error code: 11
21:44:35 ERROR: Flash Jetson Linux - flash: command terminated with error
**21:44:35 SUMMARY: Flash Jetson Linux - flash: First Error: Installation failed.**
It may be related that the sd card is 32GB only. There is no pre-check on the sd card size though.
For those who are interesting.
There is a small recess on the back of the devkit between the antenna elements. This is most likely also intended for a jumper storage. Now on this board, there wasn’t a jumper but the case I ordered had two.
Be aware:
Do not use the Okdo case for Jetson Nano 2GB. It’s not compatible.
KKSB case jet dk seems okay, but the waste heat could be a problem.
Shenzhen Guangmaida E-commerce offers a case for ‘Jetson Orin Development Board Aluminum Housing Enhanced Durability and Superior Heat’.
M.2-2230 Crucial P310 2TB SSD and M.2-2280 Samsung 990Pro 4TB work flawlessly beside the sdcard.
