maemo.org - Talk - [Announce] USB hostmode beta release

maemo.org - Talk (https://talk.maemo.org/index.php)

- Nokia N900 (https://talk.maemo.org/forumdisplay.php?f=44)

- - [Announce] USB hostmode beta release (https://talk.maemo.org/showthread.php?t=65232)

Re: [Announce] USB hostmode beta release

Quote:

Originally Posted by Estel (Post 1137148)

By the way, is there any chance, that you could - via Your scripts - include a fix for "standby current draw" - a bug that results in increased battery consumption, after using hostmode. It is 100% reproducible, and to fix it one need to connect charger for a moment.

Once, joerg_rw suggested, that just "cheating" device to think that charger is connected for a moment, would also work. If, by any chance, this can be done via Your scripts, it would increase independence from wall socket, not to mention lowering wear & tear on USB port ;)

Also, there was unconfirmed reports about fixing it by enabling booston, killing it, and invoking boostoff - ho ever, I'm unable to determine for 100% if it really works or not (some times, it seem to work, on other occasions, I still have increased battery usage until connecting and disconnecting charger).

/Estel

That should be fixed in next KP

Re: [Announce] USB hostmode beta release

Quote:

Originally Posted by Estel (Post 1137148)

please report if you use my scrip this ( increase batt usage ) happen too.
also check with top if filemanager is active and use cpu
check if use this sequence filemanager close, unmount, some wait, vbust off, some wait, exit make any difference

i don't have problems with battery

Re: [Announce] USB hostmode beta release

It also happens with your script, and AFAIK, it's related to kernel parts of hostmode, so you probably experience it without noticing ;) My proposition wasn't of course meant to "proper" fix this issue - as your script doesn't affect kernel part - bu rather, to introduce some way of "cheating" device that charger is connected, which is ugly workaround.

Of course freemangordon amazed me again, so i think we can rest assured it'll be fixed properly ;)

/Estel

Re: [Announce] USB hostmode beta release

Quote:

Originally Posted by Estel (Post 1137174)

The kernel image I PMed you some time ago has the patch expected to fix this issue, along with ancient bug when device is unable to shutdown with charger connected. Do you use that kernel and still have battery drain after using hostmode?

Re: [Announce] USB hostmode beta release

I've PM'ed You few days ago, that I was still using Your special kernel build, until I realized, that I can't properly enumerate *any* USB device with it. Maybe PM was somehow "missed in action"? I got one report about my PM being supposedly redirected to /dev/null, so it may be some problem on my side.

Anyway, flashing regular kp49 back solved the issue. Still, it's possible that some hardware voodoo with cables/female-female adapter happened (despite I tried reconnecting, reboots, etc many times), and I was during long trip when this all happened, so I got limited testing possibilities. if You're absolutely sure it should work, I can flash it again and test thoroughly in my "home lab".

/Estel

Re: [Announce] USB hostmode beta release

Quote:

Originally Posted by Estel (Post 1136559)

I'm not opting on *excluding* hostmode charging from blue_led scripts. I'm suggesting, that forcing every user to use it (or modify scripts) is bad idea - as opposed to allowing using it by executing two simple commands from xterm (boostoff && charge.sh), or even creating one script, that, upon execution, invoke those 2 commands - for lazy ones ;).

Calling charging from xterm by 1/2 short commands seems reasonable for script, that works from xterm anyway. Forcing user to *always* do charge.sh, or modify scripts itself to get rid of it, isn't fun. Nor it resemble the "ideological" Open/Linux way of doing things.

Of course, if it gets implemented as "force to use it", I can live with that, and modify script / fork it if others would be interested in using such version (like it was for a long time with backupmenu, and backupmenu-multiboot - while, t was very easy to implement one version working for all). After all, final decision belongs to blue_led. Still, I don't think it's good idea, to *force* such commands on user.

Not to mention complications on script-side (determining, when it should do boostoff/charge, or not - trying that without external power source would break hostmode), but that's different topic.

/Estel

dude, H-E-N is first and foremost meant for mobile hostmode where you can not charge and need vboost power from device.
I'd never suggest to change that to a "you need an external power supply or it won't work".

What I thought of though is displaying a notifier "if you want to use charging, plug in your power supply NOW!", then for maybe 5s detect/check if there's already 5V applied, then depending on the result either enter charging hostmode or vboost hostmode. In the specs for my never finished jrbme/hostmode script this was dealt with by parameter --power-auto (as opposed by --power-external and --power-vboost [default]).
[edit] anyway note that due to speed settings need to be done with NO vbus power applied, any external power supply will be mutually exclusive to speed autodetection :-S (blue-led will know what I'm talking of, as he already implemented vboost joggling to do the speed detection)[/edit]
Further related parameters were --power-notify-timeout <seconds>, with "0" meaning that user has to click on "ok" in that notifier, and there's been another specified parameter --power-manual which would open a "charging? yes/no" requester. Quite obviously any script (also) for charging hostmode needs to wait for external power to get applied before ENUM etc gets started. And once we started vboost we can't detect presence of external power anymore. Thus the above sketched scheme.

:-D :-D
cheers
jOERG

Re: [Announce] USB hostmode beta release

Quote:

Originally Posted by blue_led (Post 1136698)

1) charging hostmode
until now i can't find a solution to detect a charger when vbus is 5V.
monitoring battery current, voltage ... no work
[...]

errrr, you detect a charger by vbus = 5V, you simply check the according sysnode that works independent of bme. You can not detect chargers (as in "detect fastcharger D+/- short") when using hostmode - the D lines are used for DATA then, and can't get shorted. For normal charging you resort to using bme which you start as soon as hostmode gets finished (just like it's done right now in H-E-N GUI).

cheers
jOERG

Re: [Announce] USB hostmode beta release

Quote:

Originally Posted by joerg_rw (Post 1141547)

What I thought of though is displaying a notifier "if you want to use charging, plug in your power supply NOW!", then for maybe 5s detect/check if there's already 5V applied, then depending on the result either enter charging hostmode or vboost hostmode.

Very good idea. It also leave room for just powering USB devices without charging N900 - one just need to plug in external power source outside such hypothetical ~5 seconds.

If it would be looking like that, I'm totally supporting concept of auto-enabling charging while hostmode.

/Estel

Re: [Announce] USB hostmode beta release

Quote:

Originally Posted by joerg_rw (Post 1141549)

what i want is to detect an external +5 when boost is active. one idea is to monitor curent sink from battery using bq27200.
enable charge is an option ( manual connection of external source required ) so an button in status area menu is enough

anyway
i found an workaround ( hardware mod ) for ALL hostmode problems. i am glad to share with you

details
bq27200 have an unused GPIO pin, out mode is open drain transistor 5mA sink capable.
by connecting this pin ( 9 ) to R4283 - C4280 - F4 ( isp 1707 ) node we can controll voltage applied to the usb phy. bq chip can sink all curent flowing r4283 to ground ( 5V / 1k = 5mA ) if any piece of code will program gpio pin of bq27200 as input this don't affect normal usb operation
what we get ?
independent source of vbus speed selection. even if external 5V is applied, permanently to n900 we can any time make speed selection by programming pin 9 of bq27200 as output and assert low
this is equivalent to toggle boostoff , booston .
so charging any time or boosting to 5v the bus line the job is freed of any constraint

the link between 27200 and 1707 can be easily done ( no underchip conections )

Re: [Announce] USB hostmode beta release

Quote:

Originally Posted by blue_led (Post 1142422)

what i want is to detect an external +5 when boost is active. one idea is to monitor curent sink from battery using bq27200.
[...]

alas this won't work

Quote:

Originally Posted by blue_led (Post 1142422)

anyway
i found an workaround ( hardware mod ) for ALL hostmode problems. i am glad to share with you

details
bq27200 have an unused GPIO pin, out mode is open drain transistor 5mA sink capable.
by connecting this pin ( 9 ) to R4283 - C4280 - F4 ( isp 1707 ) node we can controll voltage applied to the usb phy. bq chip can sink all curent flowing r4283 to ground ( 5V / 1k = 5mA ) if any piece of code will program gpio pin of bq27200 as input this don't affect normal usb operation[...]

Wow , that's nifty. But I'm not sure if the peripheral will need a VBUS voltage drop to restart the whole USB negotiation as well.
A tip from me: if you could rather manage to pulldown the ID pin, this should work way more in the originally intended way. If you make PHY1707 send a msg "ID pin low" to musb_hdrc core, you won't need to 'abuse' test_mode for hostmode, and thus the limitation regarding switching speeds won't apply anymore. --> GENUINE OTG hostmode, without H-E-N (well almost, modulo vboost which isn't controlled by kernel anyway)

Anyway, brilliant :-D Keep on hacking!
cheers
jOERG