ZED camera not recognized on USB 3.0 port after the basics manipulations (Solved)

Autonomous Machines Jetson & Embedded Systems Jetson TK1
1

Hi,

Although I enabled the USB 3.0 port via extlinux.conf and disabled the autosuspend, my ZED camera is still recognized as being on a USB 2.0 port. When I type lsusb -t I’ve this :

/:  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/2p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/6p, 480M
    |__ Port 3: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 3: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M

I took a look at the jetson-tk1_extlinux.conf.usb file by curiosity and replaced the usb_port_owner_info=0 by usb_port_owner_info=2. The lsusb command displayed me the same thing, so I put the parameter at 0.

The funny thing appeared when I set usb_port_owner_info at 0 and reboot. The parameter stayed at 2 even after 2 other attempts.
Thereafter, I tried to add another usb_port_owner_info=0 before the initial one.
After reboot the both were at 2 even if I swaped values amongst themselves.

After these manipulations, lsusb give me the same message.

Now the only solution that I see is compile another kernel with USB 3.0 activated.

So, Does anyone have another solution ?

Thank you in advance for your reply.

P.S : I have a Jetson TK1 with L4T version 21.4.0.

2

Which connector is the camera on?

The lsusb you show says USB3 is active and functioning…the video is not on that connector. The output “Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/2p, 5000M” implies this root HUB is running USB3…and thus USB3 driver was successfully added. Unfortunately, this is not the connector your USB3 camera is attached to.

Note that the micro-A/B connector is hard wired to only support USB2. The USB3 is the full-sized “A” connector, and the only connector supporting those speeds. It looks like a simple connector switch would do the job.

3

Hi,

Maybe I should specify that the ZED camera is directly connected to the full-size type-A USB 3.0 of the TK1 and nothing else is on the other USB.

If I well understood, I should have something like that :

/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=tegra-ehci/1p, 480M
[b]/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/2p, 5000M
    |__ Port X: Dev X, If 0, Class=Video, Driver=uvcvideo, 5000M
    |__ Port X: Dev X, If 1, Class=Video, Driver=uvcvideo, 5000M[/b]
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/6p, 480M

I also tried ZED SDK samples and software that ask me to verify whether the camera is on a USB 3.0 connector with the HD720 resolution parameter (without surprise).

4

All of the entries with “5000M” are running at USB3 speeds. The “CLass=root_bub” applies to a single USB connector on the Jetson itself, and so the one with “5000M” is indeed USB3. This most recent “lsusb -t” is exactly what you’re looking for.

Did you change connections between that “lsusb -t” and the prior listing? I ask because previously the uvcvideo driver applies to Bus 1 instead of Bus 2. This most recent “lsusb -t” shows the device is running at USB3 speed.

5

Hi,

The “lsusb -t” showed in my last post was just to confirm what I should have in the best case. That’s why I put “X” instead of port and device numbers.

So, in summary, my camera is attached on the type-A full size USB socket but on the software side the camera is on a “virtual” USB 2.0 port. Moreover, my USB drivers are functionals.

Is a kernel option may be missing or a path to indicate a link between the USB 3.0 and the driver?

EDIT: I received a TX1 and I have the same problem (camera “virtually” attached to the USB 2.0) when the ZED is directly connected on the full size type-A USB. Tomorrow I will try on a computer with Ubuntu 14.04 with USB 3.0 ports and I’ll keep you up to date.

6

I’m looking closer at the “stuck/ignored” usb_port_owner_info bug you mentioned in the original post where kernel command line is ignored. Is your current L4T version R21.4? See:

head -n 1 /etc/nv_tegra_release

Just to verify here is my output from “cat /proc/cmdline” after setting “usb_port_owner_info=0”…I’m expecting something like this, but reflecting my usb_port_owner_info setting (take note of usb_port_owner_info which is incorrectly at 2):

root@tk1:/boot/extlinux# cat /proc/cmdline
console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 <b>usb_port_owner_info=2</b> lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt

This verifies on R21.4 that if I change usb_port_owner_info in extlinux.conf that the value is ignored. cmdline should follow this setting, but it does not…it always shows “2”, even if I set it to “0”. This wouldn’t be bad if the port is hard coded as USB3, but there is another anomaly.

Quite some time back, starting in the days of first release of JTK1 (L4T R19.2), there was an issue of display of port speeds not necessarily working correctly, although speed tests showed the port really was at USB3 speeds. “lsusb -t” claimed a Kinect camera was running at USB2, yet testing revealed that the performance could not have possibly been as high as it was without USB3 speeds. I’m thinking that half of the issue may be the old problem of “lsusb -t” not correctly showing actual speed. If this is the case, then it needs correcting, but would not be a big issue (other than the false alarm of hunting for a USB3 setting when already in USB3 mode). The other half of the problem where extlinux.conf usb_port_owner_info is being ignored is probably a more serious issue, but again, it may be that since this shows as “=2” at all times perhaps the port really is in USB3 mode…we just can’t tell.

See:
https://devtalk.nvidia.com/default/topic/811034/jetson-tk1/kinect-2-libfreenect2-hw-acceleration-full-performance-obtained

Since I do not have anything capable of testing full USB3 speed (I only have a USB3 HUB and no USB3 device capable of running USB3 speeds), can you give any observations about performance of your ZED camera as to whether it might actually be in USB3 mode? This answer will influence how this is debugged.

7

Hi,

ubuntu@tegra-ubuntu:~$ head -n 1 /etc/nv_tegra_release
# R21 (release), REVISION: 4.0, GCID: 5650832, BOARD: ardbeg, EABI: hard, DATE: Thu Jun 25 22:38:59 UTC 2015

This is the version given by the Jetpack 1.2.

About the “/proc/cmdline”, is this file is rewrite at each boot?
Is it just a human readable file log of the kernel arguments?

Neither have I any kind of USB 3.0 devices.

I tried the camera on Windows 10 on a “ASUS Transformer Book Trio TX201LA” on its USB 3.0 port. There were no problems with the Windows basic camera software which has detected the ZED directly in full resolution without glitch.

I don’t know how but I temporarily succeeded to have that (as usual ZED on full-size A and HUB+keyboard+mouse on half size A/B):

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

However, when I tried ZED SDK tools (ZED explorer and Depth map) with the 720 resolution I had I/O error and firmware no recognizable.

EDIT:
I made other tests this afternoon.

  • With a computer on Linux Ubuntu 14.04 and CentOS, my camera was also attached to a "virtual" USB 2.0 although I tested the 3 USB 3.0 computer ports;
  • I tried again to add a second "usb_port_owner_info" and with the both at 0. After reboot there were set at 2 and /proc/cmdline indicated that the first was at 2, the second at 0.
  • I also set "usb_port_owner_info" at 1 then 3 to check the behavior and it results any differences between extlinux.conf and cmdline

Tomorrow I’ll try to find an USB 3.0 device to see.

Otherwise I’m looking for re-installing the same version of Jetpack than here :
http://jetsonhacks.com/2016/02/03/stereolabs-zed-camera/#comment-4945
or re-flash only the kernel and/or u-boot.

8

The file “/proc/cmdline” is not a real file. “/proc” is a pseudo file system which exists only in RAM, and is a real-time reflection of kernel drivers. In some cases those files can even be written to and directly/instantly modify the kernel (depends on the driver). If “/proc/cmdline” does not show a command line argument change, then it means the parameter was hard-coded within the kernel to not allow the change.

Note that regardless of whether the port runs at USB2 speeds or USB3 speeds that the camera should be detected…the difference would simply be one of speed in most cases (more about this down below).

What I find interesting is that a hard-coded cmdline could account for why “lsusb -t” would incorrectly report root HUB speed to the wrong place, while the port is actually USB3 speed. Perhaps the hard-coded cmdline was done in the wrong place such that “lsusb -t” reads from a place earlier in the call stack prior to that hard-coding.

Regarding some of the differences between USB2 and USB3 which might matter, there are certain blocks of USB parameters which are only read when the port is USB3…under USB2 the backwards-compatible parameters should be able to run the device at USB2 speeds. It is possible though that the camera did not include all functionality within the backwards-compatible USB2 parameters, and that those functions would not be accessible without USB3. Most device manufacturers would try to avoid that, but if it is known the device cannot function in a useful way under USB2 the manufacturer may not have bothered with such compatibility. Having the cmdline hard-coded and incorrect in some way could conceivably cause failure to try to read those USB3 parameters as well…if some software knows the device is USB3 but other parts of software do not know this I imagine strange things could happen.

Question: On the setup where the device showed USB under Ubuntu 14.04 and CentOS were these x86_64 systems? Can we verify which of those were shown as USB2 or as USB3? Was there a USB2 error on a non-Jetson where a USB3 capable port showed USB2?

9

Hi,

I tried with a USB 3.0 storage and the device were well attached to the bus 02 as below.

ubuntu@tegra-ubuntu:~$ lsusb 
Bus 002 Device 002: ID 0951:1666 Kingston Technology DataTraveler G4
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ubuntu@tegra-ubuntu:~$ 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/2p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/6p, 480M

I’m thinking about the ZED camera firmware that we can update by the ZED Explorer tool. My internship supervisor said me that it’s one of the first model of the ZED. So, I’ll contact Stereolabs in order to have the binary firmware file for updating.

About

The computer is a x86_64 system.

10

The USB3 mass storage shows up correctly. It may be a one-time strange issue for the camera to show up on the wrong USB port via lsusb, but the hard-coded usb_port_owner_info which ignores extlinux.conf setting is still there and possibly related to the problems. I suspect new firmware for your camera would be beneficial, but it also looks like there is more to the story at the Jetson side of things.

11

Hi,

The firmware update had no effect (CentOS, TK1 & TX1), I contacted Stereolabs directly, so wait and see.

Is there a way to mark this thread as a problem in which Nvidia engineers should investigate?

12

Hi NotANumber,

Sorry for the late response.

Have you received the response from Stereolabs to resolve the ZED camera issue on both TK1 and TX1?

Thanks

13

Hi,

Yes I returned the old camera and Stereolabs gave us another one which work very well on the TX1 and Ubuntu 14.04.
So, the old camera was the problem (I think the USB 3.0 wire/port was damaged).
You may mark the thread as solved.

EDIT: I haven’t continued to investigate about the kernel parameter problem.