Cheap but crucial Model A feature request! Read this.

[Cigue]

The BCM2835 has a single USB port controller that allows for On The Go operation. OTG is unavailable in the Model B, with good cause: the USB port is already taken by another chip that provides two USB ports and ethernet (!!!).

The way I understand it, the Model A will not have this chip, which makes it possible to run OTG USB. There's a problem, however: OTG connectors have 5 pins and are not compatible with regular USB sockets.

It would be ludicrous to ask you to replace the Model A's sole USB port with an OTG 5-pin port, however there's something else that you can do: just route the fifth pin (ID pin) right next to the GPIO/UART/SPI/I2C… pins. That way, regular folks get their USB ports, and hackers can build an OTG port if they so please.

Why is OTG so important?

Maybe you've heard about, run into or used the Arduino. It's a small platform for developping electronics with a rudimentary computer in its middle. Despite the fact that the Arduino microcontroller is orders of magnitude less powerful (and harder to use) than the Raspberry Pi, it sells a lot of units because it's currently the best option for DIY electronics enthusiasts. The Raspberry Pi will surely change this, but so far there's a caveat: the Arduino can be used as a class compliant USB device with ANY computer, while the Raspberry Pi can't. This means Arduino and Arduino-like boards can be used as computer mice, printers, keyboard, musical instruments, joysticks, etc. while the Raspberry Pi can't.

But you know what? All that could be fixed with a single PCB trace.

I'm a software engineering student at McGill University, and I spent the night developping a custom kernel for the Raspberry Pi in order to use it as a MIDI Controller. Imagine my frustration when I found out that the current model doesn't make use of the Broadcom chip's OTG capabilities.

Thank you for reading!

E: I feel like I should mention that there is a work-around to this (assuming you don't add the trace), but it is expensive, unreliable, complicated and generally "ghetto"/hacked together. Basically, take an Arduino-like controller such as the Teensy ($20) loaded with the LUFA stack. We can communicate with it via I2C or another such protocol, and use the controller's USB port to provide Device functionality. This is however complicated and inconvenient.

[jamesh]

Unfortunately there will be no PCB layout changes for the Model A in the near future. Its also the same PCB as the model B - making change on one would therefore affect the other, which would be a problem.

I can see your reasoning, but, Sorry!

[Cigue]

Oh, I guess that my groundbreaking product will have to wait then

But would it truly be a problem to do the same modification to the Model B? After all, the ID pin isn't used in the Model B, meaning that routing it somewhere else wouldn't change anything.

[jamesh]

The redesign of the PCB is the main problem.

And there is also a problem with the OTG driver of the SoC. Not sure there is one for Linux yet.

[Cigue]

Given the right documentation, I would be more than glad to write a driver.

Otherwise, I understand your reasoning and hold no grief. However, please note this down for future iterations - this small modification could open a whole new market to the RPi.

[mole125]

My plan is just to have a small daughter board with a USB capable PIC chip on it as a pretty dumb USB->SPI converter and then let software on the RPI do all the USB device emulation as is desired.

While native support for device mode USB would be nice the above approach has the advantage that it will work for all versions of the RPi

[nullstring]

If I understand this correctly, the 5th pin is used to differentiate between client and host mode.

You could easily just hookup a 5pin usb port, and put the extra pin to a GPIO, couldn't you? (I guess you just want to avoid some extra hookup wire, etc)

[Gert van Loo]

We have used the BCM2835 in OTG mode and yes it supports OTG from the protocol side. But on OTG requires another external device between the BCM2835 and the USB bus which I think does some analogue switching/detection. I never looked into the details but the BCM2835 development boards has on of these on it. I don't have the data available here at home.

[drgeoff]

nullstring said:


If I understand this correctly, the 5th pin is used to differentiate between client and host mode.

You could easily just hookup a 5pin usb port, and put the extra pin to a GPIO, couldn't you? (I guess you just want to avoid some extra hookup wire, etc)


Perhaps cique's request is not quite what you think.  Possibly the SoC pin is needed to differentiate between client and host mode, and is currently inaccessible underneath that BGA device.  Anyway it is a moot issue unless Gert's thinking about an extra analogue device being required turns out to be incorrect.

[nullstring]

Oh, perhaps you are right. That makes more sense than what I was thinking

[secretagent]

The drivers appear to be already there: https://github.com/raspberrypi/linux/tr ... st/dwc_otg

About the hardware side - I don't pretend to know anything about USB OTG but from a quick look at the specs it seems that on the device side the ID pin needs to be floating and on the host it needs to be grounded (if the host is in OTG mode at all). So, if the SoC's ID pin is not connected to anything shouldn't that be enough to use it as a USB device in OTG mode and connect to a USB host (which doesn't have to be OTG)?

As for the external device between the SoC and the bus: what is that needed for? Shouldn't the USB hardware itself support switching between regular USB and OTG mode? Or am I missing something?

[mole125]

I've not looked at it closely, but from what you have said the purpose of the extra pin is to allow  device selection of which end is master/slave. From the little I have read OTG means that there is effectively two USB stacks implemented - the host and device stack, the extra pin is used to select which one it is. I would imagine that it is also possible (perhaps with a bit of coding) just force the stack into one particular mode, by default this is the host stack, but with a bit of twidling I'd expect it would be possible just to force it into slave mode through software. You only need true OTG functionality support if you are actually expecting to switch dynamically between modes - if needed this could just be achieved by a button on a GPIO instead.

[secretagent]

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.

And about the extra device I'm guessing it may have something to do with the extra handling of the VBUS line that needs to happen in a true OTG scenario and possibly with where the data lines are pulled (high or low, which is different depending on whether it is host or device). Maybe Gert can shed some light on that.

An the big question is, assuming you don't need true OTG but just want to force it to behave like a device and connect to a regular (non-OTG) host, is it possible to do it with the current hardware setup, only by changing the driver to force device mode.

[meltwater]

Will be truly impressive if this can be done, OTG operation opens up a number of very useful applications.

[abishur]

There is another thread on OTG (Located here) on that thread Gert posted the following



There was a thread somewhere here about Raspi and OTG and I said we needed a extra chip. (I can't find the thread any more. Sorry too busy to search long)

I have asked what the chip was: It is a USB bus power switch. For OTG if you are a master you have to put power on the USB bus. If you are a slave you should remove the power. The BCM2835 supports the protocol but has no USB power switch so you have to add an external chip for that and you have to control that.



Translation: OTG is a no go.

[Ferret141]

I'm a total novice. But could you solder on/patch in a USB power switching chip?

[abishur]

I fear that's outside my knowledge base.  The only hiccup in that that I can see is that you would probably need to attach it to specific points on the SoC itself.  Assuming there were spots on the bottom representing each pin of the SoC *and* you could find out which pins you needed to solder to, it would still be an insanely difficult process to solder the correct pin as the pitch being used is very, very small.

[Ferret141]

Trying to patch something onto a BGA would be near impossible for anyone.

[secretagent]

So, yes, true OTG is not possible with the current boards but that is not much of a surprise and the question (at least for me) is not whether you can do actual OTG but whether you can force it in device mode an connect it to a traditional host. And from what I understand the issue is the VBUS line. But how is that connected on the board? Does it just go the the 5V? If so, and if you were to connect a cable from the regular USB port on the board to a regular power-supplying USB host (and of course you don't connect anything to the micro usb port), then wouldn't the board just get powered by the USB host and work fine?

[Cigue]

You can't force device mode USB without either USB OTG or USB Device hardware. The Raspberry Pi chip has OTG capabilities, but unless the Powers That Be take notice of this suggestion it's locked as an USB Host device.

[secretagent]

Cigue said:


You can"t force device mode USB without either USB OTG or USB Device hardware. The Raspberry Pi chip has OTG capabilities, but unless the Powers That Be take notice of this suggestion it"s locked as an USB Host device.


Are you referring to the issue with the ID pin? According to the datasheet, the USB core is "Synopsys DWC_otg" and while I cannot access the specification from Synopsys themselves (they want a license code of some sorts), the registers descriptions are available in datasheets of other SoCs which appear to use this core. For example this: http://www.tracermcc.ru/foto/b.....8_0902.pdf In there for register GUSBCFG you have bit ForceDevMode which says: "Writing a 1 to this bit will force the core to device mode irrespective of utmiotg_iddig input pin.".

Also, it appears people have been successful in forcing this core in a particular mode, although what I've seen seems to be the other way around – it appears to be used in some phones with a default of device mode and they force it in host mode to connect devices to  the phone.

Or are there other hardware issues in this case? (ignoring the VBUS one for now, which in the worst case can always be resolved by using a custom cable)

[Cigue]

Only the ID pin is an issue here. The hack you mentioned probably isn't possible in reverse because of quirks with the USB OTG specification.

I'll probably end up programming a small microcontroller to act as an adapter. Disappointing...

[secretagent]

Well, given that there is a flag in the register that is supposed to resolve this exact problem (forcing the core in device mode ignoring the ID pin) I think there is some hope at least. But you may be right, I don't know. Anyway, I plan on trying it once I get a model A board and if I have any luck I will post here (if somebody else hasn't by then).

[gsh]

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

[secretagent]

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?