Hello,
I am trying to connect 28 USB webcams (USB 3) cameras via a 10 port USB hub (3 of them) to the Jetson Orin AGX via the USB 3.2 Type A: 2× Stacked (4× total. 2× Gen2 and 2× Gen1). When I plug in each hub individually it recognises the cameras but doesn’t when I plug in more than 2 10 port hubs simultaneously. I have tried this on a Windows machine and it handled it perfectly. I have thoroughly checked the hubs are perfectly fine as are the cameras and the cables. On paper, the jetson agx orin should handle this fine. I have tried resetting the USB ports and it still doesn’t work.
System Information - aarch64, Ubuntu 20.04, Debian, 32GB dev kit, 5.10.65-tegra.
Any help or suggestions would be greatly appreciated, Thank you.
Hi,
Do you use AGX Orin developer kit? If yes, please also use the type-C port. The 4 type-A ports are embedded USB hub and connected to single USB roothub. We would suggest connect to the type-C ports to use bandwidth of the other two USB roothubs.
What do you recommend to be the best way of connecting all 28 (if possible)? Like a split between the type C and A ports? And yes I am using the 32GB dev kit.
Hello, so i tried using a using the USB C port by plugging in an adapter and still no luck. Do you have any information with regards to the maximum EP for this kit and are they any ways of exceeding it or going around it. I was sold on the idea that these ports are individual ports not knowing they are root hubs. Thank you for your help so far.
I will suggest that if the expansion card has available external power, then this makes success more likely. Additionally, you’d need to find out if there is a specific driver in the Linux kernel for that expansion card.
Also, although this would add some available devices, but there are still limitations on bandwidth (both the PCIe bandwidth and the shared USB bandwidth…the PCIe card provides at least one root HUB, but is each port its own? if not, then you again have bandwidth limitations).
Hello @linuxdev thank you for your suggestions I have tried to cover all the very important points you mentioned. I have bought this → 4-Port USB PCIe Card 3.2 Gen 2 - 2 Chips - USB 3.0 Cards | StarTech.com United Kingdom it has an option for external power(I don’t think it would be needed because I plan on testing with powered USB hubs), it has embedded drivers compactible with Linux 3.5 and up - LTS Versions only. And finally it has two different chips(controllers) for 4 ports which I think should suffice in addition to the one the Orin AGX provides. Thank you again for your help I will keep you all updated.
Yes, powered USB HUBs would solve a lot of problems.
Once you have this working (assuming there might be a driver needing install, but maybe not) you might want to use lspci to check the PCIe speed (if you run just “lspci” it will list a slot, for example, it might be slot “01:00.0”, I’ll use that as an example), and find the fully verbose listing: sudo lspci -s 01:00.0 -vvv
There will be something listed for “LnkSta” (the link status). Speeds are listed in giga transfers per second (GT/s). 5 GT/s is PCIe v2, 8 GT/s is PCIe v3. Hopefully it will be at v3. Then examine the actual USB topology with “lsusb -t”.
Hello again, so it works.The PCIe adapter is a v2 (5 GT/s) but the Jetson ORIN AGX port is supposed to be a Gen 4 port but currently reporting (2.5 GT/s ) which i think is a current limitation.
The Link cap for the PCIe port ‘LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us’ ‘LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)’
When i run the ’ sudo lspci -s 0005:04:00.0 -vvv’ it displays →
“LnkSta: Speed 5GT/s (downgraded), Width x2 (ok)” “LnkCap: Port #0, Speed 8GT/s, Width x2, ASPM L0s L1, Exit Latency L0s <2us, L1 unlimited”
This is the same for the two controllers on the PCIe adapter. I’m not too sure if the speed would be sufficient yet.
I was wondering if there was a way of altering the default speed of the PCIe port or is that just the max speed setting.
Thank you again for all your help.
You can post the full PCIe log via: sudo lspci -vvv 2>&1 | tee log_pci.txt
(then attach “log_pci.txt” to the forum)
PCIe may be working the way intended. The link capability is the max link the device will make available, but this depends on signal training.
The way this works a PCIe card will tell PCI what its specs are. PCIe will then try various signal rates for a sort of “test” of signal quality. The maximum rate at which quality is sufficient is chosen (and this is “link training”). If the card is capable of v2 (link capability), but running at gen. 1 (the 2.5 GT/s you mentioned), then it means signal quality was insufficient to read gen. 2.
Regardless of how good the signal is, since the card has a capability of only gen. 3 (the advertisement says PCIe v3, USB says gen. 2, but USB is a different standard and we are speaking only of PCIe), there would never be a possibility of PCIe v4. PCIe cards can have more than one device present (verbose listings show numbered link status “LnkSta” and link capability, “LnkCap”), and there is also control, so it isn’t always obvious which “device” link capability you are looking at, but somewhere (if the advertisement is correct), then there should be a PCIe capability of some part of the card listed as PCIe v3. PCIe v4 has no possibility of even being tested since PCIe would not attempt to run that fast on an adapter stating it is gen. 3. If the particular link has a capability of only gen. 2, then nothing would be tried for that particular link beyond gen. 2.
RF signal quality is a very complicated thing. Slight changes in capacitance and inductance or trace shapes can make otherwise identical hardware behave quite differently. Within your verbose lspci there is a note about something called “de-emphasis” (which is always coupled with a matching “pre-emphasis”, although it isn’t mentioned). This can make up for trade lengths to some extent, and a proper implementation will tend to use a -3.5dB de-emphasis (paired with the same pre-emphasis…the transmit end uses pre-emphasis, the receive end uses de-emphasis), while longer traces tend to use a -6dB pre-emphasis/de-emphasis. This is pretty much the only adjustable setting, but this in turn is usually set in firmware based on the carrier board design. You won’t have any ability to force a higher rate, and doing so would likely just result in high error rates.
Hello, thank you again, very useful information. I will read up more on this. I will also run some more tests to push the hardware to its max. For now I am pretty sure all 28 cameras are detected, able to communicate and send data quick enough for my intended use.
Please also find the log_pci.txt attached below. Thank you again for all your help.