Jetson TX2 not detected on host PC

Hi,

I am developing a project based on jetson TX2. My TX2 based device application is recording video. The recorded files are stored in eMMC of Tx2. My L4T BSP version is R32.2.1.

My requirements is follow:

  1. I want to connect the device as device mode with host PC.
  2. The host PC should detect the device and mount the filesystem.
  3. The desire partition must be a non root partition.

I have followed this how-to-set-tx2-otg-usb-as-device-mode discussion to achieve my application.

When i connect TX2 with host(ubuntu PC) through micro usb2.0 (same port used for flashing). The TX2 goes on device mode the other usb device like keyboard is not working. But the device is not detected in host PC. I checked the dmesg of both system but nothing is there related to new usb.

Please guide me to connect TX2 to host PC.

Thanks,
Asif Ikbal

What L4T release? See “head -n 1 /etc/nv_tegra_release”.

What is the exact full path to your recorded files? Who is the owner of the files? What modifications did you make to any of the files at:
/opt/nvidia/l4t-usb-device-mode/

Assuming this is the dev kit, but you might want to confirm. Are you using the supplied micro-B USB cable, or some other cable?

Hi Linuxdev,

Thanks for your reply.

Our L4T release is:
# R32 (release), REVISION: 2.1, GCID: 16294929, BOARD: t186ref, EABI: aarch64, DATE: Tue Aug 13 04:45:36 UTC 2019

We are not using dev kit but we are using third party board which is ASG006 provided by connect tech. We are using some other micro-B usb cable with OTG capable.

Our recorded video files are stored in a folder located in /home/ubuntu. The files owner is ubuntu.

I only modify the filesystem.img size by truncate command and type of file system using mkfs.vfat. My current filesystem is:
$ file filesystem.img
filesystem.img: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, sectors 1048576 (volumes > 32 MB), FAT (32 bit), sectors/FAT 1024, serial number 0x6bdebc06, unlabeled

Rest of other scripts are keep as it is. I have gone through the scripts from /opt/nvidia/l4t-usb-device-mode/ and i am understand that the filesystem.img will be exported over USB for host PC.

Please correct me if something is wrong in this process and help to connect the TX2 with PC.

Thanks,
Asif Ikbal

When you first started on this, do you know if the default example USB device mode content was working? There are many reasons why a third party board could fail with even the default sample code, especially if the device tree needed a change for the wiring layout to the micro-OTG connector (the custom carrier might have a different wiring layout, and the device tree is the method of conveying that information).

If we know the port was working with the default example device mode code, then we have basically verified that the device tree is correct. If we know the device tree is correct, then it comes down to finding out what configuration will work.

To say that filesystem.img will be exported over USB is correct, but it is also complicated. The file itself is not what is exported, it is the loop device covering the file which is exported. Just to illustrate, if the file itself is read-only, then you wouldn’t be able to write files. If the file is read-write, but the loopback device is read-only, then once again you would not be able to write. If there are security issues (such as the user not having permission to read), then you wouldn’t even be able to read the device, although possibly you’d be able to detect it. Your first step would always be one of just seeing if you can read.

Having the files in “/home/ubuntu” tells me that the only users that’ll be able to read or write will be limited to user “ubuntu” and user “root”. You could have made permission updates to change that, so this is not “written in stone”. However, consider that the user logged in to the system is predictable, but the user running the device mode software might not be who you expect…it wouldn’t matter which computer you plug that micro-B port in to, the user who is logically accessing the disk space depends upon the other code. I’m not quite sure how to test for that, but it is irrelevant until the loopback partition is detected.

As a test I suggest that initially you do not modify any of the code in “/opt/nvidia/l4t-usb-device-mode/”. Make sure that works. Then change only one thing: Change the location of the filesystem.img to your “/home/ubuntu/” location, restart, and see if this is when you lose detection of the device mode filesystem. If you can read content there, then likely permissions are ok and you can proceed to other updates.

  • Are you able to read content without any modifications in “/opt/nvidia/l4t-usb-device-mode/”?
  • Are you able to modify only the location of the “filesystem.img” and read from that location as well?
  • From the Jetson, if you monitor “dmesg --follow”, do you see any output upon insert of a micro-B USB cable?

Hi Linuxdev,

Thanks for your reply. Happy New Year.

I have tried to connect the TX2 without any modifications in “/opt/nvidia/l4t-usb-device-mode/” but problem is still there. The TX2 is not detected on host PC. I have monitor dmesg --follow and I got:

[ 4342.304450] usb 1-1: USB disconnect, device number 26
[ 4342.304475] usb 1-1.2: USB disconnect, device number 27
[ 4342.304495] usb 1-1.2.2: USB disconnect, device number 28
[ 4342.483503] usb 1-1.2.4: USB disconnect, device number 29
[ 4344.046652] usb usb1: usb_suspend_both: status 0
[ 4344.046688] tegra-xusb 3530000.xhci: entering ELPG
[ 4344.052202] tegra-xusb 3530000.xhci: entering ELPG done
[ 4354.055335] tegra-xusb 3530000.xhci: exiting ELPG
[ 4354.060149] tegra-xusb 3530000.xhci: Firmware timestamp: 2018-12-26 10:30:04 UTC, Version: 55.12 release
[ 4354.061486] tegra-xusb 3530000.xhci: exiting ELPG done

I have checked for device tree configuration for USB. This is my device tree configuration

usb_cd {
status = “okay”;
phys = <&tegra_xusb_padctl TEGRA_PADCTL_PHY_UTMI_P(0)>;
phy-names = “otg-phy”;
};

xotg {
    status = "okay";
    phys = <&tegra_xusb_padctl TEGRA_PADCTL_PHY_UTMI_P(0)>;
    phy-names = "otg-usb2";
};

xudc@3550000 {
    status = "okay";
    phys = <&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-0}>;
    phy-names = "usb2";
    nvidia,boost-cpu-freq = <1200>;
};

usb_cd {
    status = "okay";
    phys = <&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-0}>;
    phy-names = "otg-phy";
    nvidia,xusb-padctl = <&xusb_padctl>;
};

xhci@3530000 {
    status = "okay";
    phys = <&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-0}>,
        <&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-1}>,
        <&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-2}>,
        <&{/xusb_padctl@3520000/pads/usb3/lanes/usb3-0}>,
        <&{/xusb_padctl@3520000/pads/usb3/lanes/usb3-1}>,
        <&{/xusb_padctl@3520000/pads/usb3/lanes/usb3-2}>;
    phy-names = "usb2-0", "usb2-1", "usb2-2", "usb3-0", "usb3-1", "usb3-0";
};


xusb_padctl@3520000 {
    status = "okay";
    pinctrl-0 = <&vbus_en0_default_state>;
    pinctrl-1 = <&vbus_en1_default_state>;
    pinctrl-2 = <&vbus_en0_sfio_tristate_state>;
    pinctrl-3 = <&vbus_en1_sfio_tristate_state>;
    pinctrl-4 = <&vbus_en0_sfio_passthrough_state>;
    pinctrl-5 = <&vbus_en1_sfio_passthrough_state>;
    pinctrl-names = "vbus_en0_default", "vbus_en1_default",
        "vbus_en0_sfio_tristate", "vbus_en1_sfio_tristate",
        "vbus_en0_sfio_passthrough", "vbus_en1_sfio_passthrough";

    pads {
        usb2 {
            lanes {
                usb2-0 {
                    nvidia,function = "xusb";
                    status = "disabled";
                };
                usb2-1 {
                    nvidia,function = "xusb";
                    status = "disabled";
                };
                usb2-2 {
                    nvidia,function = "xusb";
                    status = "disabled";
                };
            };
        };
        usb3 {
            lanes {
                usb3-0 {
                    nvidia,function = "xusb";
                    status = "disabled";
                };
                usb3-1 {
                    nvidia,function = "xusb";
                    status = "disabled";
                };
                usb3-2 {
                    nvidia,function = "xusb";
                    status = "disabled";
                };
            };
        };
    };
    ports {
        usb2-0 {

            mode = "otg";
            vbus-supply = <&battery_reg>;
            nvidia,oc-pin = <0>;
            status = "disabled";
        };
        usb2-1 {
            mode = "host";
            vbus-supply = <&battery_reg>;
            nvidia,oc-pin = <1>;
            status = "disabled";
        };

        usb2-2 {
            mode = "host";
            vbus-supply = <&battery_reg>;
            status = "disabled";
        };

        usb3-0 {
            nvidia,usb2-companion = <0>;
            status = "disabled";
        };
        usb3-1 {
            nvidia,usb2-companion = <1>;
            status = "disabled";
        };
        usb3-2 {
            nvidia,usb2-companion = <2>;
            status = "disabled";
        };
    };
};
pinctrl@3520000 {
    status = "okay";
    pinctrl-0 = <&tegra_xusb_padctl_pinmux_default>;
    pinctrl-1 = <&vbus_en0_sfio_tristate_state>;
    pinctrl-2 = <&vbus_en1_sfio_tristate_state>;
    pinctrl-3 = <&vbus_en0_sfio_passthrough_state>;
    pinctrl-4 = <&vbus_en1_sfio_passthrough_state>;
    pinctrl-5 = <&vbus_en0_default_state>;
    pinctrl-6 = <&vbus_en1_default_state>;
    pinctrl-names = "default",
        "vbus_en0_sfio_tristate", "vbus_en1_sfio_tristate",
        "vbus_en0_sfio_passthrough", "vbus_en1_sfio_passthrough",
        "vbus_en0_default", "vbus_en1_default";
    tegra_xusb_padctl_pinmux_default: pinmux {
        /* Quill does not support usb3-micro AB */
        usb2-port0 {
            nvidia,lanes = "otg-0";
            nvidia,function = "xusb";
            nvidia,port-cap = <TEGRA_PADCTL_PORT_OTG_CAP>;
            nvidia,oc-pin = <0>;
            status = "disabled";
        };
        usb2-port1 {
            nvidia,lanes = "otg-1";
            nvidia,function = "xusb";
            nvidia,port-cap = <TEGRA_PADCTL_PORT_HOST_ONLY>;
            nvidia,oc-pin = <1>;
            status = "disabled";
        };

        usb2-port2 {
            nvidia,lanes = "otg-2";
            nvidia,function = "xusb";
            nvidia,port-cap = <TEGRA_PADCTL_PORT_HOST_ONLY>;
            nvidia,oc-pin = <2>;
            status = "disabled";
        };

        usb3-port0 {
            nvidia,lanes = "usb3-0";
            nvidia,port-cap = <TEGRA_PADCTL_PORT_HOST_ONLY>;
            nvidia,oc-pin = <0>;
            status = "disabled";
        };

        usb3-port1 {
            nvidia,lanes = "usb3-1";
            nvidia,port-cap = <TEGRA_PADCTL_PORT_HOST_ONLY>;
            nvidia,oc-pin = <1>;
            status = "disabled";
        };

        usb3-port2 {
            nvidia,lanes = "usb3-2";
            nvidia,port-cap = <TEGRA_PADCTL_PORT_HOST_ONLY>;
            nvidia,oc-pin = <2>;
            status = "disabled";
        };
    };
};

One of the top level device tree file is making those nodes status to “okay” so final dts file have status = "okay".

Here is the dmesg log related to xudc:

[ 0.449017] iommu: Adding device 3550000.xudc to group 45
[ 0.449040] arm-smmu: forcing sodev map for 3550000.xudc
[ 3.673150] tegra-xudc-new 3550000.xudc: device count: 1
[ 3.674436] tegra-xudc-new 3550000.xudc: vbus state: 0
[ 3.674464] tegra-xudc-new 3550000.xudc: entering ELPG
[ 3.675348] tegra-xudc-new 3550000.xudc: entering ELPG done

Please correct me if anything wrong in device tree and help me connect the TX2 with host.

Thanks,
Asif Ikbal

Hi Asif - Have you contacted our Tech Support Team? If you fill out our support form, our Tech Team will help you work through this. You can find the form here: Customer Support Form - Connect Tech Inc.
Thanks!
Jacki

I could not personally tell you if those are valid device tree settings. CTI would know though since it is their board.