so I’ll start with the devkit first and after it works I’ll move on to the custom carrier board (I didn’t make any changes to the device tree and flashed manually using the flash.sh script)
Does the devkit has the USB controller enabling it to be a host and an end point (device)?
Most of the full sized Jetsons with a micro-OTG port work in both host and device mode. I’m not positive, but I think the NX only supports device mode on the micro-OTG port. A third party carrier board might support both modes, but it would require different wiring and a different device tree.
OK but its enough for me am I wrong? I need the NX on device mode in order for one of its partitions will appear as a disk on the host
You have a custom carrier board. The dev kit already has device mode set up, but some dev kits (I think including the NX) do not enable host mode (and it cannot be enabled on those because the wiring does not exist). I couldn’t give you the exact instructions on a custom board in order to make the OTG port behave in both host and device mode, but there is one specific point that is important: The OTG socket has an ID pin, and a power delivery pin (hosts provide power, devices consume power). The physical wiring must be present, and the device tree must tell the kernel where and how to find those pins (the how might include which power rail to use…a USB2 micro-OTG is always +5V, so it wouldn’t work well if you routed a 12V rail to it).
I apologize, maybe I misunderstood something:
I tried connecting my ubuntu host to the custom carrier board and saw there is no README partition after flashing. Therefore I said I will verify that I see the README partition using a Xavier NX emmc model devkit (regardless to my custom carrier board nx module) just to see if the README partition appears. That’s why I asked if it can function as a USB device. You said it can only act as a device - but that’s what I need isn’t it? I want my ubuntu host to act as a USB host and the devkit to act as a USB device in order to see the README partition on my Ubuntu host. Am I confusing?
Regarding the custom carrier board module - during the flashing process we saw on the Ubuntu host dmesg output that it recognized the custom carrier nx partitions and mounted them on itself (I sent the dmesg output). Isn’t that enough to indicate that there is no problem with the device tree and physical wiring existence?
Thank you for your patience.
You may also tell if the target partition that you want to share has a filesystem mounted on Jetson. If not, it would be as easy as:
# Unplug USB to host
sudo service nv-l4t-usb-device-mode stop
# Check that target has not a fs mounted:
sudo lsblk
# If mounted as /media/user/... first unmount it such as:
sudo umount /dev/nvme0n1p2
# Edit file /opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode-config.sh and change last line with devfs path to your partition such as: `fs_img="/dev/nvme0n1p2"`
# restart service
sudo service nv-l4t-usb-device-mode start
Note that this would require a directory named version to be deleted and created at root of the target filesystem (should only be an issue if this fs already has a version directory).
If it fails to restart, try rebooting.
Note that this read-only. For rw, you would edit file /opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode-start.sh and change line 202 to :
echo 0 > "${func}/lun.0/ro"
This applies to the exported mass storage.
For the disk that will appear on Jeston, it is mounted read-only at line 269, for rw you would try to remove -r flag.
If you want to share an already mounted partition filesystem, it may be more complex.
The partition in question is not a “real” partition. It only exists when loopback has set it up as such (loopback covers a file; the loopback device is what shops up as a partition). @Honey_Patouceul just gave you the method of enabling/disabling and working with the loopback partition. Assuming it is still set up as default, this would likely show up as “loop0” when listing partitions, e.g., via lsblk. I am curious, what do you see when specifically looking at loop devices?
lsblk -f | grep loop
The USB making this visible as device mode is a separate topic versus loopback setup. This is where device tree becomes involved. The device tree does not set up, nor does it mount any loop or block device. The device tree does determine the wiring and setup of the USB lanes, and those lanes are the other half of the OTG port (or even regular host port) on the carrier board.
Half is the partition being available (virtual or not), the other half is the pipe making this available to the outside world (in this case USB). What does the lsblk show for the virtual loop devices (I’m assuming this is what is missing at first; once that is available, e.g., through the mentioned nv-l4t-usb-device-mode or an actual partition, it becomes a USB issue).
I can see the L4T-README partition on my Ubuntu host when I connect it to the devkit.
So first step is to create a new partition with new filesystem on my devkit and cause it to identify on my Ubuntu host just like the L4T-README partition does.
After that I’ll move on to the custom board.
Yes, and you can pick labels when you format the SSD. Basically, you do this:
gdisk is what I use, and creating a partition requires then setting the type; it’ll still format and work correctly in a lot of cases even if the type is incorrect, but it should “just work” if the type is correct). For a Linux ext4 that would normally be type “0700”.ext4, e.g., with “mkfs.ext4”.e2label”.Hi,
I have an update:
Devkit:
I edited the nv-l4t-usb-device-mode-start.sh to make my partition identify as a USB disk by the host.
Instead of using loop device to load a filesystem represented by a single file, the USB gadget uses my partition directly.
Next step is to figure out why the loop device on my custom carrier board NX is not recognized as a USB device in my host.
I have 3 questions:
Is there any consideration why creating a USB device from a loopback device and a filesystem backed by a single file is better than creating USB device from a specific partition?
my main concern is performance of copying data to my Ubuntu host from the nx memory
Does our discussion here applies to the Orin NX as well? (are they the same regarding the USB gadget framework and the README partition device example)
I’m not sure I’ll have access to my custom board soon. Should I close this thread and open a new one once I’ll have another questions regrading that problem?
Thanks
What L4T release are you using? See “head -n 1 /etc/nv_tegra_release”. The R32.x releases use a 4.x kernel, while the R34.x+ use a 5.x kernel. I don’t think there are any changes in the Gadget API between the two, but I’ve not really tried to look, so maybe there is a difference. Orin only uses the R34.x+ with a 5.x kernel, but Xavier NX can use either R32.x or R34.x+ (thus there might be a difference if going between kernel major release).
Every partition has many possible options, and in general, loopback looks just like a partition. The differences are in options. A few such options:
ext4 versus VFAT versus NTFS.The gadget API itself might set up security, not sure about that. The example loopback partition is read-only, and VFAT filesystem type. Other than that there isn’t really any difference in comparison to the partition you are using. The host PC itself which is looking at the partition might have different security, and might handle VFAT differently than ext4. Not sure.
Obviously going through loopback adds some overhead compared to going straight to a partition, but that isn’t likely a noticeable difference. The actual disk performance and method of connection probably matters a lot; if your NX is on eMMC, then the loopback partition is a small slice of the eMMC and depends first on eMMC performance; if the loopback partition is based on an SD card model, then that is no doubt even slower; if a USB external drive is used, then perhaps the difference between USB 2 and 3 would be the biggest difference. I couldn’t really predict what the whole chain looks like, especially when caching gets involved. Read-only usually reads once and stays cached, whereas read-write might cache some, and then get a cache miss. A system with lots of RAM will purposely use some of that as buffer, but as demand for memory goes up, buffer will get removed and switched to its new purpose.
The Orin NX shouldn’t be any different than Xavier in terms of the Gadget API. There are likely differences in I/O, and Orin is new, so I think it’s I/O is not yet really optimized. To that extent I suggest using the absolute most recent L4T release on any Orin, especially if performance matters.
A custom board would indeed be best in a new thread.
Thank you for your help. Much appreciates!
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.