Greetings,
I am running into an issue while trying to use the Elroy Carrier.
First of all, I am using the Imperx software for my Imperx camera while using my Orbitty Carrier with TX2i system. I connect the camera to the USB 3.0 hub of the Orbitty Carrier. Under these conditions, I can successfully receive images from the camera without any problems.
However, when I switch the carrier board from Orbitty Carrier to Elroy Carrier, make the proper connections for USB, HDMI etc. and follow the same steps with the same camera software, it does not seem to work. This seems like some kind of hardware issue.
Here are some of the troubleshooting steps I followed:
-
I tried changing the USB cable. I still can not receive images under this condition.
-
I tried changing the Imperx camera. I still can not receive images under this condition.
-
I tried changing the Elroy Carrier (with another Elroy Carrier). I still can not receive images under this condition.
-
I tried changing the power cable for the camera. I still can not receive images under this condition.
-
I tried changing the TX2i (with another TX2i with the same software and L4T installed). I still can not receive images under this condition.
-
I tried changing the USB hub I use on the connection cables from the Elroy Carrier package. I still can not receive images under this condition.
-
I tried changing the USB cable that gets attached to the Elroy Carrier with the 3 alternatives. I still can not receive images under this condition.
- I tried changing the camera configurations from the Imperx software. I can receive images when I significantly reduce the framerate or resolution of the images captured by the camera.
Here are some further information, in case they are helpful:
target system: NVIDIA TX2i
architecture: aarch64
operating system: Ubuntu 18.04 LTS
carrier board: Elroy Carrier Rev G (C) - 2018
camera: Imperx u3v-c2880m
camera software version: 1.3.0.29
Thank you in advance.
Do know that every carrier board requires its own board support package, and without this USB probably won’t work as expected (the device tree would probably be wrong if you don’t use the correct BSP).
If the BSP is correct, then what do you see with the tree view of lsusb? Run command “lsusb -t” while the cameras are connected. The “5000M” entries are USB3, the “480M” entries are USB2. We can use this to verify if USB3 is running from root_hub to end device.
Hello linuxdev,
Sorry for the late reply, I had to take care of something else that had higher priority at that time.
I attempted to install the BSP for the Elroy Carrier from the Connect Tech website. I followed the instructions for flashing the BSP. The “cti-flash.sh” told me that the flashing of the BSP was successful. However, after rebooting the TX2i, I can only see an Nvidia logo on the screen that stays there indefinitely until the system is turned off. The Ubuntu boot screen or the login screen does not appear at all.
Afterwards, I tried cloning the system image to see if something is wrong with it, using the “sudo ./flash.sh -r -k APP -G backup.img jetson-tx2i mmcblk0p1” command. The “backup.img” file is only 42.7 MB.
I have some questions:
Is this the expected result? Or could it have been caused by me accidentally skipping or messing up one of the steps?
Is a BSP intended only to be installed during the initial steps of setting up the system, or can it be installed on an existing system without harming the existing installed/saved files on the system? If so, how?
Since the BSP for exactly L4T 32.2.3 did not exist on the Connect Tech website, I tried installing both the 32.2.1 and 32.3.1 supported BSP (in this order). Both of them yield the same results. I do not know if it is harmful in a way, and I was not supposed to do this.
Thank you in advance.
The “backup.img” would be only one of two files. The file which is the full size, and which you can test and examine, is the raw “backup.img.raw”. Granted, 42.7 MB is too small to be valid, but it would be of interest to find out what the exact byte size is for “backup.img.raw”. Also, knowing if you can do this would be useful:
sudo mount -o loop /where/ever/it/is/backup.img.raw /mnt
ls /mnt
df -H -T /mnt
sudo umount /mnt
If the above succeeds, what do you see from the “df -H -T /mnt” result? I am thinking that the flashed content will not be valid, but debugging from a bad image versus invalid content will be very different in procedure. FYI, I always throw away the sparse “.img” file, and save only the raw “.img.raw” file.
Do know that the BSP changes for TX2 versus TX2i, BSP changes for JetPack/L4T/SDKM release, and BSP changes for each carrier board. You will want to verify that the BSP is valid for that mix of TX2i, L4T/JetPack/SDKM release, and for that carrier board. If this is not right it won’t account for why a flashed image is too small, but it would imply errors which would possibly break boot.
A serial console boot log would be useful (serial console logs even during bootloader stages). However, if the logo goes on and stays on, then the failure is from very early on (and very early on might be a discrepancy of BSP with TX2i and carrier board combination). Are you positive the Connect Tech carrier board, the BSP they provided, the JetPack/SDKM release, and the TX2i combination is valid?
I have managed to solve the issue. It turns out that I had completely misunderstood how the “cti-flash.sh” software from the BSP kit is supposed to work. Supposedly, it uses the contents of the “rootfs” folder located in the same directory to flash the target system. Since there is no rootfs folder in my first attempt, cti-flash flashes the system with a (almost) completely blank root file system, causing the issue I talked about earlier.
Here is how I managed to solve it:
- Create a copy of the system image of the TX2i using the command:
sudo ./flash.sh -r -k APP -G backup.img jetson-tx2i mmcblk0p1
- Create a “rootfs” folder in the “Linux_for_Tegra” folder and mount the backup image into this folder, populating this folder with the proper root file system:
sudo mount -t ext4 -o loop backup.img.raw ./rootfs
- Download the BSP from the Connect Tech website, and place the CTI-L4T folder inside the Linux_for_Tegra folder.
- Allow the BSP toolkit to make some changes on the host system, mainly placing some files to their appropriate locations:
sudo ./CTI_L4T/install.sh
- Allow the BSP to be flashed onto the target system, using the modified root file system in “rootfs” folder, which now contains the BSP components:
sudo ./cti-flash.sh
- Flashing is probably successfully completed at this point. If so, unmount the “rootfs” folder:
sudo umount ./rootfs
- Feel free to delete backup.img, backup.img.raw, system.img, system.img.raw etc. as they occupy a lot of space.
This is an excellent way to do it! Often people don’t realize they can use a clone as either the “bootloader/system.img” or as a loopback mount on “rootfs/”. Do know that if you loopback mount though, that the “boot/” content (and perhaps some firmware) will be updated upon flash…but the beauty of that is knowing your clone is updated to an exact copy of what went onto the system, but without performing another clone.
PS: If the clone is from a system which has been updated and set up correctly, then I always save the raw image. It takes a long time, but if this is going to be stored, I run “bzip2 -9” on the image. This is still several GB in size, but having an already configured system is handy for all kinds of reasons, including sysroot content of cross compile.
I am having an almost identical issue to what you describe in this post, except with a different camera.
What versions of Jetpack/Tegra (e.g 32.2.1) and which CTI BSP profile (e.g. elroy-revF+ vs. elroy-usb3) were you successful in using to enable USB 3.0?
Thanks.
Hello Nathan,
As I mentioned earlier, I had 32.2.3 as for the version of L4T, and there is no corresponding exact version for the Board Support Package on Connect Tech Website. The most relevant option are 32.2.1 and 32.3.1. I don’t remember which one of these I installed, so I can only suggest you to try both options if one does not work. Also, my revision for Elroy Carrier is “Elroy Carrier Rev G © - 2018”, therefore I naturally chose the revF+ option. You can see the review number physically printed on the carrier board itself.
Did you try installing the BSP from the Connect Tech website using the instructions I gave on my last message? Can you not use the USB-3 hub even after trying to install the BSP? If that is the case I might try giving more detailed information.
Thanks for your reply. My issues may be hardware specific. I just wanted to match your versions exactly since you had a working USB3.0 solution. I appreciate it.