Hi,
On 28-03-15 18:16, Paul Kocialkowski wrote:
Le samedi 28 mars 2015 à 17:07 +0100, Paul Kocialkowski a écrit :
I've been trying to use the Cubieboard2 USB OTG/DRC port (the mini USB
one) in U-Boot and it seems that VBUS is always enabled on it (by
measuring the voltage on the pin of the mini USB connector that is close
to the ethernet connector, it always reads 5V).
The schematics mention a TCS9708 USB switch for OTG that I cannot seem
to find on the actual board (I see only 2 TCS9708, one for each USB host
port). Hence, I'm worried that the schematics don't actually match the
board and that the OTG VBUS is always at 5V.
The TCS9708 should be controlled by the PB9 GPIO, but toggling it
doesn't change anything. The VBUS detection GPIO (PH5) always shows 1.
Apparently, the TCS9708 is not populated and the resistor marked R93 on
the schematics and R27 on the layout is populated instead (with NC
value).
This sounds like the same issue which I've seen on the cubieboard1,
so it seems that all cubieboards have this issue.
Is this behaviour reproducible on every such board? If so, should we
somewhat bypass the VBUS detection code in U-Boot so that the OTG port
becomes usable in host mode too?
In that configuration, it's probably not very wise to use the board in
OTG device mode.
I disagree, esp. since the device also has proper host ports. As long
as the device is powered via the otg connector (I think this may be done
this way to make that more reliable, no voltage drop this way), then
using the otg port in device mode will work fine, and it is the
most logical way to use the port given that we also have proper host
ports.
Also if the board is powered from what is ultimately the same V5 source
as the one on the otg connector, e.g. using the usb -> powerbarel jack
cable which comes with the board plugged in to the same machine as a
usb -> micro-usb cable used for device mode, then things are fine too.
I think something ought to be done to reflect this in
U-Boot and in the upcoming OTG/DRC Linux kernel support.
The kernel is more problematic since the board switches between host and
device "on the fly" (while in U-Boot, MUSB has to be selected at
build-time so there is no immediate problem for users that use the
provided config as-is).
I think both the kernel and u-boot are problematic here because we cannot
use vbus-detect to see if there is a cable plugged in. I've working on
this for the kernel side of things, to see if I can still get auto
host / mode switching to work, on my todo list but it is not a high
priority item, so it may be a while before I get around to this.
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" 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/d/optout.
