Configure Jetson TX1 as OTG device mode

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX1
1

I have followed this post (JTX1_USB_as device - Jetson TX1 - NVIDIA Developer Forums) on how to configure Jetson TX1 as device mode for USB0 OTG port but my kernel and or patched dtb does not create the /sys/class/android_usb directory nor a /sys/devices/platform/tegra-otg (ALL other relevant /sys/class directories are present only otg missing)

Any help on this issue would be immensely appreciated.

kernel defconfig:

CONFIG_USB_OTG=y
# CONFIG_USB_OTG_WHITELIST is not set
CONFIG_USB_XHCI_HCD=y
CONFIG_TEGRA_XUSB_PLATFORM=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_ACM=y
CONFIG_USB_STORAGE=y
CONFIG_USB_NV_SHIELD_LED=y
CONFIG_USB_NV_SHIELD_PDA=y
CONFIG_USB_OTG_WAKELOCK=y
CONFIG_USB_TEGRA_OTG=y
CONFIG_USB_TEGRA_XOTG=y
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_VBUS_DRAW=500
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=4
CONFIG_USB_TEGRA=y
CONFIG_USB_TEGRA_XUDC=y
CONFIG_PLAT_FPGA_T210=y
CONFIG_USB_G_ANDROID=y
CONFIG_USB_TEGRA_CD=y

logs:

15.714125] init: write_file: Unable to open '/sys/block/mmcblk1/queue/read_ahead_kb': No such file or directory
[   15.724732] init: write_file: Unable to open '/sys/class/android_usb/android0/iSerial': No such file or directory
[   15.735112] init: write_file: Unable to open '/sys/class/android_usb/android0/iManufacturer': No such file or directory
[   15.745984] init: write_file: Unable to open '/sys/class/android_usb/android0/iProduct': No such file or directory
[   15.756427] init: write_file: Unable to open '/sys/class/android_usb/android0/f_rndis/manufacturer': No such file or directory
[   15.767949] init: write_file: Unable to open '/sys/class/android_usb/android0/f_rndis/vendorID': No such file or directory
[   15.779049] init: write_file: Unable to open '/sys/class/android_usb/android0/f_rndis/wceis': No such file or directory
2

Applied this patch also:

Subject: [PATCH] jetson-tx1: xudc with usb2p0/ss1

---
 .../boot/dts/tegra210-jetson-cv-base-p2597-2180-a00.dts  | 16 ++++++++--------
 arch/arm64/configs/tegra21_defconfig                     |  3 +++
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/tegra210-jetson-cv-base-p2597-2180-a00.dts b/arch/arm64/boot/dts/tegra210-jetson-cv-base-p2597-2180-a00.dts
index 1b32f8b..84db2cd 100644
--- a/arch/arm64/boot/dts/tegra210-jetson-cv-base-p2597-2180-a00.dts
+++ b/arch/arm64/boot/dts/tegra210-jetson-cv-base-p2597-2180-a00.dts
@@ -412,18 +412,19 @@
 		nvidia,port-otg;
 		nvidia,charging-supported;
 		#extcon-cells = <1>;
-		status = "okay";
+		status = "disabled";
 	};
 
 	otg@7d000000 {
 		#extcon-cells = <1>;
-		status = "okay";
+		status = "disabled";
 	};
 
 	xusb_pad_ctl: padctl@0 { /* Put common control config here */
-		nvidia,ss_portmap = <0x21>;
+		nvidia,ss_portmap = <0x7701>;
 		nvidia,lane_owner = <0xff56>; /* Use 0xF to disable lane assign */
-		status = "okay";
+        nvidia,otg_portmap = <0x0102>;
+        status = "okay";
 	};
 
 	xusb@70090000 {
@@ -431,22 +432,21 @@
 		/* nvidia,gpio_controls_muxed_ss_lanes; */
 		nvidia,gpio_ss1_sata = <0>;
 		nvidia,ulpicap = <0>; /* No ulpi support. can we remove */
-		nvidia,portmap = <0x0e03>;
+		nvidia,portmap = <0x0e01>;
 		nvidia,common_padctl = <&xusb_pad_ctl>;
 		status = "okay";
 	};
 
 	xudc@700d0000 {
 		nvidia,common_padctl = <&xusb_pad_ctl>;
-		nvidia,portmap = <0x0108>;
 		#extcon-cells = <1>;
-		status = "disabled";
+		status = "okay";
 	};
 
 	xotg {
 		#extcon-cells = <1>;
 		nvidia,common_padctl = <&xusb_pad_ctl>;
-		status = "disabled";
+		status = "okay";
 	};
 
 	gpu-dvfs-rework {
diff --git a/arch/arm64/configs/tegra21_defconfig b/arch/arm64/configs/tegra21_defconfig
index 6390256..300102a 100644
--- a/arch/arm64/configs/tegra21_defconfig
+++ b/arch/arm64/configs/tegra21_defconfig
@@ -458,9 +458,12 @@ CONFIG_USB_SERIAL_OPTION=y
 CONFIG_USB_SERIAL_BASEBAND=m
 CONFIG_USB_NV_SHIELD_LED=y
 CONFIG_USB_TEGRA_OTG=y
+CONFIG_USB_TEGRA_XOTG=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_VBUS_DRAW=500
 CONFIG_USB_TEGRA=y
+CONFIG_USB_TEGRA_XUDC=y
+CONFIG_USB_G_ANDROID=y
 CONFIG_PLAT_FPGA_T210=y
 CONFIG_USB_AUDIO=m
 CONFIG_USB_ETH=m
-- 
2.1.4
3

The only logs I get with dmesg|grep otg is:

otg_wakelock_init: No USB transceiver found

and dmesg|grep gpio:

extcon-gpio-states 1.extcon: Cable state 1

with usb otg cable attached

extcon-gpio-states 1.extcon: Cable state 0

with no usb otg cable connected

I can’t understand why I dont have a /sys/class/android_usb/ directory even though I have enabled all the corect defines in my defconfig. I have even used the default tegra21_android_defconfig and I still get the same results, no OTG support…

4

I have not set this up so I can’t say what is going on. Do beware though that in general if the driver is not there or fails to load, then the related “/sys” will go away even if the driver is defined.

About configuration of the kernel and items you can’t find…try “make nconfig”. nconfig has an option to show invisible symbols…basically symbols which do not normally show because some other requirement was not found can be set to be visible to the editor. The search function in nconfig can also find symbols regardless of being selected or not.

I don’t know the meaning of “OTG” in this context, but if I were to take a literal technical meaning, this implies the ID selection pin on a micro-OTG connector for automatic selection between device mode or host mode based on whether a type-A or a type-B micro connector is plugged in. In a stricter sense OTG support is only necessary for automatic selection of cable type to support a hot plug switching between which driver supports that connector (you can ignore the ID pin and just manually switch to host or device mode). The actual driver for what device you are emulating in device mode is what creates the “/sys” content…unless you are interested in just the “/sys” content which works with cable detect. The reason why I’m mentioning this is that some features you find with the OTG label may have nothing to do with the device you want to emulate…in some cases the OTG label may have no other meaning than switching between device and host modes with no relation to the particular driver you want.

5

Thanks for the response linuxdev. I am trying nconfig now with show all enabled.

Would the otg settings in dts fail to create the /sys directory with the default settings?

extcon {
		extcon@0 {
			status = "disabled";
		};
	};
	udc@7d000000 {
		nvidia,port-otg;
		nvidia,charging-supported;
		#extcon-cells = <1>;
		status = "okay";
	};
        otg@7d000000 {
		#extcon-cells = <1>;
		status = "okay";
	};
	xusb_pad_ctl: xusb_padctl { /* Put common control config here */
		nvidia,ss_portmap = <0x21>;
		nvidia,lane_owner = <0xff56>; /* Use 0xF to disable lane assign */
		nvidia,lane-map = <0x14>;
		nvidia,enable-sata-port;
		status = "okay";
	};
	xusb@70090000 {
		/* nvidia,uses_external_pmic;
		/* nvidia,gpio_controls_muxed_ss_lanes; */
		nvidia,gpio_ss1_sata = <0>;
		nvidia,ulpicap = <0>; /* No ulpi support. can we remove */
		nvidia,portmap = <0x0e03>;
		nvidia,common_padctl = <&xusb_pad_ctl>;
		status = "okay";
	};
	xudc@700d0000 {
		nvidia,common_padctl = <&xusb_pad_ctl>;
		nvidia,portmap = <0x0108>;
		#extcon-cells = <1>;
		status = "disabled";
	};
	xotg {
		#extcon-cells = <1>;
		nvidia,common_padctl = <&xusb_pad_ctl>;
		status = "disabled";
	};
6

The relation between a dtb file and the driver is that sometimes the driver can set things up without caring about dtb, but at other times the driver is coded generically to require hardware to already be set up to match what is coded. If in the former case the driver does its own setup, then dtb is only needed if setup is required earlier in boot before the driver loads. In the latter case where the driver expects hardware to already be prepared, then bad dtb setup will cause the driver to not load (or worse).

There is a sort of in-between case as well…if a resource locks in use of some hardware which you want to use, and if the driver does its own setup, then the driver will still fail to load if the other resource does not let go…the first one to lock up the resource wins, and the other driver fails.

NOTE: Don’t forget to see if the initrd needs changes if the dtb is needed early on.

7

Well it seems the port is completely disabled in my situation. I have tried plugging in a usb keyboard to the micro A cable included and nothing happens same goes for a storage device or connecting a pc. I would like to use the port for a standard usb port but seems that I cant get the right combo of defconfig and or dtb. It must be disabled at a level I cant seem to figure out. Ramdisk/initrd works as expected because all other functions for udev and devices are setup properly.

Port USB0 works as expected with tegraflash.py and cboot

I dont see any logs for tegra-otg udc or otg which baffles me :(

I appreciate the help linuxdev. Maybe NVIDIA can chime in here since this issue seems to be discussed all over the forum with various results.

8

Could this possibly be just a simple jumper I am missing? I am using a prebuilt kernel now with OTG support built in and jetson stock DTB and still no /sys/class/android_usb/

This would say that the DTB is the culprit for disabling the USB0 as device otg.

So question is, what is the correct dts setting for plain usb 2.0 otg device mode for connecting to a pc.

9

The micro port is normally configured as host mode. The only exception, if not modifying the Jetson, is in recovery mode. There is an adapter for full-size to micro, and if you look closely, it should say “A” on the micro end (meaning type-A, which implies the cable is connecting a device like a keyboard to the Jetson); alternatively, the supplied micro cable is type “B” (meaning the cable is intended to connect the Jetson to another host for the Jetson to be seen as a device). With the wrong connector type things may work if the port is forced to a given mode, e.g., since the ID pin is not programmed by default, an unmodified Jetson will be a host regardless of ID pin. Once OTG is setup for auto switch that port will work as a host only when devices connect on a type-A cable; and with OTG set up for auto switch, a type-B cable will auto-load the driver associated with whatever type of device it emulates.

So the question has to be considered…is the port forced into device mode or forced into host mode? Or is auto-ID-pin-OTG change configured (you would have had to have configured that)? Assuming android_usb is for a device mode emulation, then device mode is the only way this will show up. In the case of no ID pin setup, that requires manual forcing into device mode. In the case of automatic configuration via ID pin, this requires the micro-B cable to be plugged in…a micro-A would disable this. Are you forcing mode change? Is the cable type micro-B or micro-A? Have you verified if in device mode or host mode?

10

Hi Linux4all,
The steps are for usb 3.0 OTG device mode
[url]https://devtalk.nvidia.com/default/topic/952472/jetson-tx1/jtx1_usb_as-device/post/4937794/#4937794[/url]

Is it your usecase? Or you need usb 2.0 OTG only?

And with 0001-jetson-tx1-xudc-with-usb2p0-ss1.patch, /sys/class/android_usb/ has to be shown up, or we are not able to continue the steps. We have confirmed it working fine on r24.2.1. Could you check again and ensure the kernel gets rebuilt with the patch?

11

Hi Linux4all,

Have you managed to get Jetson TX1 as OTG device mode successfully?

Any further update?

Thanks

12

Yes I actually did manage to fix OTG and I am not sure it was the correct way. I am running android 7.0 on my Jetson TX1 and I had to remove the shim dts includes for otg to activate.

#include "tegra210-platforms/tegra210-jetson-cv-shim-p2597-2180-a00.dtsi"