UP Board still enumerating as USB 2.0 after all updates applied

[ioreed]

| Camera Model | D435 | | Firmware Version | 05.09.02.00 | | Operating System & Version | Ubuntu 16.04.16 | | Kernel Version (Linux Only) | 4.13.16 | | Platform | UpBoard | | SDK Version | 2.10.2 |

Issue Description

Using the standard 2GB-16GB 'Up Board' (http://www.up-board.org/up/) and have not figured out how to get it recognized on the USB 3.0 (super speed) bus. It does enumerate on the USB 2.0 (high speed) bus. Any suggestions for where to look in the Linux config to connect the camera to the correct bus are much appreciated.

Tried so far:

1. All of the suggestions in other threads about the Up Board and USB problems: https://github.com/IntelRealSense/librealsense/issues/970 https://github.com/IntelRealSense/librealsense/issues/1198 https://github.com/IntelRealSense/librealsense/issues/1225 https://github.com/IntelRealSense/librealsense/issues/1253 https://github.com/IntelRealSense/librealsense/issues/1306
2. Six different OTG >> USB Type C cables
3. Updating the kernel to 4.13.16
4. Updated Up Board firmware to latest UPC1DM07, 2018.02.20
5. Updated D435 firmware to 05.09.02.00

The things that look broken that have not figured out how to fix:

1. dmesg (see more below) shows errors that look like a UVC problem although we have updated using the latest instructions at /librealsense/doc/distribution_linux.md [ 42.151183] uvcvideo: loading out-of-tree module taints kernel. [ 42.151353] uvcvideo: module verification failed: signature and/or required key missing - tainting kernel
2. lsusb (see more below) shows the Intel D400 camera is enumerated on the USB2.0 bus even though the USB 3.0 bus is working.
3. We think that there is a mismatch between v4l2, uvc driver, and kernel config but have failed to find and fix it.
4. When realsense-viewer is run, we get the same enum error that others have experienced: WARNING [140218186627776] (backend-hid.cpp:1091) Failed to read busnum/devnum. Device Path: /sys/bus/iio/devices/iio:device0

System Information:

Realsense Physical Port: /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/video4linux/video1

$uname -a Linux up-brd-2-16 4.13.16-041316-generic #201711240901 SMP Fri Nov 24 09:02:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 005: ID 0424:2530 Standard Microsystems Corp. Bus 001 Device 004: ID 0424:4603 Standard Microsystems Corp. Bus 001 Device 003: ID 413c:3200 Dell Computer Corp. Mouse Bus 001 Device 002: ID 413c:2111 Dell Computer Corp. Bus 001 Device 006: ID 8086:0ad6 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/7p, 480M | Port 1: Dev 6, If 3, Class=Vendor Specific Class, Driver=, 480M | Port 1: Dev 6, If 1, Class=Video, Driver=uvcvideo, 480M | Port 1: Dev 6, If 2, Class=Video, Driver=uvcvideo, 480M | Port 1: Dev 6, If 0, Class=Video, Driver=uvcvideo, 480M | Port 2: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M | Port 2: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M | Port 3: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M | Port 7: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 4: Dev 5, If 0, Class=Vendor Specific Class, Driver=, 480M

$ dmesg [...clip] [ 41.929775] usb 1-1: new high-speed USB device number 6 using xhci_hcd [ 42.067622] usb 1-1: New USB device found, idVendor=8086, idProduct=0ad6 [ 42.067629] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 42.067632] usb 1-1: Product: Intel(R) RealSense(TM) 430 [ 42.067634] usb 1-1: Manufacturer: Intel(R) RealSense(TM) 430 [ 42.113694] media: Linux media interface: v0.10 [ 42.130957] Linux video capture interface: v2.00 [ 42.151183] uvcvideo: loading out-of-tree module taints kernel. [ 42.151353] uvcvideo: module verification failed: signature and/or required key missing - tainting kernel [ 42.152630] uvcvideo: Found UVC 1.50 device Intel(R) RealSense(TM) 430 (8086:0ad6) [ 42.154263] uvcvideo: Unable to create debugfs 1-6 directory. [ 42.154595] uvcvideo 1-1:1.0: Entity type for entity Intel(R) RealSense(TM) 430 with was not initialized! [ 42.154599] uvcvideo 1-1:1.0: Entity type for entity Processing 2 was not initialized! [ 42.154602] uvcvideo 1-1:1.0: Entity type for entity Intel(R) RealSense(TM) 430 with was not initialized! [ 42.154605] uvcvideo 1-1:1.0: Entity type for entity Camera 1 was not initialized! [ 42.155120] input: Intel(R) RealSense(TM) 430 as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/input/input10 [ 42.155672] usbcore: registered new interface driver uvcvideo [ 42.155674] USB Video Class driver (1.1.1.realsense-4.10.0)

$ modinfo uvcvideo | grep "version:" version: 1.1.1.realsense-4.10.0 srcversion: BC301475460C7DC7D746AFF

$ modinfo uvcvideo | grep ver version: 1.1.1.realsense-4.10.0 description: USB Video Class driver srcversion: BC301475460C7DC7D746AFF vermagic: 4.13.16-041316-generic SMP mod_unload

$ rs-enumerate-devices Device info: Name : Intel RealSense USB2 Serial Number : 745412070309 Firmware Version : 05.09.02.00 Physical Port : /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/video4linux/video1 Debug Op Code : 15 Advanced Mode : YES Product Id : 0AD6

Stream Profiles supported by Stereo Module Supported modes: stream resolution fps format
Infrared 2 480x270 @ 30Hz Y8 Infrared 1 480x270 @ 30Hz Y8 Infrared 1 480x270 @ 15Hz Y8 Infrared 2 480x270 @ 15Hz Y8 Infrared 1 480x270 @ 6Hz Y8 Infrared 2 480x270 @ 6Hz Y8 Infrared 1 424x240 @ 30Hz Y8 Infrared 2 424x240 @ 30Hz Y8 Infrared 1 424x240 @ 15Hz Y8 Infrared 2 424x240 @ 15Hz Y8 Infrared 1 424x240 @ 6Hz Y8 Infrared 2 424x240 @ 6Hz Y8 Depth 480x270 @ 30Hz Z16 Depth 480x270 @ 15Hz Z16 Depth 480x270 @ 6Hz Z16 Depth 424x240 @ 30Hz Z16 Depth 424x240 @ 15Hz Z16 Depth 424x240 @ 6Hz Z16

$ ./realsense-viewer 19/03 12:38:13,637 WARNING [140218186627776] (backend-hid.cpp:1091) Failed to read busnum/devnum. Device Path: /sys/bus/iio/devices/iio:device0 19/03 12:38:13,660 WARNING [140218186627776] (backend-hid.cpp:1091) Failed to read busnum/devnum. Device Path: /sys/bus/iio/devices/iio:device0 19/03 12:38:13,834 WARNING [140217889339136] (sensor.cpp:313) Unregistered Media formats : [ UYVY ]; Supported: [ ]

[RealSense-Customer-Engineering]

[Realsense Customer Engineering Team Comment] There is a hardware issue with the type-C connector on the camera module that may be causing your problem. Can you please confirm that the issue still occurs if you reverse the orientation of the plug. Also try plugging the connector in quickly and/or plugging in the camera side and then the host side last. There is a controller on the board that switches a MUX to route the SS signals from the connector to the ASIC and it is slow to switch; the USB2 signals always connect first and if the ASIC doesn't see the USB3 signals soon enough, it starts in USB2 mode.

Let me know if this makes a difference. There is a hardware revision that should be released soon.

[mgildner]

The OP's issue is remarkable similar to what I am seeing on the intel compute board (https://github.com/IntelRealSense/librealsense/issues/1320). This board also as a ASIC to route SS signals. Can you confirm that this will required a D435 hardware revision? If that is the case, can you offer any solutions that would not require unplugging the cable since I am trying to use the D435 in an embedded application.

[RealSense-Customer-Engineering]

[Realsense Customer Engineering Team Comment] The issue that I described only occurs when physically plugging in the type-C connector. This will be addressed in the next revision of hardware.

If you see this issue on power up with the camera already connected, this would indicate a different issue; is this your case?

[mgildner]

Yes, that is my case. The compute board will still not recognize the D435 (or any usb 3 devices) as superspeed. They work as superspeed on another machine using the same cables (except for the OTG cable).

[ioreed]

We noticed a sensitivity to the Type C connector orientation although it effects if the camera is recognized vs. missing off the bus completely. We are using OTG >> Type C cables and plugging directly into the UP Board. Research into the OTG spec leads us to believe that there is likely line swapping problem with how the OTG header is connected on the host. We ordered an OTG adpater cable directly from UP thinking that it might fix this known issue. We'll report back if it does.

[RealSense-Customer-Engineering]

[Realsense Customer Engineering Team Comment] @mgildner there are two issues here, one is the UVC driver issue and one is the device powering up in USB2. I will be trying to replicate this on the UP board but you can feel free to follow this issue but with regard to the compute board I'll leave this for https://github.com/IntelRealSense/librealsense/issues/1320.

[ioreed]

We received the OTG cable adapter from UP Board today. On a clean Ubuntu 16.04 LTS install and default 4.10 kernel, the D435 connected to the UPBoard cable connected to the OTG port DOES correctly enumerate on the USB 3.0 bus. We upgraded the kernel to 4.13 and confirmed the camera still enumerated on the USB 3.0 bus. However, once we started following the librealsense SDK installation steps (and checked the connection state after each step) the camera fell back to USB 2.0. Don't have time to start over and carefully trace the install but we'll do that in the next few days.

[dvlamp]

Hey @ioreed What kind of cable (brand, specs, length, etc) were you using for this? I have gotten my D415 recognized as a USB 3.0 device on my UP board using the cable configuration in the image below. However I am trying to get a single custom cable made that can do the job. Any updates on your issue since Mar 29?

[RealSense-Customer-Engineering]

[Realsense Customer Engineering Team Comment] Hi @ioreed,

Did you try the latest SDK/Firmware with the qualified cable? still need any help?

[RealSense-Customer-Engineering]

[Realsense Customer Engineering Team Comment] Hi @ioreed,

Do you have any update about cable issue? Note: Our latest firmware 5.9.11 also support USB2 stream.

[RealSense-Customer-Engineering]

[Realsense Customer Engineering Team Comment] HI @ioreed,

Do you have any update result with a new cable and new firmware?

[RealSense-Customer-Engineering]

[Realsense Customer Engineering Team Comment] Is this still an issue? If not, the ticket will be close din 5 days.

[RealSense-Customer-Engineering]

[Realsense Customer Engineering Team Comment] Hi @ioreed,

I will close this first. If you still have any issue, you can reopen it or create another ticket.

[maria-mn]

For those having this problem the solution is using an adapter: OTG USB 3.0 cable - USB 3.0 (f) to Micro-B USB 3.0 (m). Then connect cable USB 3.0 Type A (m) to USB 3.0 Type C (m) and plug it into the camera port.

[milidam]

[Realsense Customer Engineering Team Comment] The issue that I described only occurs when physically plugging in the type-C connector. This will be addressed in the next revision of hardware.

I know that this issue is quite old, but I am facing the same issue with one D455 camera, but not with another one.

One of the difference between the two cameras is what I interprete as the "hardware revision number": the one having the problem is K83122-110, whereas the working one is K83122-111.

Can anyone confirm that this enumeration problem has been solved in that new hardware revision? Or is it a coincidence, and the problem is somewhere else? The PCN does not actually say anything about this issue...

[MartyG-RealSense]

Hi @milidam Have you tried swapping the USB cables of the K83122-110 and K83122-111 revisions to test whether the issue is with the cable?

Have you also tried unplugging the micro-sized end of the cable from the base of the D455, turning it around the other way and re-inserting it? USB-C cables are two-way insertion at the micro-sized end, and a reversal of the micro-sized end can sometimes resolve the problem of the camera only being detected as USB 2.1.

[milidam]

Hi @MartyG-RealSense, Yes, I've tried all combinations of cable possible:

• a USB-A - USB-C cable does not show the problem with any of the camera
• any USB-C - USB-C cable show the problem with one camera, and not with the other The problem is exactly the one described in this thread, and turning around the USB-C connector at the camera end makes it work for the K83122-110 camera. It works whatever the connector orientation for the K83122-111.

When the problem occurs, only the orientation of the connector at the camera side matters, not at the PC side.

I just wanted to know whether the hardware revision number change is the reason explaining that difference, as implied by the previous post

[Realsense Customer Engineering Team Comment] The issue that I described only occurs when physically plugging in the type-C connector. This will be addressed in the next revision of hardware.

in which case things would be clear from a "logistic" point of view

As from 2018, is that next revision of hardware the K83122-111 one?

Both cameras have the same firmware version: the latest 5.16.0.1.

[MartyG-RealSense]

K83122-110 was introduced around mid 2022, several years after the post that you quoted. The key change in it was the swapping of the IMU component to a slightly different one. So the 2018 message likely does not apply to K83122-110.

Once you have found the best orientation for the micro-sized connector that provides USB 3.2 detection then usually you do not need to unplug it from the camera again and it should consistently enumerate as 3.2.

[milidam]

OK. So has that issue actually been addressed since then, or not?

Any idea, then, why there is a different behavior with the two different hardwares?

[MartyG-RealSense]

The details of changes made in hardware revisions are not publicly available except when they are publicly disclosed, such as the IMU component change for K83122-110 and K83122-111 referenced in the data sheet document for the 400 Series cameras. So I do not have further information about this subject to offer, unfortunately. I do apologize.

You could test whether the affected camera can be identified as USB 3.2 if you insert it into the USB port with a quick, firm insertion action, as this can increase the chances of a successful USB3 detection. A slow insertion can result in a USB 2.1 detection.