gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1711
Joined: Sat Sep 10, 2011 11:43 am

Re: Cheap but crucial Model A feature request! Read this.

Fri Mar 16, 2012 6:44 am

So, being the only person on here who has done any OTG work on the BCM2835 I'll give you a definitive answer to your question...

OTG is very very simple, in fact its a big fat cheat...  What happens is when you plug in a special cable the cable is different at both ends (yes that's right they may look the same but they are different, often coloured differently).  The only difference between the two is whether the OTGid pin is wired to the ground pin or not.  This is detected in the OTG controller to decide who is going to 'open negotiations' using the OTG 'Host Negotiation Protocol'...

If you don't care about OTG itself (i.e. you just want to be able to plug in a non-OTG PC) then the only thing you need to do is to remove the power from the VBUS pin (otherwise both the R-Pi and the PC will be driving the line and invariably they'll be driving it to slightly different voltages!)

You can do this using electronics (add a FET to turn off the supply) but it might just be easier lifting the pin on the USB connector or cutting the track on the PCB, or even get hold of a USB cable and cut the red wire (not the blue wire, you don't want to blow us all up do you?)

Once you have done that, it is just a case of changing the Linux driver to enable the device mode and select which device you want your Pi to look like...

As a side effect you can even boot your R-Pi from the USB...  But you'll need a bit of software to do that and you'll have to ask very nicely!

Hope that helps

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

secretagent
Posts: 36
Joined: Wed Mar 07, 2012 10:09 am

Re: Cheap but crucial Model A feature request! Read this.

Fri Mar 16, 2012 7:31 am

Thanks gsh, that helps a lot. So, it looks like my plan should work. Is switching the driver a matter of setting the ForceDevMode flag? It looks like the linux dwc_org driver already hooks into the usb gadget subsystem, so it shouldn't be much work to use it as a device.

gsh said:


As a side effect you can even boot your R-Pi from the USB...  But you'll need a bit of software to do that and you'll have to ask very nicely!


That would be great, if you can share the necessary software.  Does the first stage boot loader support both SD card and booting from a USB host? Or would it need to be re-flashed for this to work?

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1711
Joined: Sat Sep 10, 2011 11:43 am

Re: Cheap but crucial Model A feature request! Read this.

Fri Mar 16, 2012 8:08 pm

The bootrom in the 2835 supports many boot options, but the two enabled are the USB boot and the SDCard boot...

The order is, SDCard then USB boot...  So what happens is:

Enable SDCard, open FAT, read FAT

Search FAT for second stage boot and load and execute...

If fails

Enable USB, Wait for host to enumerate

I love the USB boot, its the one bit I wrote myself from scratch to do the whole enumeration, download the file check signature and run, all in about 2Kbyte of code!  Now that's what I call 'proper' engineering!

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

User avatar
rew
Posts: 448
Joined: Fri Aug 26, 2011 3:25 pm

Re: Cheap but crucial Model A feature request! Read this.

Thu Apr 19, 2012 10:06 pm

My personal guess is that if you connect the usbD+ and usbD- lines of the BCM2835 to the microUSB connector you'd be done. Maybe a strap might need to be added in both lines, so that this option is properly cut off for the model B.

Now connect your RPI to a PC with a proper micro USB cable, and voila: the RPI in device mode on USB.

Normally a host manages to get power from elsewhere. So it needs to disconnect the power when you end up being a device. However this is not the case for the RPI: If it is in host mode you'll still be powering it through the micro USB connector.

The only thing that isn't possible in that case is to have the RPI be USB-Host when you're powering it from a port on a  PC, because then the USB-A connector would be shorted out to the PC.
Check out our raspberry pi addons: https://www.bitwizard.nl/shop/

whitebluff
Posts: 4
Joined: Wed Mar 06, 2013 9:56 pm

Re: Cheap but crucial Model A feature request! Read this.

Tue Mar 26, 2013 9:12 pm

I've a model a board, and I cut off red wire of a usb cable, and configure otg usb port to device mode, but it doesn't work as a device usb. Any suggestion?

cleverca22
Posts: 4642
Joined: Sat Aug 18, 2012 2:33 pm

Re: Cheap but crucial Model A feature request! Read this.

Tue Apr 02, 2013 8:41 pm

secretagent wrote:Hmm, yes, for some reason I thought that the usb controller would switch between regular host and OTG and then when it is in OTG it would do either host or device as per the OTG protocol. However, it looks like it is just OTG and in host mode by default, so maybe the ID pin is grounded on the board. Though, these are just guesses since there is very little about the USB core that is freely available, so if somebody knows better please correct me.

Regardless, it looks like it may indeed be possible to override this pin in software by changing the force device/host bits in the GUSBCFG register of the core, if I'm understanding it right.
ive checked the schematic, on page 3, the USB_OTG_IO pin (K16) is connected directly to gnd

USB_DM and USB_DP go to both the usb hub (ethernet chip) and thru 2 optional 0ohm resistor, to the lower usb port

so to do it 'properly' you would need to cut the trace (is it even a trace?, its more likely directly on the ground plane), and wire it to the 5th pin

to do it improperly, you could maybe force the driver (no idea how the usb core works) and make a pin-adapter that connects only D+ D- and gnd to the right connector

pablocrossa
Posts: 1
Joined: Tue Oct 01, 2013 11:32 am

Re: Cheap but crucial Model A feature request! Read this.

Tue Oct 01, 2013 5:19 pm

I own a Nokia N900. As some of you might or might not know when this device arrived to market it only had USB client capabilities even though the IC (or ICs really) inside of it supported USB OTG. In it the detection pin is not connected to any related IC (i.e. it's "floating"), which always places it in client mode.
After some kernel hacking developers in the forum have gotten reliable switches with software from USB Host to Client. The same can be done with the Pi if a working driver exists in the kernel branch. I only have a model B so I cannot play around with it though. A question:

1) How is the USB power from the Pi wired to the input MicroUSB connector?? I ask because when I was playing around with my Pi I had one of these USB cables that has 3 ends, 2 male and one female, a male and the female ends have all four wires but the second male only has power (i.e. not data); people use this a lot on the N900 to provide additional USB power as it can only output 200mA@5V when doind USB host. The thing is I had NOTHING connected to the Pi's MicroUSB connector and my 3-end cable was configured as follows:
Male WITHOUT data: Phone USB charger thing that you plug in the wall
Male WITH data: One of the USB connectors on the Pi's hub.
Female WITH data: USB 1W WiFi adapter
The funny thing (again, nothing plugged into the MicroUSB on the Pi) is that as soon as I plugged the wallplug in the Pi powered on (at least the power LEDs on it turned on); this leads me to think that to save costs the V+ and GND pins on the Pi's MicroUSB are directly wired to those on the host USB ports. If it is so then you could just plug in the Pi to a computer with a Male to Male and nothing plugged into the Pi's MicroUSB and it should power on without killing any of the devices (someone confirm the wiring is so or link me to some schematics :) ). Again, this is pure speculation.

If not or if you want to plug it as a Client after it's been powered on (to avoid rebooting 50 times a day) then just do as mentioned and cut the V+ or GND (or both really) cables from the Male to Male you will use to connect the Pi to the PC and you're done (a Male to Male is non-conformant to the USB specification AFAIK so breaking it a little more won't really hurt ;) )

Skimming over the USB driver linked earlier in this thread (not sure if it's even the right one) there's a typedef union in dwc_otg_regs.h called gpwrdn_data from which variables such as gpwrdn ar created. It seems that it is in charge of the state of the detection pin (the driver queries several times gpwrdn.b.idsts and the status of other gpwrdn_data variables, the ID pin status, to check if it's host or peripheral).
You might get away with a dirty fix possibly by changing this name to gpwrdn_dataORIG and creating a new typedef struct called gpwrdn_data, add a constructor-like function and some #defines, that would be a very hacky way of 'fixing' the driver, which might not work, and getting the new struct to always return 1 for the b.idsts (peripheral is 1, host is 0 AFAIK). A better fix would of course mean actually fixing the driver up to allow a sysfs parameter and something less hacky than faking a hardware state, but that might just work, someone with a model A can try, your device will always be peripheral/client then :)
(EDIT: Or even better hack around the function that reads the values from hw)

What I'm trying to say is that with a right cable and knowing what you're doing, if someone hacks the existing driver to create a sysfs entry to simulate the change from ID pin to change from host to guest (possibly/probably some more hacking about is needed) then this should be entirely possible and yes, I agree, this is a big + for the Model A Pi, specially if you can power it from the computer without anything else :)

EDIT: Apparently what I said about the wiring is true:
http://www.raspberrypi.org/phpBB3/viewt ... 29#p286429
http://www.raspberrypi.org/phpBB3/viewt ... 31#p286431

albug
Posts: 3
Joined: Mon Dec 23, 2013 10:58 pm

Re: Cheap but crucial Model A feature request! Read this.

Sun Feb 23, 2014 1:54 pm

The Raspberry Pi EVB (Rev B, not sure about Rev A) can be used as a USB 2.0 480 MBit/sec “Device” port, but is not configured as such by default. And, there is no need for cuts and/or jumpers:
1) BCM2835 USB core is a single USB 2.0 480 Mbit/sec OTG port

2) External Microchip LAN9512 chip is used to provide:
a. (1) 10/100 ethernet port
b. USB 2.0 Hub with (2) downstream USB 2.0 480 Mbit/sec ports (not OTG) and (1) upstream USB 2.0 480 Mbit/sec port (not OTG)

3) The S1 USB port is only for power into the EVB (data lines are not connected). 5v@700 mA input power is recommended. This is the single MicroUSB connector.

4) The S7 USB 2.0 port can be used as follows (this is the dual stacked USB connector):
a. Upper USB 2.0 port of the S7 dual USB connector can only be configured as the first USB 2.0 Host port out of the USB Hub (if the USB Hub is enabled)

b. Lower USB 2.0 port of the S7 dual USB connector can be configured as either of the following:
i. Second USB 2.0 Host port out of the USB Hub. R36 and R37 should not be installed. These are not installed by default. They are on bottom of PCB, underneath S7 connector.
ii. Single USB 2.0 statically configured “Host” or “Device” port – Not fully USB 2.0 OTG compliant because it does not have the ability to dynamically control power to the USB 2.0 OTG port (BCM2835 itself does have the ability to control an external power controller, but the external chip and control lines have not been used). But, this is not a problem in terms of being able to use the USB port (straight out of the uC) as either a statically configured Host or Device USB 2.0 port, as follows:
1. “Host” USB 2.0 port:
a. Must use S1 USB port as host power. This power is routed out of the S7 USB connector, as host power.
b. Must disable the LAN9512 USB Hub function
c. Must install 0 ohm resistors for R36 and R37, on the bottom of the PCB.

2. “Device” USB 2.0 port:
a. Must not use or connect S1 USB port as host power. Power is input from the S7 USB connector instead.
b. Must disable the LAN9512 USB Hub function
c. Must install 0 ohm resistors for R36 and R37, on the bottom of the PCB.
d. Do not attempt to enable USB 2.0 OTG functionality in the Linux driver. Simply use a static USB 2.0 “Device” driver.

Return to “General discussion”