[USB OTG] [11DEC13] [PATCH] Externally Powered USB OTG

[ziddey]

I'm compiling my own. I haven't been able to get your zip file to update framework-res.apk with any of the recoveries (cwm 6.0.2.3 and several twrp versions).

My description works fine, i.e. it says USB STORAGE. The bar below that even seems to indicate that most of the storage is available, but it just won't tell me how much (I know I have over 26GB out of 29.71GB available). Is there something in the storage_list.xml that should change since you posted the "source" a few weeks ago? I mean, I copied that, and I've been using that for my compile. So is there something you have changed in that "source" that I may not have included?

I wonder what the issue is with the script. I'm now running the latest TWRP and everything is still working. Does it create the .1 backups? Add the line to build.prop? It did change your platform.xml, so the script is running..

Not sure about the available storage, especially since you're compiling your own storage_list.xml.

I've made a powered otg cable by modifing a normal otg cable.
I've tested it with this kernel and it sometimes works and sometimes not..

When i use a mouse, it works but sometimes the cursor stops moving for some secs and then it works again..
Mass storages are detected but after some secs they become not accessible...

I don't know if it is due to my bad cable or not, anyway if you have any suggestion i'd be glad to be helped by you...
Thank you.

Sounds like an intermittent bad connection to me. Hell, my microusb port is a whole lot looser now than it was a few weeks ago before I started fiddling with all this

I think you also need to include ALSA support besides USB Audio; audio devices are being detected, but sound isn't being re-routed to them (not even after a reboot), as if there was no audio device priority logic, which I believe is included in ALSA.
I would do some tests myself but I don't have a linux partition right now.

Thanks for helping out!

ALSA support is also already included. I don't know off the top of my head, but I think you might need to do the rerouting yourself? Sorry I don't have a usb dac to test with.

 

[sga999]

ziddey, the .1 backup does get created, and build.prop is updated correctly.

 

[SetiroN]

You're right ziddey, everything is enabled in the kernel, I was erroneously assuming that because audio wasn't being re-routed after a restart (which is the usual behaviour so far on every device that has kernel but not framework support) something was missing from it. After manually checking that everything was in place, (no luck in trying to use the usual linux tools - aconf and alsaconf -) I realised that everything needs to be done at framework level on android. Luckily, the guys over at the Nexus 7 forums have already stumbled upon the same issue and developed a solution:
a windows-based services.jar patcher that includes plug&play support.
http://xdaforums.com/showthread.php?t=2029728
Although being developed with the N7 in mind, of course the relevant section and classes of services.jar are identical, thus the patch works handsomelyy on every AOSP-based jelly bean ROM.
You could put a link to that patch in the OP.

A cleaner solution would be to modify the source, Timur developed a very elegant solution (http://timur.mobi/img/usbhost_screenshot3b.png) but it would be up to ROM developers to include it.

 

[danba]

ALSA support is also already included. I don't know off the top of my head, but I think you might need to do the rerouting yourself? Sorry I don't have a usb dac to test with.

There are some very cheap USB DAC/headphone amplifiers: HDE 7.1 Channel USB External Sound Card Audio Adapter for example
http://www.amazon.com/s/ref=nb_sb_n...sb+sound+card&rh=i:aps,k:cm119+usb+sound+card
http://www.ebay.com/sch/i.html?_trk...&_nkw=cm119+usb+sound+card&_sacat=0&_from=R40

 

[sga999]

ziddey, the .1 backup does get created, and build.prop is updated correctly.

ziddey, I decided to flash the PA 3.15 rom. I have been content with stock for several months, but I was curious to see what would happen with another rom. I'm still using TWRP 2.4.4.0 (which had not "worked" when I was on the stock rom, i.e. framework-res.apk was not updated properly). So...I flashed your latest zip file, and it DOES update framework-res.apk. The "bad string" turns into "ISSUED ON:"

Unfortunately, the "Available" space problem is still exactly the same, i.e. smaller font below it with "Available". I can plug this same micro sd card into the OTG cable attached to a Samsung Galaxy Tab 2 7.0, and it works well. This is so strange.

(ASIDE: Oh, I just saw "disable smilies" in text below about options in sending messages....I could have done that to fix the colon p problem last night!).

EDIT: I recompiled framework-res.apk myself with the correct storage_list.xml, and installed it on the same setup as above, i.e. PA 3.15. Now the "bad string" is correct (now it says "USB STORAGE"), but I still have the "Available" problem.

I'm just going to ignore the "Available" problem for now. But about your 2 issues (usbdisk not working at all or a "bad string" displays), it must be that the .xml you're creating cannot be just inserted into the framework-res.apk. It's like there are some "unresolved linkages" (that's my terminology) in your file that only get resolved by actually recompiling all of the pieces and recreating the apk (I know you are already aware of this problem, but I'm just describing it in my own way) . Whenever I have recompiled, the apk has worked for all roms that I've tried....stock deodexed or odexed, or this new PA 3.15. It seems like compiling and recreating the apk is the only surefire way to get a good framework-res.apk.

 

[sga999]

ziddey, I just finished editing my prior post to give you a little more info, and then I decided to try one other thing. I decompiled YOUR framework-res.apk. This line shows in storage_list.xml:
<storage android:mountPoint="/storage/usbdisk0" android:storageDescription="@string/issued_on" android:removable="true" />

"Issued on:" was the string I was getting when flashing your zip on this PA rom. Maybe you were already aware that the decompile was showing this, and if so, just ignore this.

EDIT: I just noticed that the first line from the decompile of your apk is bad too. Here are both lines:
<storage android:storageDescription="@string/issued_by" android:emulated="true" android:mtpReserve="100" />
<storage android:mountPoint="/storage/usbdisk0" android:storageDescription="@string/issued_on" android:removable="true" />

If I decompile the original apk, that first line has "@string/storage_internal", which is what we expect.

What is even more strange is that my settings - storage screen shows "INTERNAL STORAGE" despite that bad string in the first line, but the 2nd line displays "ISSUED ON:". That really makes no sense.

These strings are in strings.xml. The PA strings file has more strings than the stock strings file, so the "index" to the string points further down in the stock rom strings file (19 lines?), so it must be choosing the wrong string. (In my particular files, the "issued by" does seem to be at about the right place to cause this problem).

I have no idea if this has any bearing, but when I was trying framework flasher weeks ago, I ran across some things I didn't understand.
1. Someone said to do this before decompiling an apk. They said it would install the device's framework to your system. (This is probably completely unrelated to the problems we're having).
apktool if framework-res.apk
2. Someone said that when creating an update.zip, META-INF/com/google/android/update-binary was rom dependent, and "You will need to pull this from a ROM or Theme.zip".

Are you using an update-binary from your specific rom? Again, I don't know what this all means, but maybe each of us would have to have the right one.

 

[simobile]

Slimport and Qualcomm PMIC chips on Nexus 4 support bus powered USBOTG. Even though Qualcomm blows and don't share their datasheets as they should. Information is available elsewhere and can easily be found with some extra digging.

The op here has done a great job in finding a way to get devices identified/connected and now let's get part two working. I don't want to hear that "its not possible". Everything is possible with enough time and patience. So, I'm sure there are many items that need to be looked into for USB bus power output but for now I have found this...

From: https://groups.google.com/forum/?fromgroups=#!topic/android-kernel/B8qgcWjN_G8

Hello,

As per USB compliance update, a device that is actively drawing more
than 100mA from USB must report itself as bus-powered. But currently
in android composite device, the bMaxPower is set to 500 mA and in
bmAttributes, it's set to Self Powered. This is wrong as per the UsB
spec and USBCV throws error as :
A SELF POWERED device cannot draw more than 100ma from the USB bus.
Device consumes > 100ma when SELF POWERED : 500mA

The following patch corrects this.

diff --git a/drivers/usb/gadget/android.c b/drivers/usb/gadget/
android.c
index 5e778e6..d8cf4c9 100644
--- a/drivers/usb/gadget/android.c
+++ b/drivers/usb/gadget/android.c
@@ -183,7 +183,7 @@ static struct usb_configuration
android_config_driver = {
.setup = android_setup_config,
.bConfigurationValue = 1,
.bmAttributes = USB_CONFIG_ATT_ONE | USB_CONFIG_ATT_SELFPOWER,
- .bMaxPower = 0xFA, /* 500ma */
+ .bMaxPower = CONFIG_USB_GADGET_VBUS_DRAW / 2,
};

static int android_setup_config(struct usb_configuration *c,
@@ -273,6 +273,19 @@ static int android_bind(struct usb_composite_dev
*cdev)
strings_dev[STRING_SERIAL_IDX].id = id;
device_desc.iSerialNumber = id;

+ /*
+ * As per USB compliance update, a device that is actively drawing
+ * more than 100mA from USB must report itself as bus-powered in
+ * the GetStatus(DEVICE) call.
+ */
+ if (android_config_driver.bMaxPower <=
+ (USB_SELF_POWER_VBUS_MAX_DRAW / 2)) {
+ android_config_driver.bmAttributes =
+ USB_CONFIG_ATT_ONE | USB_CONFIG_ATT_SELFPOWER;
+ usb_gadget_set_selfpowered(gadget);
+ } else
+ android_config_driver.bmAttributes = USB_CONFIG_ATT_ONE;
+
/* register our configuration */
ret = usb_add_config(cdev, &android_config_driver);
if (ret) {
@@ -296,7 +309,6 @@ static int android_bind(struct usb_composite_dev
*cdev)
device_desc.bcdDevice = __constant_cpu_to_le16(0x9999);
}

- usb_gadget_set_selfpowered(gadget);
dev->cdev = cdev;
product_id = get_product_id(dev);
device_desc.idProduct = __constant_cpu_to_le16(product_id);

I can confirm that sys/bus/usb/devices/1-1:1.8/subsystem/drivers/usb/usb1/bmaxpower is set to 0ma. I don't have my Micro USBOTG here as Ieft it at work. However, i'll change that value and see what happens when I get a chance. I also have an Acer A500 tablet with a full size USB host port. That file is also labeled as 0ma but I think that is because that voltage is always being presented to the port with an on board regulator. It's not asking Android to enable anything. So Android see's the device as drawing 0ma from the power bus.

I'm no hacker or programmer but I'm more than happy to dig in as much as I can. Also, this is just a thought and it might mean nothing. I was bored and I know this can be solved.

 

[ziddey]

That's well beyond where the actual problem is. To start, take a look at msm_hsusb_vbus_power() in drivers/usb/otg/msm_otg.c. This function is responsible for actually enabling vbus power. If you look at the kernel messages, you'll see "vbus_otg is NULL." From here, it simply bails out of the function without actually enabling vbus_otg (obviously it can't and will crash since it doesn't exist). Because of lazy coding, it then just assumes that it is enabled and proceeds (good for us since it continues to enable host mode..).

Chasing the issue a little further "upstream", take a look at msm_otg_set_host(). There's a specific if condition of !machine_is_apq_8064_mako(). That is to say, specifically DON'T set vbus_otg for the Nexus 4.. Talk about hardcoding.. I've played around with removing the if condition, but then it's "Unable to get vbus_otg" and bails out hard, pretty much wrecking otg in its entirety (no peripheral mode, host mode, or hsic).

From here, I believe we need to go up to arch/arm/mach-msm/lge/mako/board-mako.c to see that there is no vbus_otg. It'd be worth comparing with j1 code (Optimus G): http://xdaforums.com/showthread.php?p=39019345#post39019345

It looks like the implementation was more in board-j1.c for the LGOG vs. in msm_otg.c itself for us.

I did try to simply boot the "OptimusNexus" kernel (http://xdaforums.com/showthread.php?t=2175663) but it's clearly incompatible and trashed something in /data that killed wifi. I'm going to make a backup of my /data and then try the whole OptimusNexus and see if that runs any differently. If not, we're probably barking up the wrong tree. So far, it still doesn't seem to be confirmed that host mode is indeed working for the LGOG. Somebody with that phone needs to try it..

 

[EDV11]

As much as I would like to have Slimport + OTG working at the same time, I think it is not possible by design.

Here is the spec sheet for ANX7808: http://www.analogix.com/pdf/ANX7808_PB.pdf. It says

The same connector on the device can be used for USB when a SlimPort® receiver is not connected.

So when slimport is connected, the transmitter blocks the USB signal. I have even tried it to connect to the computer while connected to Slimport (USB from computer-Slimport adapter-phone), but only charging is working.

Also

USB host, device or OTG data passes through by default

OTG goes through by default, but when Slimport is connected, it will switch into video output.

Here is a message from Analogix stating that Slimport and OTG will not work together right now. I tried to get more clarification on this, as they say it is planned but I don't know if it will be available for ANX7808 or it will need a different transmitter (probably the latest).

Now, this is a diagram for the communication

Do you think the configuration for this resides in the Slimport transmitter, or is it inside kernel?

 

[sga999]

ziddey, I've gotten the update zip to work on stock 4.2.2 I changed otgmod.sh to stdout the output of the results of the ./zip command into a file so that I could see it later. Also, I changed the option -rf to -rfv (v for verbose). The output said "res/xml/storage_list.xml up to date."

Then I tried changing the option -rf to leave out 'f' (also with v for verbose so that I could see the results again), i.e. no freshening. That worked for me! I would imagine leaving out the freshening is not going to accomplish what you're trying to do for all cases. But at least this gets around the problem for stock. Maybe someone else who has had problems can give this a try too. (I had been recompiling, so I was already getting around this problem, but I wanted to know what was going wrong).

Has this problem been seen on roms other than stock? I know I could go back through all the posts, but if someone can just tell me, that would be great.

NOTE: This does nothing to fix the problem of the wrong string being displayed instead of USB STORAGE. That's due to storage_list,xml and strings.xml "incompatibility" due to being from different roms.

 

[ziddey]

Huh! Thanks. I'll change that for the next release. I thought about removing the freshen flag anyway now that the script simply assumes the .1 backup is good and doesn't using zip in an if condition anymore (was figuring that might have not been completely kosher). Don't know why that would make any difference though.

 

[simobile]

That's well beyond where the actual problem is. To start, take a look at msm_hsusb_vbus_power() in drivers/usb/otg/msm_otg.c. This function is responsible for actually enabling vbus power. If you look at the kernel messages, you'll see "vbus_otg is NULL." From here, it simply bails out of the function without actually enabling vbus_otg (obviously it can't and will crash since it doesn't exist). Because of lazy coding, it then just assumes that it is enabled and proceeds (good for us since it continues to enable host mode..).

Chasing the issue a little further "upstream", take a look at msm_otg_set_host(). There's a specific if condition of !machine_is_apq_8064_mako(). That is to say, specifically DON'T set vbus_otg for the Nexus 4.. Talk about hardcoding.. I've played around with removing the if condition, but then it's "Unable to get vbus_otg" and bails out hard, pretty much wrecking otg in its entirety (no peripheral mode, host mode, or hsic).

From here, I believe we need to go up to arch/arm/mach-msm/lge/mako/board-mako.c to see that there is no vbus_otg. It'd be worth comparing with j1 code (Optimus G): http://xdaforums.com/show...5#post39019345

It looks like the implementation was more in board-j1.c for the LGOG vs. in msm_otg.c itself for us.

I did try to simply boot the "OptimusNexus" kernel (http://xdaforums.com/show....php?t=2175663) but it's clearly incompatible and trashed something in /data that killed wifi. I'm going to make a backup of my /data and then try the whole OptimusNexus and see if that runs any differently. If not, we're probably barking up the wrong tree. So far, it still doesn't seem to be confirmed that host mode is indeed working for the LGOG. Somebody with that phone needs to try it..

Ziddey, I totally agree.

I looked over those files and they really have borked this thing! The only way to get voltage out that I see is spoofing Slimport to send it. It is already enabled to output usb 5volt, 500ma but the trick would be getting that power but keeping it disabled. May or may not ever happen. My head hurts from looking over so many files. I'm a hardware guy by trade (silicon valley robotics) and software only interest me enough to get my hardware to work the way I want it to. If I run across anything else that may be helpful, I'll post it up here. Keep up the good work!

 

[ziddey]

Where are you seeing 5v 500ma from slimport?

Working with drivers/misc/slimport_anx7808/slimport.c, I've been trying to do some testing to see if I could get enough power to get a usb device working (power from phone, data to computer, since I haven't figured out how to prevent the data pins from being switched for slimport use). I've been able to get 3.1v by forcing slimport, but I haven't tested how much current I can draw before it trips the overcurrent. Of course, usb is 5v, so this requires a device that can either run on 3.1v, or actually is a 3.3v with whatever regulation to step down 5v to 3.3v, in which case it could be modded.

So far, I haven't gotten anywhere. I haven't modded my usb sticks, but they seem to not get enough power. My usb hub seems to trip the overcurrent, losing vbus entirely. I got a few Kingston G2 microsd-usb adapters to play around with ($3 each from http://www.staples.com/Kingston-G2-USB-20-microSDHC-Flash-Memory-Card-Reader-FCR-MRG2/product_651710Staples[/url]. I figure sd is 3.3v/1.8v, so if the controller can work with 3.3v and slimport power can provide enough current, it may be a viable solution (provided we can figure out how to prevent the data pins from switching over).

I remember reading somewhere that the spec for slimport power was 4-50mA @ 3.3V, which may not be enough for sustained operation / initial power-up. That said, a capacitor might allow it to function under most situations..

Anyway, if you want to do some testing, this is the relevant code executed when slimport is connected (slimport_cable_plug_proc()):

sp_tx_pd_mode = 0; // not exactly needed for our purposes
sp_tx_hardware_poweron();
sp_tx_power_on(SP_TX_PWR_REG);
sp_tx_power_on(SP_TX_PWR_TOTAL);
//hdmi_rx_initialization();
//sp_tx_initialization();
sp_tx_vbus_poweron();

The initialization functions aren't required, but the others look to be essential for now. Basically, I commented out the code in anx7808_cbl_det_isr() and stuffed that in its place.

I'm not sure what the slimport resistance between the id pin and ground is, but either way, an otg cable (id grounded) will not trigger the cable detect. Unplugging it will though, so that's what I've been doing to get things rolling. From there, I've hacked up a cable so that the usb port gets power from the phone, but has the data wires going to my pc. Now to mod up one of these things and test it..

 

[simobile]

Slimport is a DisplayPort VESA technology. So it must follow their rules. Your right, about 3.3volts@100milliwatts is what Analogix claims. I'm not sure I believe that current figure as it has to run a dongle IC but whatever. That 3.3volts comes from an onboard regulator on the Slimport IC.I ran into some Slimport power files last night that said it's permitted to receive up to 5 volts from another regulator. Basically, the one that powers the Slimport IC, should be powering our USBOTG.

Not sure if it can be diverted or not.

Thanks for the code. I'll run some test and see what I can come up with.


Lucky Goldstar, she is a cruel mistress.

 

[Kodam]

Ziddey, could you make an otg enabled matr1x kernel?
Franco kernel is really slow for me and reboot really often, but i'd like to use my usb drives.
Thanks,
Kodam

 

[ziddey]

Ziddey, could you make an otg enabled matr1x kernel?
Franco kernel is really slow for me and reboot really often, but i'd like to use my usb drives.
Thanks,
Kodam

All my changes are provided in the 2nd post (github for msm_otg.c). Feel free to apply and compile matr1x kernel with them.

 

[adidas007]

Ziddey, could you make an otg enabled matr1x kernel?
Franco kernel is really slow for me and reboot really often, but i'd like to use my usb drives.
Thanks,
Kodam

+1. I too have no idea about compiling kernels and stuff. Don't want to mess around with this beauty!

It would be really grateful if you could enable usb otg on matr1x kernel whenever you get time.

Sent from my Nexus 4 using xda premium

 

[forcedairinduction]

Ziddey you da man : ). I've been waiting patiently for my y cable to arrive from China (about a month lol). I'd previously bought a5v power pack & today downloaded your kernel & its all worked silky smooth for otg.
Thanks a million mate. It may have been discussed previously but instead of trawling through milliond of posts.....ill ask anyway
Do you intend to make other kernels (particularly trinity & stock carbon) comparable with otg so I don't have to keep re flashing????
Cheeeeers. Mark.

 

[EDV11]

Ziddey you da man : ). I've been waiting patiently for my y cable to arrive from China (about a month lol). I'd previously bought a5v power pack & today downloaded your kernel & its all worked silky smooth for otg.
Thanks a million mate. It may have been discussed previously but instead of trawling through milliond of posts.....ill ask anyway
Do you intend to make other kernels (particularly trinity & stock carbon) comparable with otg so I don't have to keep re flashing????
Cheeeeers. Mark.

You just have to read two posts over yours

Enviado desde mi Nexus 4

 

[forcedairinduction]

You just have to read two posts over yours

Enviado desde mi Nexus 4

Wow just had a look at ziddeys link. Im a Psychiatric nurse, not a programmer unfortunately. It scared the pants off me just rooting phone, couldn't trust myself to do actual fiddling about with it. Its beyond me I'm afraid : (