USB3 to GbE interface on custom board

Autonomous Machines Jetson & Embedded Systems Jetson TX2
#1

Hi All,

We made a custom board for both TX1 and TX2, the same one.

Using TX1 on our custom board – second GbE works

We are using the following two signals in order to convert USB3 to GBE:
USB_SS0 (USB 3.0 Port #0) and USB2 (USB 2.0, Port 2)

This works perfectly for us, we see eth0 (us SoM internal Gbe) and eth1 (as our additional GbE). By the way, we are using the same Realtek controller us used on TX1.
Below is kernel print for correct Realtek initialization of our second GbE:

[ 1.689641] usb 2-1: new SuperSpeed USB device number 2 using tegra-xhci
[ 1.710804] usb 2-1: New USB device found, idVendor=0955, idProduct=09ff
[ 1.710810] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 1.710815] usb 2-1: Product: USB 10/100/1000 LAN
[ 1.710818] usb 2-1: Manufacturer: Nvidia
[ 1.710822] usb 2-1: SerialNumber: 000001000000
[ 1.830362] usb 2-2: new SuperSpeed USB device number 3 using tegra-xhci
[ 1.850931] usb 2-2: New USB device found, idVendor=0bda, idProduct=8153
[ 1.850937] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 1.850942] usb 2-2: Product: USB 10/100/1000 LAN
[ 1.850945] usb 2-2: Manufacturer: Realtek
[ 1.850950] usb 2-2: SerialNumber: 000000000000
……
……
[ 1.222903] usbcore: registered new interface driver r8152
……
……
[ 2.040356] r8152 2-1:1.0 eth0: v2.08.0 (2016/12/09)
[ 2.040361] r8152 2-1:1.0 eth0: This product is covered by one or more of the following patents:
US6,570,884, US6,115,776, and US6,327,625.

[ 2.109859] usb 2-2: reset SuperSpeed USB device number 3 using tegra-xhci
[ 2.140326] r8152 2-2:1.0 (unregistered net_device): Invalid ether addr 00:00:00:00:00:00 // Author: this is fine since MAC was not burn
….
….
[ 2.189764] r8152 2-2:1.0 (unregistered net_device): Random ether addr 12:a9:da:09:c6:7a
[ 2.190348] r8152 2-2:1.0 eth1: v2.08.0 (2016/12/09)
[ 2.190351] r8152 2-2:1.0 eth1: This product is covered by one or more of the following patents:
US6,570,884, US6,115,776, and US6,327,625.

Using TX2 on our custom board – second GbE not works

Our custom board not changed. We are still using the same signals:
USB_SS0 (USB 3.0 Port #0) and USB2 (USB 2.0, Port 2)

But during the boot, now we are getting the following errors:

[ 14.392569] usb 2-1: new SuperSpeed USB device number 2 using xhci-tegra
[ 14.413059] usb 2-1: New USB device found, idVendor=0bda, idProduct=8153
[ 14.413062] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 14.413064] usb 2-1: Product: USB 10/100/1000 LAN
[ 14.413066] usb 2-1: Manufacturer: Realtek
[ 14.413068] usb 2-1: SerialNumber: 000000000000
[ 14.413547] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[ 14.423880] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[ 14.424423] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
….
….
[ 14.544914] usb 2-1: reset SuperSpeed USB device number 2 using xhci-tegra
[ 14.565347] r8152 2-1:1.0 (unnamed net_device) (uninitialized): Unknown version 0x5c30
[ 14.565349] r8152 2-1:1.0 (unnamed net_device) (uninitialized): Unknown Device

Notes

We have USB3 to GbE external adaptor with the same Realtek controller we are using on our custom board. This adaptor is working on Jetson TX2 evaluation board.
The same external adaptor is working on our custom board with TX1 and TX2.
Our internal Realtek controller, works only with TX1 and not with TX2.
The only difference between our design and Jetson evaluation board is that we are using USB2 (USB 2.0, Port 2) and Jetson evaluation board using USB2 (USB 2.0, Port 1).
But again, using TX1 SoM on our board, internal Realtek controller works.

Please help.

#2

How does “lsusb -t” show for both the TX1 and TX2 cases?

#3

Hi,

Thank you for the fast response.

TX2

root@tegra-ubuntu:/home/nvidia# lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/3p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 480M
|__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M

TX1

lsusb -t
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=tegra-ehci/1p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
|__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/5p, 480M
|__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 3: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 2: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 2: Dev 6, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M

#4

This stands out:

Class=Vendor Specific Class, Driver=r8152
# versus:
Class=Vendor Specific Class, Driver=,

USB itself appears to see the device without issue. Once the device is seen hot plug announces this and a driver must claim ownership…in this case a driver specific to that hardware, and not a generic class. The driver is the r8152. The implication is that the r8152 driver needs to be installed on the system where it doesn’t work.

On each system, what do you see from:

zcat /proc/config.gz | grep 8152

If “=y”, then this is part of the base kernel. If “=m”, then this was built as a module. If not enabled, then this will be a problem. If this driver is available, and still not assigned, then there may be an issue with how USB announced the device (which in turn would be part of the USB add-on needing programming).

#5

You can see from my first post that driver is actually loaded, the prints below are from r8152 driver.
We tried both, compiled as monolithic (y) and as a loadable module (m).

[ 14.392569] usb 2-1: new SuperSpeed USB device number 2 using xhci-tegra
[ 14.413059] usb 2-1: New USB device found, idVendor=0bda, idProduct=8153
[ 14.413062] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 14.413064] usb 2-1: Product: USB 10/100/1000 LAN
[ 14.413066] usb 2-1: Manufacturer: Realtek
[ 14.413068] usb 2-1: SerialNumber: 000000000000
[ 14.413547] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[ 14.423880] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[ 14.424423] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
….
….
[ 14.544914] usb 2-1: reset SuperSpeed USB device number 2 using xhci-tegra
[b][ 14.565347] r8152 2-1:1.0 (unnamed net_device) (uninitialized): Unknown version 0x5c30
[ 14.565349] r8152 2-1:1.0 (unnamed net_device) (uninitialized): Unknown Device
[/b]
#6

There are differences between a TX1 module and a TX2 module with regard to how their integrated ethernet is wired, but from what I can see your question is entirely about a Realtek chip you have put on a custom carrier board, and since this is connected via USB, the two should behave the same using the same kernel and drivers. When a TX1 is placed on the carrier it works, but when a TX2 is placed on the carrier it seems to strip out the device and product IDs which would be used to know to bind the 8192 driver to the chip, and thus the driver won’t work even if you know it should simply because the kernel does not make that association:

[ 14.544914] usb 2-1: reset SuperSpeed USB device number 2 using xhci-tegra
[ 14.565347] r8152 2-1:1.0 (unnamed net_device) (uninitialized): Unknown version 0x5c30
[ 14.565349] r8152 2-1:1.0 (unnamed net_device) (uninitialized): Unknown Device

Since the USB port sees the device, but behaves differently for a TX1 versus TX2, someone from NVIDIA will have to look to see if it is something internal to the module which might make the same custom carrier board work for the TX1 but fail for the TX2. I am at a loss as to why the chip would get a different ID depending on which module is connected.

#7

Hi Berkutok,
What is your config # per https://developer.nvidia.com/embedded/dlc/jetson-tx2-oem-product-designguide ?

And which USB_SS# connects to the Ethernet chip?

#8

Thank you Linuxdev for trying to help.

Hi Dane,

We are using default config (2), the same as on Jetson TX2 evaluation board.
We are using USB_SS0 to connect it to Ethernet chip.

Interesting note I found in “Jetson_TX1_TX2_Interface_Comparison_and_Migration_v1.0.pdf”.

“Table 3. Jetson TX1 USB 3.0, PCIe, and SATA Lane Mapping Configurations” - Looking on this table, I see that USB_SS0 is actually connected to internal TX1 SoM Ethernet and on TX1 USB_SS0 pins, we actually have USB_SS1 signals.

“Table 4. Jetson TX2 USB 3.0, PCIe, and SATA Lane Mapping Configurations” - Tells us that on TX1 USB_SS0 pins we have USB_SS0.

So, actually USB_SS signals we are using on our custom board in both cases are different:

TX1:

USB_SS1 (on pins of USB_SS0) and USB2 (USB 2.0, Port 2)

TX2:

USB_SS0 (on pins of USB_SS0) and USB2 (USB 2.0, Port 2)

I want to mention again, that on Jetson TX1/TX2 evaluation board, USB1 (USB 2.0, Port 1) is used as a “pair” for USB_SS port and we are using USB2 (USB 2.0, Port 2).

Maybe a problem is here? Maybe we can’t use USB2 (USB 2.0, Port 2) as a “pair” with USB_SS0?

#9

Hi All,

We did a stitch on our custom board and now we are using the same ports like on Jetson TX2 evaluation board:
USB_SS0 (on pins of USB_SS0) and USB2 (USB 2.0, Port 2)
Results are the same:
TX1 - works
TX2 - doesn’t recognized eth1

[   14.820997] usb 2-1: reset SuperSpeed USB device number 2 using xhci-tegra
[   14.837439] r8152 2-1:1.0 (unnamed net_device) (uninitialized): Unknown version 0x5c30
[   14.837442] r8152 2-1:1.0 (unnamed net_device) (uninitialized): Unknown Device
#10

Hi All,

We found a problem.
We add the missing case to TX1 driver and forgot about it. After adding it to TX2 Realtek driver, it works.

Thank you for the help.

#11

I am curious to know if it was the USB ID matching the Realtek driver to the hardware which was missing?

#12

Yes,

[   14.837439] r8152 2-1:1.0 (unnamed net_device) (uninitialized): Unknown version 0x5c30

The following link grab my attention that we already did it once, some time ago:

https://patchwork.kernel.org/patch/9708645/

The patch a a little bit different here but the idea is the same.

#13