USB-C port cannot be used as host

[mvduin]

For some time now I've heard of people who need USB 3 strugging to use the USB-C port, which is the BBAI's only USB 3 port, in host mode (using a charging hub). Recently I finally got around to digging into it, and my conclusion is: it cannot work, at least not if either the BBAI or the hub complies with the USB standard (if both violate USB standard then those violations might perhaps in some cases fortuitously interact to yield a working result, but that's obviously terrible to rely on).

Here's why:

When connecting devices via USB-C, initially one side has to become sourcing host (i.e. host data-role and source power-role) and one side has to become sinking device (i.e. device data-role and sink power-role), or no connection will be established. Becoming initial-host requires being able to supply VBUS power, hence a VBUS-powered device like the BBAI will always initially negotiate device role on connect. Even if the BBAI is powered via P9, it lacks the ability the provide VBUS to the USB-C connector, hence it still cannot negotiate initial host role.

After these initial roles are established it is possible for the devices to subsequently swap data role (i.e. which side is host and which side is device) and/or power role (i.e. which side is source (i.e. supplies VBUS power) and which is sink), which is the only way you can become a sinking host or sourcing device. However, these role swaps can only be done using USB Power Delivery (PD) signalling. Unfortunately the USB-C controller on the BBAI (TUSB322I) does not support PD signalling, nor does its replacement on rev A2 (HD3SS3220), hence it cannot perform a data role swap.

Since the BBAI can neither be initial-host nor perform a data role swap, there is no way for it to ever have host role on its USB-C port. Forcing the usb subsystem into host mode via sysfs will merely cause the BBAI to violate the usb specification and may result in a drive conflict. It does not change the negotiated role, hence it will not result in successful connection (unless the other side also violates the usb specification).

The only real fix is to use a USB-C controller with support for PD communication, specifically data role swap. (Or, in retrospect, another option would have been to use a dedicated USB3 host (instead of the USB2 host port) and limit the Type-C port to USB2 instead of doing it the other way around, since it seems more likely people would want the beaglebone to be USB3 host than to be USB3 device.)

[wiebel]

This make the whole USB-C situation even more ridiculous. Running the BBAI at full speed requires easily north of 2A at 5V which is fine for a USB-C Powersource (although even most Powerbanks are more likely to suport 9V@2A than 5V@2.5A), but in the likely case of using it as a USB client, even my beefy Thinkpad sometimes fails to deliver. So one might like to use a powered HUB, but that leaves us with a USB 3 Type A Port, as true USB-C are not existant as of now, and USB Type A is rated at a 0.9A, while most hubs will deliver 1.5-2A with a reasonable voltage Ddop, at times (boottime to be precise) the voltage browns out rebooting the BBAI. Learning that it will also not work as a host, which could be done as most USB-C Hubs feature a USB-C power input, makes one really wish to have the good old barrel jack back. To sum it up: To use USB 3 at all it must be powered via P9.
Note that the preinstalled debian comes with an older kernel having a 400Mhz mode available, which uses less power at the cost of beeing unbearably slow.

[vvv-ca]

You just need a splitter cable to provide power externally (or from the other USB port - lots of those online for use with smartphones and power banks) and it works just fine. You might have to wait for the attached device to reconnect if you restart the BBAI since the vbus won't loose power but it usually takes less than 10 seconds.

[mvduin]

You just need a splitter cable to provide power externally

I'm assuming you replied purely based on the subject instead of actually reading the post, since this is an awful "solution" for something that is not even the problem under discussion in this thread. I was already assuming the connected device supplies power, typically by using a charging hub/dock, since otherwise the BBAI obviously doesn't have power. There is no way to make a USB-C "splitter cable" unless either

1. there's actually a whole bunch of electronics in the "cable", or
2. the cable is a blatant violation of every relevant spec, only works in limited situations with certain devices (rather than consistently and reliably), sabotages the overcurrent protection and other safegaurds designed into the usb standard, and probably risks damaging devices.