Hello,
We have a custom carrier for Orin Nano, during flashing/Force Recovery Mode the USB Serial Port detects the device. But in normal boot, it is not identifying in any serial port ?
Why is that?
Are you talking about the USB0 port for flashing does not give you device mode after boot up?
Yes, in other modules we would get serial access (via ssh/Putty) if connected to a laptop. But not with Orin Nano.
If this is custom board then you need to review USB device tree to match your board design.
Otherwise the usb device mode enabled or not could just be random behavior.
The USB matches with the device tree, USB 2 is connected to Pin 109(D-) and Pin 111(D+).
How to know if the USB device mode is enabled ?
Sorry to ask this. Do you have some hardware or software engineer on your side who is familiar with usb knowledge?
USB device mode hardware design is not just “USB 2 is connected to Pin 109(D-) and Pin 111(D+).”… This thing is not just this kind of easy…
The pin was mentioned to say that it matches with the device tree.
How to know if the USB device mode is enabled ?
I have asked below how to verify device mode. It would be good if this was answered.
We have tried connecting it to Cameras and other devices, not detecting.
If you hotplug your usb cable to another x86 host PC usb port, then you shall see new dmesg from 3550000 controller coming out and show enabled.
I don’t know what you are trying to test here. Connecting a camera to it is for a USB host mode. Not device mode.
Your reply is kind of lacking of some sense here. USB device mode or host mode both connecting Pin 109(D-) and Pin 111(D+). There are some other hardware mechanism to decide the roles.
Telling the data line is kind of pointless. Of course data line is connected in such way.
Yes, connected to another x86 host PC USB port and checked the dmesg of 3550000
tegra-xudc 3550000.usb:EP 0 (type: ctrl, dir: out) enabled
Need to see multiple enabled/disabled process to make device mode work.
Only one line with enabled means it is not working.
You could compare with NV devkit to understand what I am telling.
Okay got it.
Sent what was received upon your instruction, didn’t said it’s working. Would be great to resolve this without any assumptions.
First one when it’s connected, second when disconnected. No changes
Yes, usb device mode does not work there.
As previously mentioned, you need to modify device tree to match your board design.
Also, if your board design is not able to work in device mode at all, then it may not be possible to configure a correct device tree to enable design mode.
Okay got it. What part needs to be modified in it. Any suggestions or references?
And not sure if it’s related to this issue, the same port gets identified when put in Recovery Mode during flashing procedure
-
Recovery mode does not rely on any knowledge or mechanism on USB design. It is just “I push this button/pin then this thing would temporarily work in usb device mode”. So something working in recovery mode does not mean it would still work in real USB usecase.
-
Please refer to the Design guide document. Basically a USB device mode would only work in micro USB (OTG) or type C design by its nature. For example, you won’t see a usb type A port to be working as USB device mode, it could only work as host mode
- Okay got it.
- Yes, micro USB is used in the custom board
Then please do read the document which I posted here.
The document has sample for micro usb port setting in the DT.
Okay, thanks.
I will add a detail just to add some clarity.
- There is a USB port for serial console (this is what people refer to as serial access, and the port is in device mode because it is a device).
- There is also, when fully booted, software which takes a USB port and emulates hardware: That USB port is pretending to be an Ethernet router, along with mass storage with a README file in it.
- When a Jetson is in recovery mode it becomes a custom USB device which the driver package in the flash software understands.
All of those are device mode with the Jetson becoming a device which can be plugged in to the host PC.
Many pins on a Jetson have multiple possible functions. If some hardware is plug-n-play, then it is easy for software to find and use that hardware. Much of the hardware cannot “self describe”, and the only way find the device is to tell the driver where it is and what it is; this is via device tree.
USB devices are plug-n-play. The controllers which either use or pretend to be a device are not plug-n-play, and if they are not found, it is usually because the device tree (which is firmware) failed to give the information needed.
If your micro-USB port is intended for serial console, and if the wiring layout is an exact match for that part of the carrier board, compared to the reference design, then that part of the device tree should be usable even without edits. If there is any change in layout or pin routing or driver for that micro-USB port, then you likely need edits to the device tree.
Thanks for the explanation.
The micro USB in our design was intented for serial console. Checked with the dev kit schematics, USB3 type C is used in the dev kit hence the addition of MUX and CC controller.
Due to usage of microusb in our board, there is no MUX or CC controller. The wiring layout matches with that of the cariier board. Hence no changes in the device tree was made.
Please find the dts file attached below, modified as per the document, any more changes to be done ?
orin_nx_modified.zip (35.3 KB)