Can you provide instructions on how to restore the IP over USB using static IP 192.168.55.1 .
This feature worked on all previous JP releases
This thing is still there.
It could be your usb device mode does not work so this interface is gone.
I guess you are using a custom board?
I get USB0 with static address 192.168.55.100 on all carriers we use when I flash with JP5.
I do not get any USB network connection for JP6.
I do get USB network connection using IPV6 address which is active during the flashing procedure, and then disappears after flashing is complete.
So its JP6 related somehow
May need to clarify if all of you are using NV devkit or custom board.
As what I am doing now, I don’t see such issue on NV devkit.
The most of cases I saw here is custom board owner/vendor does not really configure device tree for usb device mode correctly. In rel-35, there are some error tolerance that allows such behavior.
But in rel-36, it is more strict that device tree must be correct.
Thus, I wouldn’t say this is a bug yet. You have to use correct configuration first but not always rely on some error tolerance in the driver.
Thus, clarify if this is only with custom board or even NV devkit can see such behavior.
I have this problem on a Leetop dev kit carrier board 900-44386-0000, Rev 2.2, 2023-07-26. This is based on Nvidia reference design for the dev kit.
Can you show me a photo of USB0 working on your Dev Kit carrier board with Orin NX running JP6. And let me know model number for your carrier board so I can test that here.
Hi,
There is nothing called “Leetop devkit”. If this is a carrier board made from Leetop, then it is a custom board. Every carrier board made by non-NV vendor is a custom board. No matter what they tell you, treat them as custom board.
And only NV official carrier board would use the term “devkit”.
The official Orin Nano/NX carrier board is the Orin Nano devkit. p3768.
l4tbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.55.1 netmask 255.255.255.0 broadcast 192.168.55.255
inet6 fe80::3cc7:e7ff:fe79:f387 prefixlen 64 scopeid 0x20<link>
inet6 fe80::1 prefixlen 128 scopeid 0x20<link>
ether 3e:c7:e7:79:f3:87 txqueuelen 1000 (Ethernet)
RX packets 3085 bytes 669283 (669.2 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2442 bytes 571023 (571.0 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1591 bytes 196412 (196.4 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1591 bytes 196412 (196.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::5478:e9ff:fe5f:b185 prefixlen 64 scopeid 0x20<link>
ether 56:78:e9:5f:b1:85 txqueuelen 1000 (Ethernet)
RX packets 771 bytes 111288 (111.2 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 787 bytes 182518 (182.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
usb1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::5478:e9ff:fe5f:b187 prefixlen 64 scopeid 0x20<link>
ether 56:78:e9:5f:b1:87 txqueuelen 1000 (Ethernet)
RX packets 2330 bytes 560358 (560.3 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2634 bytes 727728 (727.7 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether b4:8c:9d:1c:48:31 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@tegra-ubuntu:/home/nvidia# cat /etc/nv_tegra_release
# R36 (release), REVISION: 3.0, GCID: 36191598, BOARD: generic, EABI: aarch64, DATE: Mon May 6 17:34:21 UTC 2024
# KERNEL_VARIANT: oot
Thanks for the screenshot.
On my setup I see l4tbr0 on JP5.x and not on JP6.x, so my issue is actually l4tbr0 that is not being created on JP6.
I understand what you are saying about dev kit vs custom, and I see l4tbr0 on all custom boards for JP5.x and not for JP6.x
So from your comments, are you saying that JP6 has additional requirements that are not met by these custom boards.
What changes can I make in rel-36 image to re-enable l4tbr0
Hi,
When you connect the micro usb or type C port between your jetson and host pc, could you share the dmesg from your jetson?
I get no dmesg messages when connecting or disconnecting microUSB for JP6 system.
To check, I do get connect and disconnect messages for any other USB device I connect.
So it looks like microUSB (OTG) is not active
Do you want me to send full dmesg file
It is okay. No need to do that.
Are you the board vendor that made the board you are using?
We are vendors for a custom board and we also use others like Leetop. We are system integrators and we also design at pcb level as required. So we can make changes to our custom board if required.
You need to confirm
-
If your usb design supports otg by its nature. For example, if you design a type A usb port, then it won’t work in otg mode.
-
You have to make sure your device tree is configured to match your carrier board with the device tree guidance here.
Jetson AGX Orin Platform Adaptation and Bring-Up — NVIDIA Jetson Linux Developer Guide 1 documentation
The reason to check whether you are the vendor is because if you are the end user, you may not know the schematic so may not be able to write the correct device tree.
The ID pin is not connected on these carriers so not operating as an OTG port. It is a host port.
Vbus-detect is connected to SOM pin 87, so connection is detected ok.
Can you tell me what has changed in JP6, or what pinmux settings need changing, since OTG pinmux settings dont appear to be related to this problem if it previously worked in host mode.
It is not “what change on JP6”. Your concept here is also wrong.
The most of cases I saw here is users/vendors didn’t know that they have to modify the device tree correctly to match their board. Most of users relying on some error tolerance in the driver but now the driver does not have such thing anymore so you must use correct device tree…
The document is already posted in previous comment.
And some reply to your comment here.
The ID pin is not connected on these carriers so not operating as an OTG port. It is a host port.
Vbus-detect is connected to SOM pin 87, so connection is detected ok.
No, no ID pin means this board may only work in device mode. Not host mode.
Can you tell me what has changed in JP6, or what pinmux settings need changing, since OTG pinmux settings dont appear to be related to this problem if it previously worked in host mode.
It is just as I said. When you migrate/upgrade to a new release, you have to make sure the device tree is correct. If you didn’t do this thing before, then whether your usb port worked or not before does not matter. It is just luck/coincidence. The default Orin Nano devkit is relying on fusb301 controller for type C usb.
If you are not using type C usb + fusb301 combinatin, then your port won’t work with default device tree.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.