Jetson TK1 USB OTG on L4T kernel

Is it possible to enable Jetson TK1’s USB On-The-Go feature on L4T kernel?

I’m running a custom kernel with Android features enabled, and want to run adbd on the device in peripheral mode. Currently I fail to get any response from the device or the host on connections over a micro-B to standard-A cable.

Given that I can successfully recover the device using the same connection, I assume there’s no flaw in the hardware design, and it should work also on an L4T kernel with correct drivers/configurations.

However I found a change in the git repository saying “disable usb device mode”. Is there any reason for denying that ability to Jetson TK1 (PM375) ?

http://nv-tegra.nvidia.com/gitweb/?p=linux-3.10.git;a=commitdiff;h=8d2d72cbc67e7a2b23e2b1ae1e90ef619617f701

I’ve checked the PCB schematics at https://developer.nvidia.com/jetson-tk1-support . Aparrently the USB0’s ID/VBUS signals are connected to AS3722 chip. In the kernel they’re handled by “as3722-extcon” or “power-supply-extcon” on Ardbeg based boards. Is it correct and known to work on Jetson TK1? It’s hard for me to examine it because detail info/spec/datasheet on AS3722 or Tegra K1 or Ardbeg are not available.

I appreciate whatever information or hint. Thanks!

Not really an answer, but perhaps of interest. FYI, I’m not familiar with any kernel code in standard linux distros which deal with OTG modes (and L4T is just embedded standard Ubuntu). If someone knows of kernel options to work with OTG I’d love to experiment with this.

You essentially have a physical connector which allows you to plug in either an “A” type connector, which will accept common things like a mouse or keyboard, and also the ability to plug in a “B” type connector, in which case the Jetson itself would become a device which is no different than something like a printer or external hard drive. What kind of device it becomes depends on programming. During reset for flash, device mode is the only mode it has, and it becomes a custom device capable of debug type interactions. During normal boot, after the linux kernel takes over, OTG on hardware capable of this (and Jetson hardware seems capable of this) would have to be monitored by the linux kernel for connector types and connector type change. Software or drivers put in place to hot plug mode change would switch driver mode and inform programs dealing with it to change as well.

Supposing the kernel did have software in place for device mode, and is able to switch to device mode, it could become almost anything. E.G., it could become a router, a multimedia server, so on. I suspect that because of the way smart phones have worked that people think OTG means access it as a hard drive or memory device for file copy. You could do this, e.g., reserve a place on the eMMC or an external hard drive for file sharing, but there is a lot involved in this.

Linux traditionally started out as a desktop computer for most people, or as a server. Desktop boxes and servers have rarely come with USB connectors for type “B”, so you won’t find much to do with this unless you go to Android, where smart appliances often do this sort of thing. This is one of the points of distributions like Android…drivers for hardware commonly installed on smart appliances, as well as user land software to use those drivers. What you might really be asking are these two questions: (1) Are there standard kernel drivers which work with understanding and signalling for changing between type A and type B connectors, and (B) are any of the programs for device mode operation on Android ported to other linux distributions?

linuxdev, thanks for your comment.

Actually, my target is an Android, not a standard Linux distro like Ubuntu. I’m running Android userland on Jetson TK1 with an L4T kernel and it behaves like an almost complete Android. The OTG feature with adbd is a major missing part of the system, it’s mandatory for further Android development.

I know that tegra drivers in L4T kernel support OTG with some blessed platform like Ardbeg (NVIDIA’s Android devkit). What I want to know is whether or not it can also support Jetson TK1, and the hardware is really capable of it.

For example the driver needs to sense USB’s VBUS voltage changes to switch it between device and suspend mode. I want to check it’s routed to correct device pins (AS3722 ADC or Tegra K1) as assumed in the driver.

The schematics are given, Tegra K1 Technical Reference Manual is also given, but there’s no info on other core chip’s functionality (like AS3722) or detailed hardware wiring (to which K1’s ball is USB0_VBUS connected?). I’m asking for clues or hints about the information not publicly available.

Can you Please tell me how did you get Android userland work on Jetson tk1? I’m a Linux user for few months and quite a newbie with embedded. Thanks!

You’re ahead of me, but I’m interested in similar information as I’m trying to develop some custom USB hardware and software for Tegra in general (Jetson just lets me test some things not possible in earlier Tegra).

I’ve noticed much more detailed information for Tegra 3 in areas relevant to this, but not found this for Tegra124. Even so, I would not be able to use the pre-existing USB functionality for what I’m working on. If you find answers I hope you add them to the forum. I do suspect that somewhere there is a register which could be tested for every conceivable USB hot plug possibility.

Did you ever figure this out? I’m trying to load the ethernet gadget driver on my Jetson. When I plug a micro-a connector, I get prints saying otg is on and that it has gone from suspend->host. If I plug a micro-b, nothing at all happens.

If you attach a “device” (such as ethernet) via micro-B, then you have essentially not connected it. You would have to use a “micro-A” instead. The cable coming with Jetson is only for recovery mode, which is type micro-B. This would be true regardless of whether Jetson has L4T or Android on it.

I tried A <-> micro A and A <-> micro B, and thought that plugging micro A to Jetson would make it a host, while plugging a B would make it a device. And, Jetson did end up saying it was host. Could it be that I need a “proper” A <-> micro B cable?

Indeed, using a type A makes Jetson a host, and type B a device. But this is just hardware, with no software. Basically you also need a kernel driver for each mode.

Drivers to make Jetson a host have been in place a long time and are there by default on Jetson kernels. Drivers to make it a device pretty much must be created, as the only device software which currently exists (that I know of) is recovery mode…but booting normally this isn’t loaded, nor would that be useful in a normal boot. Being in device mode only makes it possible to turn Jetson into a device…but it isn’t a device without that driver. What exactly do you want Jetson to be in device mode? Perhaps knowing that would make it easier to find out if any drivers exist.

Thanks for the good replies.

What I’m trying to do is networking over USB by using usbgadget (g_ether.ko).

I see some references to g_ether.ko in the R21.4 kernel (probably the same in earlier R21.x). So kernel support is probably there to be added as a kernel module, but I don’t know what user space software might be needed. Unless someone has the specific device or you have a specific setup issue it’ll be hard to provide useful information.

Understandable. I should be able to debug/patch kernel issues myself, so the most important thing for me is to make sure I’m using the right type of cable, and that there are no physical/hw reasons that otg should not work on Jetson.

Any “type B” connector on the micro port should work if other OTG requirements are met. This includes the cable shipped with Jetson, which uses OTG device mode during recovery. This also assumes you have actually found a way to boot with the port being OTG instead of host.

Keep in mind that if you have a piece of USB hardware that plugs into Jetson through USB, and which is able to emulate OTG, that the Jetson itself would still require normal “host” mode and a “type A” connector…the OTG would be performed by the attached device and not via the Linux kernel (although it may require kernel driver support, the port on the Jetson would remain in normal host mode).

If I boot without any cable connected, Jetson will say this:

334:[ 0.858767] tegra-otg tegra-otg: otg transceiver registered
478:[ 4.565161] port_otg: no
500:[ 4.706975] port_otg: no
532:[ 4.925268] port_otg: yes
565:[ 5.139049] otg state changed: SUSPEND --> PERIPHERAL

So it seems it knows something about otg :)

I’ll keep debugging and report back here if I figure something out.

I digged out an old Wandboard and attempted the same task there. That worked without problems, so there is something missing on my Jetson-side.

This works for me on L4T now. I was missing just one simple command:

echo connect > /sys/devices/platform/tegra-udc.0/udc/tegra-udc.0/soft_connect

In addition I learned that I can control host/peripheral state with:

/sys/devices/platform/tegra-otg/enable_host
/sys/devices/platform/tegra-otg/enable_device