Tried this several times. If I have my C920 cam plugged into usb port the machine halts during the boot process. No error messages the screen is dark.
Funny but I can plug that camera into a non powered usb-c hub and it works fine.
I can confirm the C920 issue. A little more info: Here’s the log of the C920 being enumerated when connected to a USB hub:
[ 17.744084] uvcvideo: Found UVC 1.00 device HD Pro Webcam C920 (046d:082d)
[ 17.745034] uvcvideo 1-4.3.2:1.0: Entity type for entity Processing 3 was not initialized!
[ 17.745038] uvcvideo 1-4.3.2:1.0: Entity type for entity Extension 6 was not initialized!
[ 17.745040] uvcvideo 1-4.3.2:1.0: Entity type for entity Extension 12 was not initialized!
[ 17.745042] uvcvideo 1-4.3.2:1.0: Entity type for entity Camera 1 was not initialized!
[ 17.745044] uvcvideo 1-4.3.2:1.0: Entity type for entity Extension 8 was not initialized!
[ 17.745046] uvcvideo 1-4.3.2:1.0: Entity type for entity Extension 9 was not initialized!
[ 17.745048] uvcvideo 1-4.3.2:1.0: Entity type for entity Extension 10 was not initialized!
[ 17.745050] uvcvideo 1-4.3.2:1.0: Entity type for entity Extension 11 was not initialized!
[ 17.745304] input: HD Pro Webcam C920 as /devices/3610000.xhci/usb1/1-4/1-4.3/1-4.3.2/1-4.3.2:1.0/input/input7
[ 17.745506] usbcore: registered new interface driver uvcvideo
[ 17.745507] USB Video Class driver (1.1.1)
Just to be clear, this is a completely unfair statement. This release is clearly marked as non-production, pre-release, and developers can reasonably expect to encounter issues. Developers can contribute by reporting issues when they are found.
If you are looking for a more stable release, you should wait until the production software is released. For many of the developers working on next generation products, this early access is invaluable to get a head start on their development.
In the first place I just reported an issue I found. No way to get it fixed if noone tells nvidia there is a problem. No way they can have every device someone might attempt to use with the machine. Sounded fishy to me that a powered hub would be required to use a single device I’ve used on a TK1 TX1 and TX2 so I plugged into a non-powered hub I have that uses the usb-c input instead. It worked so I posted that. More information for the folks at nvidia to use to figure out what is going on. Geez.
So do you want a prize or something? By the way the ZED camera works just fine on that port without a powered hub. Actually I encountered it on the first day I had the computer the 15th. But didn’t get around to posting it till today. Too busy getting the rest of my software built on the new machine. Which by the way is working perfectly after a couple of fixes which had nothing to do with the Xavier. They were version issues with ROS melodic and Ubuntu 18.04. As far as I’m concerned its the best machine nvidia has ever released. Glad I have one.
Is there a bug tracker for this kind of thing?
If I encountered this issue I simply would have posted the issue on this forum like I did with the “Sorry, Ubuntu 18.04 has experienced an internal error” issue.
It’s as if the forum is being used to report bugs, and to track the severity of them. To see if it’s a real bug, or if it’s just user error.
It’s easy to miss a bug that’s been reported. This is a perfect example as I didn’t see it. It’s under a thread about monitor resolution as that was the original problem before it was traced to this.
This problem in particular is a bit odd as the USB-C ports work just fine with the camera plugged in directly. The only port that has this issue is the USB+SATA one, and only if the camera is plugged in directly. At least that’s the result of my quick experimentation.
I can verify the error on a C920. There is another thread which looks to be the same issue using a C922…unfortunately I don’t see which thread that was.
Found the other thread:
https://devtalk.nvidia.com/default/topic/1042023/jetson-agx-xavier/default-boot-resolution-/
Here is the OOPS:
[0003.611] I> USB 2.0 port 4 new high-speed USB device detected
[0003.613] W> WARNING: event and command not matching, cmd_trb_ptr = 0x96b13f00, cmd_ring.dma = 0x96b13f40
[0003.613] E> slot id is 1
[0003.615] W> WARNING: event and command not matching, cmd_trb_ptr = 0x96b13f00, cmd_ring.dma = 0x96b13f40
[0003.623] W> WARNING: event and command not matching, cmd_trb_ptr = 0x96b13f00, cmd_ring.dma = 0x96b13f40
[0003.624] I>
[0003.624] I> Enumerated USB Device 046d:082d
[0003.628] I>
[0003.629]
[0003.631] -----------------------------------------------
[0003.636] Synchronous Exception: DATA ABORT (FAR: a5e0000046500018)
[0003.642] -----------------------------------------------
[0003.647] PAR_ELX: 0x809
[0003.650]
[0003.651] ESR 0x96000044: ec 0x25, il 0x1, iss 0x44
[0003.655] -----------------------------------------------
[0003.661] [Stack Trace]
[0003.663]
[0003.664] => pc:0x96030B18, sp:0x9607EEE0
[0003.668] => pc:0x96030E48, sp:0x9607F110
[0003.672] => pc:0x960241A0, sp:0x9607F120
[0003.676] => pc:0x96002358, sp:0x9607F140
[0003.680] => pc:0x96030644, sp:0x9607F190
[0003.683] => pc:0x96003710, sp:0x9607F240
[0003.687] => pc:0x960037D4, sp:0x9607F380
[0003.691] => pc:0x960035F8, sp:0x9607F3D0
[0003.695] => pc:0x96002C34, sp:0x9607F400
[0003.699] => pc:0x96002C08, sp:0x9607F410
[0003.703] -----------------------------------------------
[0003.708] iframe 0x9607edf0:
[0003.711] x0 0x 9607ad40 x1 0x 2b8 x2 0x 9607aff8 x3 0x 96078000
[0003.720] x4 0x 516150001c20001 x5 0xb40140000505217e x6 0xa5e0000046500000 x7 0x 2a0
[0003.729] x8 0x a x9 0x 1 x10 0x a x11 0x 2
[0003.738] x12 0x 4 x13 0x 7 x14 0x 4 x15 0x 200
[0003.747] x16 0x 1 x17 0x 0 x18 0x 0 x19 0x 9607f3a8
[0003.756] x20 0x 0 x21 0x 0 x22 0x 96074000 x23 0x 0
[0003.765] x24 0x 1 x25 0x 96049dd0 x26 0x 96049e1d x27 0x d0d150d
[0003.774] x28 0x 9607f3b0 x29 0x 9607f110 lr 0x 96030bb4 sp 0x 9607eee0
[0003.783] elr 0x 96030b18
[0003.786] spsr 0x a0000209
[0003.790] -----------------------------------------------
[0003.795] panic (caller 0x96001238): die
[0003.799] HALT: spinning forever...
There is no direct USB or PCIe error shown anywhere. One of the drivers talking through USB appears to have a deadlock.
How did you get access to the OOPS? Is the serial console available somehow?
Yes, I was running serial console.
GPIO expansion header pins 8, 10 and 11? I was under the impression that the serial console is to be available via the micro USB connector.
Yes, serial console is just the micro-B USB cable next to the 40 pin expansion header connected to the type-A port of the host PC. 115200 8N1 (it’s still a serial UART, but the host goes through USB without a special cable).
Thank you for your answer. I have not been able to get the micro-b to USB A to work, I’ll have to play around with it some more.
I have not checked with control flow, but I can verify gtkterm works with 115200 8N1 and no flow control.
I have six USB serial UARTs going, and one native to the motherboard. I gave up on trying to make any of them work with PuTTy on Windows 7 :P
FYI, it is the USB end which needs the FTDI driver. Because the FTDI chip is in the Xavier, but is technically run in the PC, this is why the driver must be in the host.
@GeForceX: How do you get Xavier’s output to laptops’screen?
@GeforceX: Thank you for your response. Could you specify the model of the HDMI USB 3.0 Capture card that you are using and that proved to work somehow.
I am asking because I never have used that sort of cards before and have no idea what of them will be a good fit for using Xavier with laptop’s display.
Thanks
Sorry, it is a confusing statement on my part. The distinction is that the FTDI chip is on the Jetson itself, but the Jetson is connected to the UART end. The host PC is connected to the USB part. The UART end does not require an FTDI driver, it is just serial bytes. The USB end does need a driver…this is on the host. When I connect the micro-B USB on the Xavier and then connect to the PC host this is what I see in the logs (my currently active FTDI devices using this one driver are all re-enumerating):
[ 9969.334468] usb 3-3.1: new high-speed USB device number 10 using ehci-pci
[ 9969.414330] usb 3-3.1: New USB device found, idVendor=0403, idProduct=6011, bcdDevice= 8.00
[ 9969.414344] usb 3-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 9969.414352] usb 3-3.1: Product: Quad RS232-HS
[ 9969.414358] usb 3-3.1: Manufacturer: FTDI
[ 9969.416534] ftdi_sio 3-3.1:1.0: FTDI USB Serial Device converter detected
[ 9969.416620] usb 3-3.1: Detected FT4232H
[ 9969.417211] usb 3-3.1: FTDI USB Serial Device converter now attached to ttyUSB5
[ 9969.418149] ftdi_sio 3-3.1:1.1: FTDI USB Serial Device converter detected
[ 9969.418207] usb 3-3.1: Detected FT4232H
[ 9969.418566] usb 3-3.1: FTDI USB Serial Device converter now attached to ttyUSB6
[ 9969.418891] ftdi_sio 3-3.1:1.2: FTDI USB Serial Device converter detected
[ 9969.418942] usb 3-3.1: Detected FT4232H
[ 9969.419295] usb 3-3.1: FTDI USB Serial Device converter now attached to ttyUSB7
[ 9969.419644] ftdi_sio 3-3.1:1.3: FTDI USB Serial Device converter detected
[ 9969.419741] usb 3-3.1: Detected FT4232H
[ 9969.420030] usb 3-3.1: FTDI USB Serial Device converter now attached to ttyUSB8
My host uses the FTDI driver, and Xavier does not even know it is FTDI. The serial UART protocol is the only thing the Xavier needs to know about. If the Xavier does not have an FTDI driver, then the serial console will still work. If the PC does not have an FTDI driver, then the serial console will fail.
This issue would be fixed in next release.
Please check if this issue is fixed on Jetpack4.1. We had some patch merged, and it should work.