Database Develop

[TT] Peripherals possible?

While looking around my phone I came up with a couple of thoughts. First would it be possible to make devices that plugged into the miniusb port on the top of the phone and could it be plug and play? Heck maybe even make the driver if necessary built into flash memory on the new device. It seems like it just takes an kernel update to make something like this possible if it's not already.
The second thing I thought of is if the above isn't possible, why not create an attachable mirror that sits at the right angle to take advantage of the rear camera for video chat. You could project your image onto the mirror and the camera could catch that. The top idea is alot better, the bottom requires alot less knowledge. Either would get us video chat.

Interesting, i like the first idea.

I like the first idea, though for video chat I would rather someone figured out where to pick up the actual modual that goes inside the phone (there's a thread about how they left the mounting brakets in place for the front cam.)
However for other things, like maybe a gamepad+extended battery combo, or an IR blaster to operate my TV

q426669 said:
I like the first idea, though for video chat I would rather someone figured out where to pick up the actual modual that goes inside the phone (there's a thread about how they left the mounting brakets in place for the front cam.)
However for other things, like maybe a gamepad+extended battery combo, or an IR blaster to operate my TV
Click to expand...
Click to collapse
This is the thread you were talking about.

From what I understand about micro usb is that there are five wires/confections. The outside connections are ground and power. The two next to the ground are for data (one + and one -) and the last one next to power is a identification connection. If the wireis connected/has power then its a source device (i.e. computer). If its not, then its a peripheral (portable hard drive, out in our case, our phone). Its been a bit since I read up on that, so it might be vice versa.
Last time I tore the phone apart, I didn't look, but it may be a setting that is hard-wired (literally), or its a switch controlled by software. If it's the latter, then its possible, if its hard wired, then its not.
Adding things to the kernel or loading drivers isn't cut and paste. It takes available source code, which isn't always available, for both the phone and the device you want to use (that works with android), as well as understanding of how to make it work.
That last part I am not well versed on. But we have a couple devs trying to get the vibrant opened up. They are few, and the request list keeps getting larger.
Sent from my SGH-T959 using XDA App

I was just thinking today that it would be great to have a micro-usb device that could house a camera for video chat... I like your mirror idea...I'm prius owner and that's how the dashboard works. The usb is right there...really I think someone should incorporate a device in a mod of the back cover...i don't know anything about code but I could make the case.
Sent from my SGH-T959 using XDA App

Devices require a driver of some kind so the controller knows how to talk to device. For example, if I wanted to hook up my DSLR and control it, I would need a driver ported over and then the SDK for the camera would have to be ported over. An OS like Windows 7 has literally thousands of drivers built in and many other devices require you to install a driver. The only time "plug and play" actually works is either with the OS has the driver already installed or if the device is designed around a generic driver.

Incredible idea! I'm going to make the second idea. I have my own twist on the concept but it shouldn't be to difficult.
Sent from my SGH-T959 using XDA App

I like the first idea but I also had a similar idea and I'd like to see the attached camera come with led's and somehow acct as a flash for both cameras. It could be tiny, if the camera app could be figured out to trigger the flash on all galaxy s models, well at least the vibrant and captivate this could sell.
If a third party app was developed it could be added to any android phone in theory. If that third party app was as good as the galaxy s stock camera app then you'd really be in business.
If I was talking to my brother I'd have tried to convince him to help me develope something. Well I hope one of you talented devs has success with this idea. I'd also like to see success with the guy adding the extra camera internally, I'd be interested in performing the mod if the software end is figured out.
Sent from my SAMSUNG-SGH-I897 using XDA App

I can take or leave peripheral support, but I'm DYING for USB host mode!

cashless said:
I can take or leave peripheral support, but I'm DYING for USB host mode!
Click to expand...
Click to collapse
That's the thing, devices that support USB host generally don't use a mini/micro B port. They have specific ports for that. Of course, the USB controller in there may well be able to be a USB host, but we don't know how to enable that from what I have seen. IF the controller can be put into host mode, loads of options like this become possible. It would require kernel mods, but that's not a huge deal. However, as long as we are in USB client mode, the only things we can connect to the port are chargers and computers, as that's all the phone knows how to deal with.

ttabbal said:
That's the thing, devices that support USB host generally don't use a mini/micro B port. They have specific ports for that. Of course, the USB controller in there may well be able to be a USB host, but we don't know how to enable that from what I have seen. IF the controller can be put into host mode, loads of options like this become possible. It would require kernel mods, but that's not a huge deal. However, as long as we are in USB client mode, the only things we can connect to the port are chargers and computers, as that's all the phone knows how to deal with.
Click to expand...
Click to collapse
That is exactly what I was trying to say earlier. You put it in better words. Thanks
Sent from my SGH-T959 using XDA App

almyz125 said:
This is the thread you were talking about.
Click to expand...
Click to collapse
Ahhah, I couldn't find it to save my life last night lol! Thanks ^_^

Makes me wonder if you can still take power off of the port and communicate to the device via blue tooth. But I don't think it would come to that.
Sent from my SAMSUNG-SGH-I897 using XDA App

Dani897 said:
Makes me wonder if you can still take power off of the port and communicate to the device via blue tooth. But I don't think it would come to that.
Sent from my SAMSUNG-SGH-I897 using XDA App
Click to expand...
Click to collapse
??

ttabbal said:
That's the thing, devices that support USB host generally don't use a mini/micro B port. They have specific ports for that. Of course, the USB controller in there may well be able to be a USB host, but we don't know how to enable that from what I have seen. IF the controller can be put into host mode, loads of options like this become possible. It would require kernel mods, but that's not a huge deal. However, as long as we are in USB client mode, the only things we can connect to the port are chargers and computers, as that's all the phone knows how to deal with.
Click to expand...
Click to collapse
Oh, it's host mode built in already. One of the major pluses that I weighed in on when buying the phone.
"Both the S5PC110 (smartphone chipset) and S5PV210 (its netbook alternative) are optimized to ensure long battery life for mobile devices, using a 45-nanometer (nm) Low Power fabrication process and low power architectures. With the 1GHz clock speed and 512KB L2 cache, these processors should also manage to provide performance unknown to the ARM world so far.
The two processors have built-in 3D graphics engine and support 1080p full HD video playback and recording at 30 fps. The final nice features of the new chipset include a wide variety of interfaces and peripherals, including HDMI 1.3and USB 2.0 host interface."

Hate to kinda go off topic with the USB Host mode stuff again, but it seems like since the interface is built into the chip, host mode should be enabled in the kernel.
Yes? No?
Has anyone tried to get an OTG cable in there to see what happens?
Just saying.

I've been curious about this since I saw it done (rather impressively) by sonic7406 (YouTube) on the Nexus One. Since then, I hear it's also been hacked on the Droid. From my research, I'm pretty confident this should be possible with the right drivers installed on the Galaxy S series. I've gathered together an (supposedly) OTG "compatible" cable (the Nokia CA-101 for Nokia 6600 Slide/N900/etc), an extra-beefy powered hub, and female-to-female USB-A adapter. I have yet to dive into the kernel to load any special drivers, try mounting drives, etc. I'm still unsure of the "OTG" cable and may still need to manually ground that fifth pin to kick it off. Though, as far as the cable is concerned, that is the only thing that makes it OTG on one end.
Host Mode Background Info: OTG Wiki
Here's a modoco thread that includes most of the relevant links I've seen.
Ideally, I'd like to find a microUSB to USB-B OTG cable that connects directly from my phone to the powered hub, but I couldn't find any. Let me know if anyone knows where we could find these.

It seems like we could create an entire new category of toys to attach to our devices if the micro USB port could be figured out. To me that's ultra exciting!
Let's go a few steps further, Being able to physically attach a printer or hdmi (Yes, I know about AllShare) to the tv could require a simple adapter that plugs into the micro USB port on the handset. We could also have a nice flash that has brackets that mount to the handset for support to get better pics in low lighting (instead of just saying "oh, I've got night mode", bugger that).
The capability to do this has to be written at the kernel level and then we need hardware manufactures willing to make the products. Therein lies the problem, how do we get that to work?

My neighbor is an electronics engineer and I'm a machinist, my friend is a tool and die maker.
My neighbor has an idea to make a device for surface mount soldering using an inert liquid with a boiling point equal to the soldering temp. This would be a cheap alternative to infrared soldering.
Other than that I might be able to come up with a housing.
I wouldn't want to commit myself untill the software works and we've tested the soldering machine.
Sent from my SAMSUNG-SGH-I897 using XDA App

tools needed to unbrick G1

Hey guys,
Im looking to unbrick my G1 (no bootloader). I have asked some questions previously but haven't had the time to do anything besides that up to now.
I haven't had any luck here in India locating what I need with confidence, but today I happened across a helpful website.
Could anyone tell me if this is what Im looking for?
wiggler-clone
robokits.co.in/shop/index.php?main_page=product_info&cPath=12&products_id=240
pc-serial
robokits.co.in/shop/index.php?main_page=product_info&cPath=6_64&products_id=64
The wiggler look-a-like says its compatible with GCC OCD.
The pc-serial page offers a driver under the name of pl230.
I am hoping to be able to follow the unbrick page here: wiki.cyanogenmod.com/index.php?title=JTAG_for_Dream/Magic
Thanks

The unbrick process originated on this forum and was really moved along by member ezterry. You really ought to read the threads here in the dev section about this. They do tend to be long, but there is every bit of information you could possibly want to know about unbricking a dream.
http://forum.xda-developers.com/showpost.php?p=5911627&postcount=302
http://forum.xda-developers.com/showpost.php?p=5934885&postcount=6

thanks for the links. i am currently working through the multitude of posts.

Hey,
I am learning a lot and have what i think is my last issue before i order some parts. The pc-serial cable should be at 2.8 v but i only have access to converters that give 5 v output.
I first consulted the datasheet for the pl2303hx (link provided above) which states:
"RS-232 VDD. The RS-232 output signals (Pin 1 ~ Pin 3) are
designed for 5V, 3.3V or 3V operation. VDD_232 should be
connected to the same power level of the RS-232 interface.
(The RS-232 input signals are always 5V~3V tolerant.)"
which was a little confusing, so i consulted the vendor:
"It will output 5V if the jumper is shorted or else it will be 0V. But the unit is self powered and can accept 3.3V input and output levels.
which is self contradictory. but, from what i gather, the serial output will be the same as the usb input.
Lastly, from this google group discussion:
groups.google.com/group/android-platform/msg/bf66abf4515132fb
Someone states that they used an lm317 circuit to drop voltage to 2.8, and it seems like this is the route ill take.
Question is, which voltage do i control? I think if i drop usb vcc voltage i should be good?
I think i just going to buy it and see, whats 400 INR anyways (its like 8 bucks)

salsavirdi said:
"RS-232 VDD. The RS-232 output signals (Pin 1 ~ Pin 3) are
designed for 5V, 3.3V or 3V operation. VDD_232 should be
connected to the same power level of the RS-232 interface.
(The RS-232 input signals are always 5V~3V tolerant.)"
Click to expand...
Click to collapse
If you can't understand that, then you should find someone to assist you who does.

I suppose im being a overly paranoid, and would like some corroboration. Id really hate to fry my phone, im rather attached to it.

[Q] Micro USB to HDMI solution?

The possibility of the micro USB to HDMI capabilities have been discussed to some extent on these forums but this seems to have slipped through the cracks. I don't know if this has actually been tested yet but I'd figure it should be an easy thing to test for our custom kernel modders.
zulu99 said:
Inspecting the source code froyo 2.2 of galaxy s, the sii9234 driver for hdmi output is not compiled.
This driver is compiled and work in the galaxy tab. the probe of this is the fact that if you see the dmesg log you can see the sii9234 loaded and work.
Can our developer see the dmesg of galaxy s and confirm that sii9234 is not loaded ?
If it is not loaded can our developers compile this driver inside the kernel of galaxy s.
i don't know how to compile the kernel but for a developer is simple to include this driver, you can copy the line relative to SiI9234 from config of galaxy tab and past in the source code of galaxy s.
both source code have the file MHD_SiI9234.c relative to the sii9234 transmitter for the hdmi output produced by silicon image
Click to expand...
Click to collapse
As we actually have some people on these forums with the micro USB-HDMI cable, I think this should be explored unless it's already been tested or in some other way proven that it's simply not possible.

It's been proven to be impossible already. There's no wire connecting the usb to the display port (I think I worded this incorrectly, but essentially I am trying to say that it's physically impossible without welding an extra wire or two).
Edit: Wait. Re-reading the usb to HDMI thread in accessories again. Was the previous information false?

Thread moved to Q&A.

Is there anyone who can do one of the following???
- Point me to a HOWTO on how to check out and build an android kernel? I can build linux kernels no problem, in fact I have built my own distribution from scratch. But finding and building the SGS source is a nightmare, I have spent way too many hours on it already.
- Get a kernel developer to build SiI9234.c?

[KERNEL] (Patch) USB OTG (host mode) + simultaneous charging!

(I really struggled with where to post this. Although much work and effort went into debugging unique Z5-specific issues, this is based on prior work so I put it here instead of in "original"; also, I would be very surprised if this didn't apply cleanly and work across the entire Z5 family, not just the Compact, but it might not apply beyond the Z5 so it doesn't make sense to put it in the cross-platform forum, which means I had to pick ONE Z5 family forum to post in. I've only tested on Compact, so I guess it goes here for now.)
I am attaching a set of kernel patches that will allow Z5 users to put their phone's USB port into host mode while simultaneously also allowing the phone to take a charge. In this scenario, the USB device(s) connected to the phone are not getting power from the phone like they normally would in a standard "OTG" scenario, but are sharing with the phone whatever power source is being used to charge the phone.
Acknowledgements:
HUGE thanks...
...to @ziddey for his original patch that he developed for the Nexus 4 which was the inspiration behind all of this,
...to @sollapse for being the first to successfully implement ACA support in the DWC3 driver,
...and to @Phoenix Wright for further refining that code
The patches presented here are based largely off of Phoenix Wright's work.
Background:
I used a Nexus 4 for a long time, and grew accustomed to being able to do this with my Nexus thanks to @ziddey's extremely clever hack. (My personal use-case is a phone dock in my car which both charges the phone and connects it to a USB sound card, which in turn is fed into the auxiliary input of my car's stereo head unit.) In fact, the modification ziddey came up with was both so effective and minimally-invasive that the changes were -- until relatively recently -- easy to apply to just about any Snapdragon-based device (even ones with fully-functioning OTG support, which the Nexus 4 didn'thave), since many of them shared a common USB core, and thus also shared drivers.
I was disappointed to discover upon receiving my Z5 Compact that although for some odd reason that venerable old Snapdragon USB driver was enabled in Sony's kernel's build .config, it wasn't actually being used by the hardware...I patched up the kernel, compiled it, flashed it, and the behavior of the USB port didn't change. Turns out all of the more recent Snapdragons use a new USB 3/SuperSpeed-capable core by Synopsys, part of their DesignWare series, and this core uses an entirely different driver called DWC3. And unlike the older driver, this new one does not implement support for so-called USB "accessory charging adapters" or ACAs (typically vendor-proprietary powered USB hubs that do exactly what we want: charge the phone while putting it in host mode), so in-built support for ACAs couldn't be exploited in the DWC3 driver the way that it had been in the old driver.
Fortunately, @sollapse rose to meet the challenge and whipped up some basic ACA support for the DWC3 driver included in the kernel source tree for the OnePlus One. I took what was largely a re-write of this, done by @Phoenix Wright, and essentially ported that version over to the Z5 kernel while also making some other changes and additions along the way.
Use:
Disclaimer: I cannot be held responsible if any harm should come to you or your phone on account of using these software modifications.
This was developed and tested against the Sony copyleft sources for the kernel that shipped with the last release of Lollipop for the Z5 series (32.0.A.6.200). I plan to also work on versions for the Marshmallow and Nougat kernel releases as well, but wanted to start with something as close to what I was porting from as possible and just deal with one variable at a time. Chances are good that very little changed in the USB drivers in later Z5 kernels anyway. I have also to-date only tried to apply this to an otherwise stock Sony source tree, and running on the stock Sony Lollipop ROM.
This isn't how ACAs are strictly meant to work on a device that officially supports them, but when it comes to this patch, to enable or disable "ACA mode", you need to either pass a certain parameter (aca_enable, should be set to 'Y') to the driver (dwc3) at initialization (during boot / on the kernel command line, so 'dwc3.aca_enable=Y'), or toggle the parameter after boot using sysfs (e.g. 'echo N > /sys/module/dwc3/parameters/aca_enable'). For write access to sysfs, you have to be root, so keep that in mind if you have a requirement to be able to toggle this on and off without a reboot.
Enabling ACA mode merely changes the behavior of the driver when the ID pin/pin 5 on the micro-USB cable is grounded (OTG cable), which indicates to the phone that it should switch to host mode. With ACA mode enabled, it basically doesn't engage the USB host voltage bus regulator and instead activates the battery charging circuitry; however, just like "normal" USB host mode, it still requires an actual OTG cable to work, UNLIKE ziddey's original patch. What this means is that if you want to plug, say, a thumb drive into your phone without having to also supply an external power source, you need to set 'aca_enable' back to 'N' first before this will work again.
Sometimes it is not possible to use an OTG cable in certain situations; for example, there is no way I am going to first cut out and then cut open the non-OTG micro-USB plug from my $80 Proclip car mount in order to turn it into a proper OTG cable. For these situations, ziddey's ingenious idea -- borne out of necessity by the broken ID_GND detection on the Nexus 4 -- of triggering host mode based on the type of charging adapter detected by the phone is extremely useful, and so I implemented a similar feature: by additionally setting 'prop_chg_aca_enable' to 'Y', the driver will switch to USB host mode if a so-called "proprietary" charging source is detected (which is apparently what the phone interprets the voltage injected with a USB Y-cable as).
'prop_chg_aca_enable' will have no effect if 'aca_enable' is not also toggled on. I split it out into a separate option, though, because for reasons I haven't had the time to hunt down yet, the charger detection toggle seems (based on extremely limited testing) to make the use of an OTG cable less reliable...sometimes it works, sometimes it engages the host mode but not the battery charger, sometimes it does neither. So if you already use an OTG cable with your particular set-up, I recommend you leave 'prop_chg_aca_enable' off.
Finally, as most of you surely know, the Z5 series (and the Z3+/Z4 before it) introduced a new coverless micro-USB port along with a new requirement that you the user must manually initiate a scan for attached USB gadgets in order for the port to switch over to host mode; presumably they did this so that they could keep the IP68 water ingress protection rating despite the change to a coverless port. Miraculously, when aca_enable is on, because the phone is accepting a charge instead of delivering power in this scenario, there is (in theory) no additional risk from water exposure in this mode and yet you also do NOT need to hit "Detect USB Device" on your phone before you can use the USB device...as long as both external power and a USB device are present on the cable at the moment you plug it in. If you don't have a USB device plugged into your Y-cable, only power, then the device will not be detected later. If you have a need to work around this, you can set 'no_device_timeout_enable' to 'N', which will keep the host controller on-line and engaged for as long as you have a powered OTG cable plugged in.
If you want to *really* live life on the edge, you can also set the 'force_id_polling_on' parameter of the 'qpnp_smbcharger_extension' driver to 'Y' in order to completely disable the need for tapping on "Detect USB Devices" for "normal" OTG mode.
Oh, one more thing I forgot: if you are supplying power through an OTG cable (with ID pin grounded), then you need to set 'dwc3_msm.force_float_on_bsv=N' in order to work around a change Sony made to the driver that causes it to treat powered OTG cables as if they are non-OTG. I don't know why they did this (perhaps just to further reduce the risk of water damage on account of the open port under certain circumstances?), but I added a toggle that bypasses their change.
In summary, here are all of the various driver/module options I have decided to supply to my own kernel at boot time; at a minimum #1 and #4 are mandatory when using a OTG cable and #4 and #5 are mandatory when using a non-OTG cable:
dwc3_msm.force_float_on_bsv=N
(disables Sony "innovation" that prevents a powered OTG cable from switching controller into host mode)
qpnp_smbcharger_extension.force_id_polling_on=Y
(disables the need for "Detect USB Devices" under normal OTG use -- NOTE this could reduce the integrity of the water protection!! Use with caution!)
dwc3.no_device_timeout_enable=N
(disables host mode timeout in the event controller does not detect a device)
dwc3.aca_enable=Y
(enables the new "ACA mode" which allows for the exclusive use of powered OTG cables at the expense of normal OTG use)
dwc3.prop_chg_aca_enable=Y
(additionally allows USB host mode to be triggered by a non-OTG powered Y-cable that also has a USB device attached)
I hope others find this useful, while at the same time I also hope that our USB-C future will eventually end the need for us to dabble in such hackery.
-- Nathan

Nice work! Just to let you know, I made some final changes to the patch before submitting it to SultanXDA there: https://forum.xda-developers.com/showpost.php?p=64784909&postcount=8403 (I think there was an issue with kernel panics in certain circumstances which was fixed by a msleep(), maybe something else too).

Phoenix Wright said:
Nice work! Just to let you know, I made some final changes to the patch before submitting it to SultanXDA there:
Click to expand...
Click to collapse
Thanks! My version of the patch was based off of the final post you made to sollapse's thread, which I'll call your patch #1. I just downloaded the version of the patch you linked to (#2), and diff'd a copy of the Sultan dwc3_otg.c patched with #1 against a copy patched with #2, and this is the only difference I found:
Code:
@@ -1048,6 +1044,11 @@
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
+ /* If B_SESS_VLD went off already, proceed to enable host */
+ if (test_bit(B_SESS_VLD, &dotg->inputs)) {
+ work = 1;
+ break;
+ }
/* Ensure there's no charger before suspending */
msleep(200);
if (!dotg->ext_xceiv->bsv)
pm_runtime_put_sync(phy->dev);
} else {
...and I had actually added a single line to that 'if' block already that set work=1 indiscriminately (which you can see in my patch). (As I recall, more often than not after hitting the A_IDLE case, there would be no additional external event to trigger the workqueue again after state was set to A_HOST, which meant that OTG_STATE_A_HOST case block would never actually get executed.) It probably would be more correct for me to test for BSV before forcing another workqueue loop, so I'll try making that change and re-testing. I haven't experienced any ill effects in day-to-day use, though.
Is there a reason why you are checking BSV state twice and in two different ways here (checking the B_SESS_VLD bit in dotg.inputs, and also directly checking dotg.ext_xceiv.bsv)? Are you checking dotg.ext_xceiv.bsv directly because there is a chance that dwc3_ext_event_notify() hasn't been called by the transceiver driver yet for some reason to update the state machine inputs? What about simplifying things here down to a single test, like so?:
Code:
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
/* If B_SESS_VLD went off already, proceed to enable host */
if (test_bit(B_SESS_VLD, &dotg->inputs)) {
work = 1;
break;
} else {
/* Ensure there's no charger before suspending */
msleep(200);
pm_runtime_put_sync(phy->dev);
}
} else {
(or substitute in "if (dotg->ext_xceiv->bsv)" for the call to test_bit() if you think that is more appropriate for some reason?)
Thanks again,
-- Nathan

nlra said:
Thanks! My version of the patch was based off of the final post you made to sollapse's thread, which I'll call your patch #1. I just downloaded the version of the patch you linked to (#2), and diff'd a copy of the Sultan dwc3_otg.c patched with #1 against a copy patched with #2, and this is the only difference I found:
Code:
@@ -1048,6 +1044,11 @@
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
+ /* If B_SESS_VLD went off already, proceed to enable host */
+ if (test_bit(B_SESS_VLD, &dotg->inputs)) {
+ work = 1;
+ break;
+ }
/* Ensure there's no charger before suspending */
msleep(200);
if (!dotg->ext_xceiv->bsv)
pm_runtime_put_sync(phy->dev);
} else {
...and I had actually added a single line to that 'if' block already that set work=1 indiscriminately (which you can see in my patch). (As I recall, more often than not after hitting the A_IDLE case, there would be no additional external event to trigger the workqueue again after state was set to A_HOST, which meant that OTG_STATE_A_HOST case block would never actually get executed.) It probably would be more correct for me to test for BSV before forcing another workqueue loop, so I'll try making that change and re-testing. I haven't experienced any ill effects in day-to-day use, though.
Is there a reason why you are checking BSV state twice and in two different ways here (checking the B_SESS_VLD bit in dotg.inputs, and also directly checking dotg.ext_xceiv.bsv)? Are you checking dotg.ext_xceiv.bsv directly because there is a chance that dwc3_ext_event_notify() hasn't been called by the transceiver driver yet for some reason to update the state machine inputs? What about simplifying things here down to a single test, like so?:
Code:
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
/* If B_SESS_VLD went off already, proceed to enable host */
if (test_bit(B_SESS_VLD, &dotg->inputs)) {
work = 1;
break;
} else {
/* Ensure there's no charger before suspending */
msleep(200);
pm_runtime_put_sync(phy->dev);
}
} else {
(or substitute in "if (dotg->ext_xceiv->bsv)" for the call to test_bit() if you think that is more appropriate for some reason?)
Thanks again,
-- Nathan
Click to expand...
Click to collapse
A lot of time has passed, but if I'm not mistaken, on the OPO, in some circumstances (II think if you removed the otg-y cable quickly or something like that), dwc3_ext_event_notify() would be called (to signal that power was removed) after the device was suspended leading to a kernel panic (I did a lot of tests with the "extreme" cases, like removing the cables quickly). So the msleep is to make sure that it didn't happen (in such cases, the device is then suspended by the next invocation of that state machine if I'm not mistaken, in the "case OTG_STATE_A_HOST:", in the part below the "/* Charger has been removed */" comment). So the changes you proposed wouldn't work, as the msleep + direct check are there to tell if the state machine is going to be called again just after that.

Phoenix Wright said:
[...] on the OPO, in some circumstances (II think if you removed the otg-y cable quickly or something like that), dwc3_ext_event_notify() would be called (to signal that power was removed) after the device was suspended leading to a kernel panic (I did a lot of tests with the "extreme" cases, like removing the cables quickly). So the msleep is to make sure that it didn't happen (in such cases, the device is then suspended by the next invocation of that state machine if I'm not mistaken, in the "case OTG_STATE_A_HOST:", in the part below the "/* Charger has been removed */" comment). So the changes you proposed wouldn't work, as the msleep + direct check are there to tell if the state machine is going to be called again just after that.
Click to expand...
Click to collapse
Gotcha, thanks; makes perfect sense. I'm not sure that the same thing is necessarily happening on the Z5...it uses a different battery charge controller than the 1+1 and in fact I ripped out a lot of the 1+1-specific workarounds when preparing my version of the patch. (I still need to do more testing, but in fact I'd say there are some instances where BSV is actually not being detected properly on this platform, which could explain my initial findings...there is a debugfs file exposed where you can check current BSV detection state, but even when phone is getting power it almost always shows "0".)
Nevertheless, I ran some tests:
1. With work=1 set explicitly every time (my addition to your code for my original version of the path), everything with a powered OTG cable and aca_enable=Y worked fine for me.
2. With that removed, it almost never engaged the battery charger, though host mode almost always kicked in.
3. After adding work=1 only if B_SESS_VLD bit was set, working functionality for powered OTG cables was restored (again, as long as my new prop_chg_aca_enable=N).
So I have updated the patch to check for that bit before forcing another workqueue loop, which I believe is "more correct".
Thanks again,
-- Nathan

Hm sorry I gonna sound like a total noob but everyone starts out somewhere. The *.diff file is for a ROM to be compiled? Its not supposed to be flashed with TWRP or such? Or is it just a file to be overwritten in the system files?
Just today I made myself an OTG cable with charging function and was scratching my head why it's not charging.

tarsonis666 said:
Hm sorry I gonna sound like a total noob but everyone starts out somewhere. The *.diff file is for a ROM to be compiled? Its not supposed to be flashed with TWRP or such? Or is it just a file to be overwritten in the system files?
Just today I made myself an OTG cable with charging function and was scratching my head why it's not charging.
Click to expand...
Click to collapse
You are correct, this file is used to patch the kernel (not the ROM) source and then compile the kernel binaries.
Files you flash in TWRP usually end in ".zip" or ".img".
// DevelLevel

Hey. Has anyone compiled a kernel with this patch applied? I'm a total noob when it comes to Linux and I'm really struggling with compiling a kernel, let alone applying patches to it . I would be really grateful if someone could attach a ready kernel image.

Adamell0 said:
Hey. Has anyone compiled a kernel with this patch applied? I'm a total noob when it comes to Linux and I'm really struggling with compiling a kernel, let alone applying patches to it . I would be really grateful if someone could attach a ready kernel image.
Click to expand...
Click to collapse
Sorry, haven't hung out around here in a while...
What specific phone model do you have, and what firmware version are you using? If it is something in the Z5 family (regular/Compact/Premium) and otherwise stock Sony firmware, let me know which model and f/w version and I can probably whip something up.
If it's some other phone model, no guarantees. If Z5 with third-party AOSP-based firmware, also no guarantees but more likely than not may be possible.

nlra said:
Sorry, haven't hung out around here in a while...
What specific phone model do you have, and what firmware version are you using? If it is something in the Z5 family (regular/Compact/Premium) and otherwise stock Sony firmware, let me know which model and f/w version and I can probably whip something up.
If it's some other phone model, no guarantees. If Z5 with third-party AOSP-based firmware, also no guarantees but more likely than not may be possible.
Click to expand...
Click to collapse
Thanks for your response. I have Sony Xperia Z5 Compact model E5823 with Android 7.1.1., kernel version is 3.10.84-perf-g99119bc.

Adamell0 said:
Thanks for your response. I have Sony Xperia Z5 Compact model E5823 with Android 7.1.1., kernel version is 3.10.84-perf-g99119bc.
Click to expand...
Click to collapse
Gotcha; I should be able to help with this, but what I need is the Sony ROM version, not the kernel version. Can I assume that you're running the latest (last) version of 7.1.1 released for the Z5c, 32.4.A.1.54? (At this point I'd be surprised if you were running anything older, but I'm going to be pulling the kernel sources direct from Sony for the firmware version that matches what you're running, which is why I need to be sure. In all likelihood, though, even if you are running slightly older ROM, since you're already on 7.1.1, the odds of a kernel built from the latest sources not working with your ROM are likely slim-to-none.)
And you already have the bootloader unlocked on your Z5c, yes?
EDIT: -g99119bc is what is shown as the suffix on the kernel version from 32.4.A.1.54 in screenshots of "About phone" all over the internet for the Z5 series, so I'm moving forward with this assumption.

nlra said:
Gotcha; I should be able to help with this, but what I need is the Sony ROM version, not the kernel version. Can I assume that you're running the latest (last) version of 7.1.1 released for the Z5c, 32.4.A.1.54? (At this point I'd be surprised if you were running anything older, but I'm going to be pulling the kernel sources direct from Sony for the firmware version that matches what you're running, which is why I need to be sure. In all likelihood, though, even if you are running slightly older ROM, since you're already on 7.1.1, the odds of a kernel built from the latest sources not working with your ROM are likely slim-to-none.)
And you already have the bootloader unlocked on your Z5c, yes?
EDIT: -g99119bc is what is shown as the suffix on the kernel version from 32.4.A.1.54 in screenshots of "About phone" all over the internet for the Z5 series, so I'm moving forward with this assumption.
Click to expand...
Click to collapse
I'm running exactly the version you mentioned: 32.4.A.1.54. As far as unlocking bootloader goes it is still on my "to do" list, but for that I assume that the tutorial on Sony website will suffice.

Adamell0 said:
I'm running exactly the version you mentioned: 32.4.A.1.54. As far as unlocking bootloader goes it is still on my "to do" list, but for that I assume that the tutorial on Sony website will suffice.
Click to expand...
Click to collapse
I would advise you to not just blindly unlock the bootloader on your Z5c if you haven't done so already. Doing so on the Z5c is irreversible and has permanent consequences unless you prepare in advance / take necessary precautions. (Side note: it's because of stuff like this that I've learned to always search and read up on any potential pitfalls when it comes to doing bootloader unlocks on specific models of phones before just jumping right in!!! Sony is not entirely forthcoming in their warnings on their site about what you lose when you unlock!)
The "necessary precautions" involve backing up what is called the TA partition of the phone before unlocking the bootloader. When you unlock the bootloader, the phone zeroes out all of the DRM keys stored in this sector that are unique to your particular phone (not phone model, your specific unit! if you lose them you can never get them back! and you can't take copies of keys from another Z5c and flash them to your phone unless you want a permanent brick that will never power back on again!). So best to back this up beforehand, both so that you have the option of returning to COMPLETE stock in the future if you so desire (re-lock bootloader, etc.), but also so that you can reflash the keys back to TA while retaining the unlocked bootloader, having the best of both worlds.
Unfortunately, this is a bit of a pain to do, admittedly, since TA partition is normally heavily guarded. It's supposed to be impossible to access, but a bug in older firmwares can be exploited to gain access to it even with a locked bootloader. So this means you have to actually downgrade back to Android 6.0 Marshmallow *just temporarily*, long enough to make a backup of the TA partition. After that, you can re-upgrade back to 7.1 Nougat and proceed with bootloader unlock.
If you decide not to go to the trouble, that's fine, but at least you will be making an informed decision in advance, rather than only finding out about what you lost after it's gone, robbing you of choice.
Link to TA backup utility: https://forum.xda-developers.com/t/universal-dirtycow-based-ta-backup-v2.3514236/
To downgrade, you'll need to get yourself a copy of Flashtool and a Sony Z5c Marshmallow ROM file; I can provide links to these in a PM if you want to go down this path. The firmware download is nearly 3 gigs, just FYI.

nlra said:
To downgrade, you'll need to get yourself a copy of Flashtool and a Sony Z5c Marshmallow ROM file; I can provide links to these in a PM if you want to go down this path. The firmware download is nearly 3 gigs, just FYI.
Click to expand...
Click to collapse
Please PM me those links if it's not a problem, while the phone is just one of many laying in my drawers having options is always a good thing .

Adamell0 said:
Please PM me those links if it's not a problem, while the phone is just one of many laying in my drawers having options is always a good thing .
Click to expand...
Click to collapse
Check your PM for links and general overview of how to accomplish downgrade/TA backup/upgrade.
Your kernel is also ready, tested, and attached.
Note that this is just the raw kernel with OTG patches included. If you end up backing your TA partition up, you will want to patch this kernel image with the latest version of rootkernel (which adds additional patches to restore functionality lost after bootloader unlock, but are not patches that require a kernel re-compile) and then flash that version.
Also, just in case it wasn't clear in the original post, these patches do not allow you to seamlessly use both traditional non-powered OTG as well as powered OTG...it's one or the other. Non-powered OTG will stop working, and OTG/host mode will only be possible if a power source is also applied. It is possible to disable the powered OTG mode and revert to regular non-powered mode, but it has to be done with a terminal command, and it will return back to powered-only OTG mode after the phone is rebooted.

Which OBD2 adapter?

I have old OBD2 v1.5 adapter. Chinese, big one. Which pairs with HU and works well.
I wish to buy new one, that call 'mini'. I know I have to look for v1.5 (as 2.1 is a crap) and with PIC18F25K80 chip.
But I read that even much of these new mini are PIC based, that have some strange Mac address like AA:BB:CC:11:22:33.
Anyone has experience with such adapters? Do they pair and work with Torque on our HUs?
If anyone is using such an 'mini' adapter, please post link to eBay/AliExpress where you purchased it. Will be very grateful (and it may help other people here, too, as many have issues pairing/using crap adapters).

I personally bought https://www.ebay.com/itm/Auto-16-Pi...le-Diagnostic-Adapter-For-elm327/152700822059 and https://www.ebay.com/itm/2017-ELM32...uto-Car-Scanner-Scan-Tool-Cable-/112070132071 so I connected it over USB and only thing I've made is HW MOD to get ACC+ instead BAT+ from OBD2 so that it is powered only when Key is turned on.
Resolved pairing issue with no pairing and all works along with BT and WiFi free for other devices.

PekeMM said:
I personally bought https://www.ebay.com/itm/Auto-16-Pi...le-Diagnostic-Adapter-For-elm327/152700822059 and https://www.ebay.com/itm/2017-ELM32...uto-Car-Scanner-Scan-Tool-Cable-/112070132071 so I connected it over USB and only thing I've made is HW MOD to get ACC+ instead BAT+ from OBD2 so that it is powered only when Key is turned on.
Resolved pairing issue with no pairing and all works along with BT and WiFi free for other devices.
Click to expand...
Click to collapse
Thank you for sharing. I was not considering USB option, but it sounds interesting.
I see you both the 'big' one (same as my old one). And they really work very good.
But I would like to buy some of 'mini' models as my OBD2 port is in such place (under steering wheel and just above brake pedal) that big one is too big and my feet is hitting it while driving. Here is obe model I consider
Hardware V1.5 Chip PIC18F25K80 ELM327 Bluetooth V1.5 Auto Code Reader Super MINI ELM 327 Works ON Android Symbian FW V1.5 BEST
http://s.aliexpress.com/I3i26fy2
There are 2 models of these (not colours): old design with 2 PCB boards, and new one with just 1 board. I wonder if anyone has any of these?

pa.ko said:
But I would like to buy some of 'mini' models as my OBD2 port is in such place (under steering wheel and just above brake pedal) that big one is too big and my feet is hitting it while driving.
Click to expand...
Click to collapse
:silly: I do not see the problem there as if you checked both links from my post you would see that I use extension cable that do not have issue with connector position. Mine is located right above gas pedal so I could not drive car normally with any OBD Adapter unless I used extension cable.
pa.ko said:
Here is obe model I consider Hardware V1.5 Chip PIC18F25K80 ELM327 Bluetooth V1.5 Auto Code Reader Super MINI ELM 327 Works ON Android Symbian FW V1.5 BEST
http://s.aliexpress.com/I3i26fy2
Click to expand...
Click to collapse
PIC is programmed micro controller and not actual ELM327 see https://www.elmelectronics.com/products/ics/obd/ and v1.5 nor v2.1 exist officially as they are clones and you should use https://play.google.com/store/apps/details?id=com.applagapp.elm327identifier to test actual model and support.
Re which one: I ordered 6 different models and kept two that worked flawlessly with my car 1 was broken (got refund) and resold other 3 to get my money back.

PekeMM said:
I personally bought so I connected it over USB and only thing I've made is HW MOD to get ACC+ instead BAT+ from OBD2 so that it is powered only when Key is turned on.
Resolved pairing issue with no pairing and all works along with BT and WiFi free for other devices.
Click to expand...
Click to collapse
How did you mod this?

gazenbeek said:
How did you mod this?
Click to expand...
Click to collapse
It is fairly simple MOD:
1. Soldered positive wire of lighter connector that have power only when Ignition is turned on.
2. Bought FLAT cable that I can easily cut the wires like in picture s-l1600.jpg
3. Cut Wire on pin 16 BAT power see ODBII%20Master%20Pinout.jpg
4. Connected wire that goes to OBDII to Positive wire I prepared in step 1
5. Connected OBDII to connector from FLAT CABLE
6. Connected USB to HU SINGLE USB CABLE
7. Tested if all works with Toque
8. Used cable ties to secure all cabling behind dashboard
and now I enjoy the all the diags on HU

PekeMM said:
so I connected it over USB and only thing I've made is HW MOD to get ACC+ instead BAT+ from OBD2 so that it is powered only when Key is turned on.
Resolved pairing issue with no pairing and all works along with BT and WiFi free for other devices.
Click to expand...
Click to collapse
Thanks for this info, very helpful, just got Android 8 Eonon 2170, and I've been struggling to pair OBD, Kiwi 3 doesn't show (BLE not supported? Don't know), Tomtom unit won't pair, no name unit seems to work, but, I've thought, why not USB, started searching for USB Android supported, luckily came across your post.
To change BATT to ACC, is that just so it's ' done properly'?
Surely battery drain would be miniscule, or not? I guess makes sense to have it not powered all the time.
Going by your posts, so, some of these units didn't work properly,ECU side or Android side? Thanks again, A

I just looked into factory settings, there is a CANBUS section, currently set to NONE, should that that altered to car maker's CANBUS ?

abbots said:
Thanks for this info, very helpful, just got Android 8 Eonon 2170, and I've been struggling to pair OBD, Kiwi 3 doesn't show (BLE not supported? Don't know), Tomtom unit won't pair, no name unit seems to work, but, I've thought, why not USB, started searching for USB Android supported, luckily came across your post.
Click to expand...
Click to collapse
Glad I helped someone
abbots said:
To change BATT to ACC, is that just so it's ' done properly'?
Click to expand...
Click to collapse
Yes, it is safe no issues at all
abbots said:
Surely battery drain would be miniscule, or not? I guess makes sense to have it not powered all the time.
Click to expand...
Click to collapse
It is not the problem that it drains a ot but all small drains can pile up so eventually you have a problem. I have park mode security enabled on my dashcam system so it drains some, OBDII can drain a littl, but it is known that in some cases keeps ECU awake that can drain a lot due teh number of sensors it keeps awake also
abbots said:
Going by your posts, so, some of these units didn't work properly,ECU side or Android side? Thanks again, A
Click to expand...
Click to collapse
All was ECU side due the different pinouts see my pics, I have seen in the past several USB -> COM chips that are not supported on Android due the OEM build and specific drivers like some factory that are not recognized on laptop till you install their licensed software (Usually JUNGO Based Drivers).
---------- Post added at 00:24 ---------- Previous post was at 00:20 ----------
abbots said:
I just looked into factory settings, there is a CANBUS section, currently set to NONE, should that that altered to car maker's CANBUS ?
Click to expand...
Click to collapse
Only if you got specific cables with canbus decoder (black little box). even then USB OBDII is used to diagnostic and clear codes. I use Toque 1.83 and it works on one unit that v1.52 didn't worked with. Usually ELM v1.5 works better than v2.1

thanks! I have now got USB OBD unit 1.5 (still need splitter/extender), tried yesterday with Torque as well as with Palmer's DashCommand:
it kinda worked - during first trip, 45min, Torque app crashed twice or more, worked after restart, on return trip, DashCommand also choked once or twice, thenm I relaized, as fuel tank level is not reported, unless I run app 100% of the time, fuel consumption won't be correct - and, realsiticall, I need TomTom on the screen more than gauges....
I see there are OBD spliters that 'allow' two or three OBD devices plugged in, wouldn't you know, is it OK to split/use multiple OBDs ?
like, I have TomTom 'Curfer' OBD data logger - just logs 'quality of driving", thoiught to get splitter to log data, AND, if so desire, call gauges on screen ?
thanks for explaing CANBUS!
do you use TPMS tyre pressure units, if so, which ones ? my radio has an app to read such, wonder if it's worth it ?

I have connected my USB OBD. Torque not recognised device. How to check that Scanner is properly installed on android system?
OBD scanner is generic just like this:
https://www.amazon.co.uk/ELM327-USB-Interface-Diagnostic-Scanner/dp/B00IWLLX1Y
BTW I have MTCE with android 8.0 with KLD MCU.

Torque lite ain't work with android/usb, only in bluetooth mode.

I have torque pro so there is no problem there.
Any way problem solved. Bought Bluetooth version.