Trying to check out the new Orin Nano.
Nothing seems to want to work correctly. Etcher and JP511-orin-nano-sd-card-imageflash - no joy, sdkmanager/usb - no joy, hangs
Is there a minimal Linux only flash image that is available. Say Ubuntu 22.04 and nothing else? Then I could pretend to be a Raspi. at least I’d have a running processor.
Is the situation the same for both installation method?
What carrier board and installation medium (SD, USB flash drive, etc.) do you use?
Please connect your device to a host PC and dump the serial connection log when booting up, so we can further analyze the issue.
Dave:
Where might I find such a log?
As I’ve said, I get nothing out of the serial port. Normally, one would simply do a “ls /dev/tty*” and it would return with a new connection. In this case /dev/ttyACM0. Then I would connect with putty to /dev/ttyACM0 and I could easily collect a log. But there is no activity from that connection.
Looks to me like, at the very least, the serial port is bad. That would also explain why the sdkmanager reported errors and basically lost it’s mind.
Regards,
Chuck Glasser
What does ls /dev/tty* show on your host?
Assuming you are using the Orin Nano Devkit, do you correctly use the micro USB port? USB-A ports won’t give you anything.
Also, normally; you’d need to run monitoring tools before powering up your device.
/dev/ttyACM0 Seems to work fine for ESP32, Arduinos, RasPi, FPGA of all sorts and vendors, 3 Jetson nanos, and more embedded machinery than you can possibly imagine or afford. It’s not me but my bad luck to get a crappy Orin, Hey it happens.
Hi,
Sorry, If it is jetson Orin Nano/NX, then you need to use usb-ttl cable to dump the log.
ttyACM0 will only appear in your micro usb port “when this device boots into kernel”.
If your sitatuion is you totally cannot boot, most likely you cannot boot into kernel, so ttyACM0 is not going to show up either.
Also, I don’t know if you ever heard of sdkmanager before.
If your jetson device cannot boot and sdcard image does not work, then you can do total reflash with sdkmanager from another x86 host.
SDcard image is not a real “reflash” to jetson.
[WayneWWW] WayneWWW https://forums.developer.nvidia.com/u/waynewww
Moderator
April 27Hi,
Sorry, If it is jetson Orin Nano/NX, then you need to use usb-ttl
cable to dump the log.
Take a look at the schematics… All usb connectors are fully USB
compliant. In fact the USB-C standard is very clear about the misuse of
the connector. doing as you suggest is a very big NO-NO. The product
design guide DG-10931-001_v0.99 is also very clear about usb
connectivity. So, you are incorrect about usb-ttl!
[WayneWWW] WayneWWW https://forums.developer.nvidia.com/u/waynewww
Moderator
April 27Also, I don’t know if you ever heard of sdkmanager before.
If your jetson device cannot boot and sdcard image does not work, then
you can do total reflash with sdkmanager from another x86 host.SDcard image is not a real “reflash” to jetson.
As I have explained before, sdkmanager did not work as it depends upon
the USB debug port to gain access to the device memory.
I think it’s time you pass this problem up the chain to someone with
more experience.
Regards,
c.glasser
Chief Technical Officer
Cybin Labs
Hi,
I don’t know what you are talking about… This is kind of basic issue we are handling every day.
You need to put the board into recovery mode so that sdkmanager can detect and flash the board.
If you don’t put the board into recovery mode, then you cannot flash it.
If you hit other problem, then you need to at least share other info (e.g. log from sdkmanager) so that we can check your issue…
Perhaps it would be helpful to know that I am a very senior level EE with hardware flying in space.
Read what I tell you carefully.
Regards,
c glasser
I have put the board in recovery mode, many, many times.
Apparently the sdkmanager keeps some sort of history as the second, third and forth time I went through the recovery operations it would hang, i.e. lock up and become unresponsive. So I cycled power on my 18.04 Ubuntu box. Don’t you just love Ubuntu. I’ve tried them all going back to Slackware 0.95 somewhere around the year 1993, yikes 30 years ago. Anyway, after rebooting the host machine the sdkmanager seemed to work better BUT, as you know there are two parts the host and the target. The host side was happily marching along adding files somewhere. The target section had big red comments next to every file that it tried to load. As I recall something like !Failed in red. As the notes suggest using Edison connectors is the easiest way to short pins 9 & 10. No wonder the sdkmanager dies. It expects to see a working USB port and has no method of dealing with broken interfaces. Incidently, if one does not place the board in recovery mode the sdkmanager behavior will be different and you’ll never get to step 3.
It’s not me, it’s the broken serial port that is the issue.
Regards,
c. glasser
Where do I find the sdkmanager log?
The Jetson Orin Nano Developer Kit Carrier SP-11324-001_v1.0 clearly states in section 2.1 "The carrier board supports five USB connectors. One is a USB 3.2 Type C connector (J5) supporting host, device, and USB Recovery. "
Section 1.2 point to another debug port on the button header. While Table 3-4 refers to pins 3 & 4 of the button header as a debug uart. A uart is not the same as a USB in pin 10 definition.
Seems to me that clearly J5 is to be used with the sdkmanager and NOT some funky usb/ttl uart on J14.
Regards,
cg
Just a clarification… looks like we didn’t describe this clearly so you didn’t get it.
Sdkmanager is use the J5 to flash the board.
The uart pin + usb ttl cable here is to dump serial log.
Dumping serial log and sdkamanger are two separate things . Not matter to each other.
If you want to check the serial console log, use the uart pin.
If you want to flash the board, use the type C connector…
Hope that clarify the problem here…
WayneWWW:
I’m not sure where to go from here. I had to clean off a bench to make room for the Orin and having done so reconnected everything and WHAM everything works as expected. So, attached is the log file, even though it’s no longer needed.
Thanks for making me clean up my bench! I feel much better now.
Regards,
Chuck
orin.log (94.5 KB)
Hi,
This log indicates your device at least can boot into login prompt.
16.389267] nvidia: loading out-of-tree module taints kernel.
[ 17.498862] using random self ethernet address
[ 17.506144] using random host ethernet address
[ 18.541976] using random self ethernet address
[ 18.546684] using random host ethernet address
Ubuntu 20.04.5 LTS wizard1 ttyTCU0
wizard1 login:
If this user “wizard1” is what you expect, then the device is still working.
And your mouse is still detected. Optical mouse from Logitech. So usb is still working.
[ 8.791112] usb 1-2.4: new low-speed USB device number 5 using tegra-xusb
[ 8.908830] usb 1-2.4: New USB device found, idVendor=046d, idProduct=c05a, bcdDevice=54.00
[ 8.917426] usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 8.924941] usb 1-2.4: Product: USB Optical Mouse
[ 8.929769] usb 1-2.4: Manufacturer: Logitech
Is there still any problem under this situation? Or we are good now?
Thanks for your reply. Yes the interface is usable. I’m still having network issues but I suspect the problem is the network and not the Orin.
I’ve absolutely no explanation regarding the previous strange boot behavior. The debug terminal is very handy! Especially as it makes practical remote operations and monitoring.
In regards to the network . I can ping to the device at 192.168.55.1 and it will respond to the host. However, if I try to ping the host at 192.168.0.104 from the debug terminal or from a shell on the Orin home screen there is no response. Any suggestion on what rock needs to be turned over?
Thanks for the help. Seems like a great little processor.
Chuck
Hi,
The 192.168.55.1 is based on the type C usb port between your host and jetson. It is a network based on usb connection. So when the cable from your type C port is removed, this interface will not work.
Also, please check what IP is from this interface. This interface goes through only the usb.
You cannot use the ethernet IP on your host because Jetson side won’t know it.
I mean if this IP “192.168.0.140” is not based on usb connection between type C and your host, then device cannot ping it.
ifconfig command on host can tell more.