To answer my own question, here are the steps to take control of the 
USB1_DRVVBUS signal from user space:

Note: I am using Debian Wheezy (7.2) and Kernel 3.12

1) Ensure you have the device tree compiler patched/built. Do not use the 
apt-get package, instead, follow steps here:
http://www.embedded-things.com/bbb/patching-the-device-tree-compiler-for-ubuntu/

2) Create a .dts file (called 'USBCONTROL-Test.dts' in this example), with 
something like the following contents:
/* Information: 
*/

/dts-v1/;
/plugin/;

/{
    compatible = "ti,beaglebone", "ti,beaglebone-black";
    part-number = "USBCONTROL-Test";
    version = "00A0";

    fragment@0 {
        target = <&am33xx_pinmux>;

        __overlay__ {
            usb_drvvbus_pin: usb_drvvbus_pin_mux {
                pinctrl-single,pins = <
                    0x234 0x07 /* Pin 131 - gpio3.13 */
                >;
            };
        };
    };

    fragment@1 {
        target = <&baseboard_beaglebone_black>;

        __overlay__ {
            usb_power_signals {
                pinctrl-names = "default";
                pinctrl-0 = <&usb_drvvbus_pin>;

                compatible = "gpio-leds";

                led@8 {
                        label = "usb1_drvvbus";
                        gpios = <&gpio3 13 0>;
                        linux,default-trigger = "none";
                        default-state = "on";
                        status = "okay";
                };
            };
        };
    };
};

3) Compile the dts file to a blob with the following command:
dtc -O dtb -o USBCONTROL-Test-00A0.dtbo -b 0 -@ USBCONTROL-Test.dts

4) Copy the output .dtbo file to /lib/firmware:
cp USBCONTROL-Test-00A0.dtbo /lib/firmware

5) Now we're ready to take control of this signal. First, unbind the usb 
driver; this disables all connected devices - this prevents instability 
when cutting the power:
echo '2-1' | tee /sys/bus/usb/drivers/usb/unbind

6) No load the device tree file - this immediately changes the mux 
settings, changing the function of pin usb1_drvvbus to gpio3_13, and 
allowing control of this pin via the led driver:
echo USBCONTROL-Test:00A0 > /sys/devices/bone_capemgr.6/slots

7) Now set the signal to ON (re-enabling the USB Host 5V supply):
echo 1 > /sys/devices/usb_power_signals.8/leds/usb1_drvvbus/brightness

8) Reload the USB Driver for USB1 - this will cause all connected drivers 
to be reloaded from scratch:
echo '2-1' | tee /sys/bus/usb/drivers/usb/bind



On Friday, 17 January 2014 12:01:10 UTC+13, AndrewTaneGlen wrote:
>
> Hello,
>
> With my BBB I've been using a usb wifi device that that appears to crash 
> unrecoverably occasionally, but always works again if I simply unplug it 
> and plug it back in.
>
> With this in mind I've been looking for ways to disable the USB host power 
> output and re-enable it, in order to programmatically reset any usb device 
> I have connected.
>
> Looking at the BBB schematic there is a 'USB1_DRVVBUS' output from the uC 
> which controls the USB host 5V output. Does anyone know if it is possible 
> manipulate this pin as a gpio in order to disable/re-enable the 5V USB 
> output, or is this necessarily controlled by the USB phy, with any manual 
> control breaking the USB functionality.
>
> The document spruh73h.pdf describes how after asserting the 'USB1_DRVVBUS' 
> output the USB phy looks for the 5V to come up, and if not detected within 
> 100ms it flags a fault - possibly once this has been faultlessly enabled 
> this problem is no longer looked for - soed anyone have any idea before I 
> possibly start breaking things?
>
>
> Regards,
> Andrew Glen.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to