A bit of trivia – the connector for the Jetson AGX Orin is 699 positions and costs $74.
Is this the correct connector? There is a Mirror Mez connector that looks the same as the 699 pin version but only has 63 columns verses the 699’s 65 columns. When groking documentation on DigiKey for example it’s easy to get these two mixed up due to confusion over Molex’s part numbering system as they look identical. Also note how this connector mates with itself. The pin numbering which must be used with a carrier board has the row lettering (A-L) reversed from the Molex documentation. Nividia could have avoided a bit of brain scramble on the part of us developers if THEY had mirrored the pin numbering of the AGX module then Molex’s documentation would match that needed by the mating connector on any daughter card. There are also two different heights in this connector series. Part number 2034560003 is 5.5mm high, 2034560001 is 2.5mm high. Depending on connector selection this gives mated heights between PCB’s of 5, 8 or 11mm. See the drawing below:
2034560003_sd.pdf (1.9 MB)
Design guide for daughter cards:
Jetson_AGX_Orin_Series_Design_Guide_DG-10653-001_v1.6.pdf (3.5 MB)
AGX module basic data sheet:
Jetson_AGX_Orin_Series_Data_Sheet_DS-10662-001_v1.5.pdf (788.6 KB)
Nvidia AGX carrier board specifications:
Jetson_AGX_Orin_DevKit_Carrier_Board_Specification_SP-10900-001_v1.1.pdf (1.1 MB)
AGX module thermal design guide:
Jetson_AGX_Orin_Series_TDG-10943-001_v1.2.pdf (512.2 KB)
AGX carrier board Schematic: (anyone have a D size plotter handy? )
P3737_A05_OrCAD_schematics(base_version).pdf (1.3 MB)
Pin function names:
Jetson_AGX_Orin_Pin_Function_Names_Guide_DA-11060-001_v1.0.pdf (758.8 KB)
Dunno, I got the PN from our CAD library 
The development kit is a hefty chunk with a large integrated heat-sink:
Documentation:
A plastic cover can be removed to reveal a PCI slot:
The USB-C connector is plugged into the USB-C port above the power jack to power the unit.
The specs on the power supply are interesting:
This is a USB-C PD (power delivery) supply capable of delivering multiple voltage and current combinations. The power supply uses the USB Power Delivery protocol to communicate with the connected device to determine the optimal voltage and current combination. This type of power supply is highly versatile and capable of powering low-power smartphones to high-end laptops.
This power is delivered on the VBUS pins (5-20V).
The USB-C PD protocol communicates over the CC1/CC2 pins – only one is used based on cable orientation. The PD protocol uses a Bi-phase Mark Coded (BCM) signaling.
It looks like there are some efforts to integrate the USB-C PD protocol into Zephyr.
(note, this post is a wiki, so feel free to edit it with updates on the dev kit)
USB-C PD is a nice complex solution to a mostly political problem due to China’s demands that companies reduce the number and variety of power supplies for mobile devices. For the Nitro I vote for simplicity and go with another standardized power supply, the 19V laptop standard used by ASUS and most other laptop makers these days. The AGX dev kit, at least on paper according to the schematics, can operate with one of these in addition to USB-C PD. 4.5A through those itty bitty contacts is definitely pushing the limit. The least little bit of dirt or crud on them and they’ll start heating and at 90W eventually burn up the connector, gold contacts notwithstanding.
That being said, implementing USB-C power delivery as a sink-only device is not that complicated. However it does limit the maximum power available to us to 90W. Going to USB-C PD2 (48V) to get more power is needlessly complex for a design like this.
Yes, for stationary industrial devices where you are not trying to charge batteries in multiple devices on the go, USB-C PD is probably overkill.
A bit on Software, If we want to check openCV has CUDA support enabled then build yoe-kiosk-image with yoe distro and flash it.
IMAGE_INSTALL:append = " python3-opencv"
Then run following python script
import cv2
import re
cv_info = [re.sub('\s+', ' ', ci.strip()) for ci in cv2.getBuildInformation().strip().split('\n')
if len(ci) > 0 and re.search(r'(nvidia*:?)|(cuda*:)|(cudnn*:)', ci.lower()) is not None]
print(cv_info)
This should print something like below on AGX board
['NVIDIA CUDA: YES (ver 12.2, CUFFT CUBLAS)', 'NVIDIA GPU arch: 87', 'NVIDIA PTX archs:', 'cuDNN: YES (ver 8.9.4)']
A few random notes regarding my AGX Orin dev kit bring-up process today:
Use the USB-C to USB-A cable supplied with the dev kit. I tried connecting my desktop to the AGX via a Thunderbolt 3 cable (which worked for the nano) and never could get the two devices to communicate using it. Only once I hooked them together with the supplied cable did the AGX enumerate on my system and then able to flash the Yoe image.
The AGX Orin has several power profiles, each of which limit the max power consumption, CPUs available, CPU frequency, GPU power, etc… To change profiles, you have to use nvpmodel and/or edit /etc/nvpmodel.conf . Setting the power model to ‘0’ results in max performance mode: all cores being active, max CPU frequency, and no power limit.
More details from our friends at RidgeRun: Jetson Power Profiles
That’s pretty sweet, will come in handy when the main power input fails and the system is forced to fall back to battery power.
There is hope for implementing the OTA and installer mechanism of yoe updater something similar is done here, however its old. But we can get the information on creating flashmap from initrd which is the most vital information we need for yoe installer. Once we have that updater logic is a cake walk.
Thunderbolt cables may look like USB-C cables but they are “active” cables, having internal buffers to drive the cable, and aren’t strictly compatible with USB-3.
I had assumed Thunderbolt cables were just the top of the line (based on being active, having cable length requirements, and their price tag) but they would be backwards compatible with USB3. I guess that’s not always true then.
Just some notes today on performance using an Anyoyo Thunderbolt enclosure for NVME devices. Memory stick I have is a 1TB Crucial brand device with its own heat dissipator.
Test one made with my MSI laptop that has a Thunderbolt 3 controller on board:
Buffered disk reads from the Anyoyo enclosure come out to 1202.43MB/sec while the internal nvme0 (my second disk) runs at 641.93MB/sec. Cached reads are about the same, around 37674MB/sec for the enclosure and 36870MB/sec for the internal Samsung 970VO stick. Guess that’s the difference between the older 970VO nvme stick and the newer Crucial stick.
My PC had the ASUS USB4 card installed which uses the AS Media ASM4242 controller. A first attempt at hot plugging the Anyoyo enclosure did not work, it wouldn’t recognize the enclosure. A reboot with the enclosure attached enumerated properly but then refused to mount due to some block ID issue. However, running ‘sudo blkid’ generated the proper output for nvme2 so I tried to mount the nvme2 drive as read only, and that worked. Test results were:
dev/nvme1n1: (internal Kingston nvme drive)
Timing cached reads: 45602 MB in 2.00 seconds = 22836.95 MB/sec
Timing buffered disk reads: 4198 MB in 3.00 seconds = 1398.68 MB/sec
jeffs@Isengard:/mnt$ sudo hdparm -tT /dev/nvme2n1
/dev/nvme2n1: (Crucial memory stick in Anyoyo enclosure)
Timing cached reads: 42922 MB in 2.00 seconds = 21492.67 MB/sec
Timing buffered disk reads: 4380 MB in 3.00 seconds = 1459.90 MB/sec
So it seems that USB4 performance is running just a bit faster than Thunderbolt 3 on my laptop. No big surprise there since this is an up to date ASUS motherboard and my laptop is 4 years old.
Attempts to test with the ASUS Thunderbolt 4 card failed as the card appears to have failed. USB2.0 still functions but TB/USB4 devices will not enumerate. Dmesg also shows that the card will not initialize properly so guess I have to find a new one.
(update on 11/12/24:)
Installed a new ASUS ThunderboltEX card and now everything is working properly again. Noted the performance of the Anyoyo enclosure once again, this is running through my OWC Thunderbolt hub:
Timing cached reads: 38618 MB in 2.00 seconds = 19336.39 MB/sec
Timing buffered disk reads: 3914 MB in 3.00 seconds = 1304.63 MB/sec
Hmmm… somewhat slower than TB3, let’s try a direct connection to the second port on the card itself:
Timing cached reads: 47012 MB in 2.00 seconds = 23543.35 MB/sec
Timing buffered disk reads: 4276 MB in 3.00 seconds = 1424.93 MB/sec
Hmmm… So there is definitely a performance penalty when going through a hub. The cables, hub and PCIe card are all Thunderbolt 4.
Compare this to a USB-C connected external hard drive:
Timing cached reads: 25290 MB in 2.00 seconds = 12657.10 MB/sec
Timing buffered disk reads: 12 MB in 3.52 seconds = 3.41 MB/sec
TB4 cables seem to work OK with USB4 > TB devices. Tried a couple cables marked ‘4’ along with the lightning bolt, both worked OK.
I’m glad you guys are posting information about the NVIDIA Jetson hardware. Thanks for the information.