Re: [Announce] USB hostmode beta release
 

You miss 1 year ? :D

first q :switching speed need vbus go 0 Volts. for valid usb session vbus above 4.4 volts condition is needed . switching vbus from 0 to 5 v ( for setting speed ) will trigger an interrupt activating khubd, but usb phy and driver are not in a stable state and khubd go crazy ( timeout ). generic or custom KP kernel don't know how to switch isp1707 speed ( is "platform dependent" and not allowed when vbus is 5V ). if some patches will be writen for vbus switching in kernel some processes ( bme ) need to be stopped for leaving i2c device bq24150 free to controll. and for vbus stable a timer doing any action every less 32 s on bq21450's i2c interface also is needed
so pointing from kernel space to bme and setting a timer look ugly

it is easy doing all selections from userspace

second q: is not a problem

Re: [Announce] USB hostmode beta release
 

I see that problem from kernel hostmode patch (error messages in musb_procfs.c), but I was not sure if switching vbus is only problem. But I started looking around bq2145x chip and I will write kernel module(s) for bq chip and charging...

Re: [Announce] USB hostmode beta release
 

The jumper cables are a nice touch :)

Re: [Announce] USB hostmode beta release
 

@blue_led
the userland autospeed has one problem: it needs to either depend on sysklogd being installed or use kmsg directly. You need to support both cases, or rdepend on ksyslogd pkg.
You are aware you can find about lowspeed vs high/fullspeed devices by reading out the status registers of PHY, and IIRC they are even printed in syslog. on one the D+ is low while on other the D- is low (see USB 101 about lowspeed vs full/highspeed signalling via pullup R) [maybe the prev isn't all correct as I haven't re-read the specs myself just now, it's a while since I last looked into them]
Great to see your progress, while I clearly suck delivering that stuff :-D
Keep in mind it may take quite some time after disabling boost mode until VBUS drops to a sane level so you can switch speed. Maybe testing VBUS voltage may give a clue, or just insert a short (some 5..15s) charging phase so bq24150 will try to pull power and thus discharges VBUS rail. Otherwise musb_core might not allow proper changing of speed.

cheers and keep hacking
jOERG

Re: [Announce] USB hostmode beta release
 

my script is plain, dumb, ash script. for sure it don't suffer for missing lib
i think there is a bug or some curent leakage on d+ line so with no device attached the driver see a full/high speed device. also some modern usb devices don't have a physical resistor on data lines. they are inside asics and connected by inside fet transistors as found in isp707. i can't control how kernel deal with those cips . and i think this pull-up resistor is not connected instantly so the driver don't act well.
in sys log i see "Forcemode... no device attached" followed immediately by "Forcemode ... full spped device detected" .
my script is "event driven" so it wait for vbus changes, and sys messages. setting speed is not a problem but driver don't act as expected.
in one case i see "b-host" state :D

Late edit:
i found proper ( stable) procedure for sensing low speed devices when high or full speed is set.
rmmod g_file_storage is the key ( workaround ) . proper solution is interrupt deactivation for "vbus stable"

Re: [Announce] USB hostmode beta release
 

I don't talk about libs, I related to the way you get syslog/dmesg logs from kernel. Not all systems have pkg sysklogd installed, and on those who have you will need to use sth along the line of "tail -f /var/log/syslog" as the only alternative source for kernel logging (/proc/kmesg) is already occupied by the syslog daemon, I.E. a logger msg would either go to syslog or to your process listening to /proc/kmsg then on a random basis, if you'd use /proc/kmsg on a system with syslog installed.
On systems that have no /var/log/syslog OTOH you either install sysklogd pkg to get /var/log/syslog, or you need to use /proc/kmsg.


you mostly lost me on all that, except the "event driven" detail. I'm not aware of any such bug and couldn't figure how normal hostmode would work if normal peripherals wouldn't adhere to the standards regarding pullup/down resistors. What do you mean by "interrupt deactivation"? The state changes on USB/VBUS are sensed by ke-recv and/or hulda process via kernel event messages, quite similar to udev. ke-recv and/or udev and/or hulda then start requester which in turn loads g_file_storage (or was it g_nokia?) - IIRC

cheers
jOERG

Re: [Announce] USB hostmode beta release
 

you are all right.
dropping vbus activate g_file storage and i don't need this.

i have final scenario:
1 stop bme
2 vbus on
3 rmmod g_file_storage
4 force low
5 F > ..
6 listen to messages ( hard speed detection )
7 if no message >> low speed device
if full/high message >> go further ( step 8 )
if no device >> exit
8 put usb in stable state ...... ( here need more tests including modprobe g_file_storage or switch to peripheral )
9 force full
11 F >
12 if message "force ..error... high speed device .. but not high.." >> go high ( soft speed detection )
exit

i don't see a fastest way

Re: [Announce] USB hostmode beta release
 

@blue_led:
What about modifing musb_procfs.c (or in other kernel parts) to do this detection in kernel?

hostmode . the script
 

@pali
it can be very possible, even OTG mode
but this depend on vbus switching and the patch will be very specialized pointing only for rx51
sensing speed of device can be done without a timer for bq24500. 32s is enough for all jobs
now it is clear for me how to do this. as my post above..
first part ->hardware detection of the device
power the vbus and read debug register
here we have 3 cases
0 no device
1 low speed device
2 high or full
after this, speed can be set and read device descriptor
if the device is high speed then switch
high speed devices can be read in full speed mode

the goal of my script is to prove the concept

@everybody

[Announce] The n900 hostmode script
features: icon, automatic speed, status area icon ,notifications, mass sotorage automount, no gui

unzip the attachment in a folder
as root run
LE: zip updated with icon file. sorry for mistake
please reload

To support efforts press "Thanks"

Re: hostmode . the script
 

Yes, this concept is correct. I don't know what you mean by "32s is enough" though. At least bq24150 watchdog will need 10s at worst case

cheers
jOERG

Re: hostmode . the script
 

for speed detection a single sequence of i2c commands is enough ( first i2c command from booston )
the kernel don't need a circular timer for stable vbus for speedcheck
a single 32s pulse** for first hardware testing, and a second pulse for full - high selection ( ** turned off when not necesary )
then set a modified procfs. echo A(utosense) > /sys/.....?
a simple program from userspace can check this output then start with the corect speed.
i think is there is a great complication stopping bme and start a circular timer from kernel space. for sure the timer can do the job easy "from inside"

i will make a modification in the script with single i2c command for first speed ckeck.
this avoid ugly killall booston in first step
a simple daemon can watch ID* pin so triggering the host will make things simplier and natural

*with filled CA-157 cable or uAsoket

please provide feedback about the script (PM or .. your choice )

Re: [Announce] USB hostmode beta release
 

blue_led, wouldn't it be profitable, to write how correct order of doing things should look, using Your script? I mean executing it before/after connecting device physically, etc. I think it would save us plentora of false bug reports/"it doesn't work for me" posts.

As for script itself, I got strange results testing it with my low-speed USB keyboard, connected to high-speed hub. It result in connecting hub at full-speed (I'm 100% sure hub is high-speed), but I'm not rising alarm, until I get opportunity to check it with another female-female adaptor (loose connection may be the case here). In HEN, sometimes full/low-speed tolerates loose cables, while high doesn't...

I'm waiting eagerly for other reports, cause I've lost hope for new GUI released by MAG.

/Estel

// Edit
I'm using joerg_rw's improved booston.

Re: [Announce] USB hostmode beta release
 

I'm writing bq2415x charging kernel module, so something related should be done in this module too (as replacement for BME).
http://atrey.karlin.mff.cuni.cz/~pali/bq2415x/

Re: [Announce] USB hostmode beta release
 

yes. otg vbus controll and force boost sysfs :D

@estel
i always start with device conected using original h-e-n or my script. connect the device and tap host icon. that's all :) is irelevant the moment of the connection until vbus go on
without external power i have no problem with 1hub, 1 sd card reader+card, and a mouse all connected together copying files and working with the mouse !
if your n900 loose vbus ... no hope. any vbus drop below 4.4 V will lost the host
you should have an icon pointing to the script. the shortcut can be added as usual on any desktop .
if icon is a blue square then reboot.
why you need gui. it is an programmer tool !! i say with full respect to Mohammad work

addendum
@estel
i confirm there is a bug.
with some hubs with integrated cardreaders the script will fail.( timeout problems )
an updated version will come

Re: [Announce] USB hostmode beta release
 

Thank you. With this file it has worked well.

Re: [Announce] USB hostmode beta release
 

The script works with several pendrive I've tried.

What if I'm using an external power source, the N900 starts loading?

Re: [Announce] USB hostmode beta release
 

@blue_led

Thanks for answer. Another small suggestion - could You consider including improved booston in Your script set? I've copied it manually - to check if it works - but, normally, it contain vanilla version of booston straight from H-E-N.

/Estel

//Edit
Not rellevant to script set, but I'm quite surprised, that You can use H-E-N with USB stuff connected before vbooston. I was never able to do that - in my case, correct order is to plug device shortly after booston, before enumerating (obviously). Otherwise, I get bunch of errors like "device not accepting address xyz".

// Edit 2
As for whitewolf suggestion, please *don't* enable charging with external power detected, at least by default. There are use cases - at least, in my situation - hen I don't want N900 to charge, at the same time powering USB devices (connected to it) externally via Y-cable/powered HUB.

In other cases, executing boostoff && charge.sh is simple enough.

Re: [Announce] USB hostmode beta release
 

// Edit 2
As for whitewolf suggestion, please *don't* enable charging with external power detected, at least by default. There are use cases - at least, in my situation - hen I don't want N900 to charge, at the same time powering USB devices (connected to it) externally via Y-cable/powered HUB.


why not? if you're using HEN it's going to run out of battery alot sooner then if you wasn't using HEN.

Maybe you shouldn't even be using the Y adapter, instead just use plain powered hub, which wont return charge to the phone.

So for me, I would rather it charge on external power.
Besides, I think the charge.sh script only charges when the battery isn't full.

Re: [Announce] USB hostmode beta release
 

First of all, some powered hubs does provide power to uplink. Yea, I know they shouldn't, but...

Second, it's not healthy for battery (life) to keep it at max voltage. LiPo's (LiIon's, in particular) like best to be keep between 20-80%. For people working for hours with keyboard/mouse connected to N900, keeping it auto-charged is extremely unhealthy for battery.

Not mentioning plentora of other situations, like calibrating battery chip, etc.

As for "charging only to 100%", what else do You want? Battery exploding due to overcharge? ;)

In any case, invoking charge.sh when someone want charging, is easy enough. You won't get other charging method during hostmode, anyway.

/Estel

Re: [Announce] USB hostmode beta release
 

While I am aware. My English is not very good.

¿I can or not to load while I have connected a USB device? Should I not do? I refer to your script, Estel

If yes, what steps should I follow.

I have a cable ready with diodes to prevent the arrival of current to the N900.

As a Y cable like this.
http://t2.gstatic.com/images?q=tbn:A...DG3SpQeL_ImYWv
The plug and cable with thinner section for additional power.

Re: [Announce] USB hostmode beta release
 

@white wolf
spanish hey.. that cable photo isn't clear.
la foto no se ve muy bien.

You'll have to do it using the old GUI,
Tienes k usa el biejo programa

Haces esto:
http://talk.maemo.org/showthread.php...203#post921203

@Estel
hmm... I guess you know more then me, I thought it would auto regulate, Just like the charge script, it shows when it's charging and when it's not.
I get a year out of a battery, leaving it on charge over night and charging at work... A year is about right for a battery tho... and they're cheap enough...

One of my biggest hate with the N900, is running out of battery :(
So I always charge :)

Edit type

Re: [Announce] USB hostmode beta release
 

@whitewolf
You can charge device, while using it in hostmode with USB device(s) enabled.

Your cable looks correct, except for fact, that diodes are *unnecessary*, and actually prevent You from charging. Using cable with diodes, You can power Your USB device externally, but You can't charge N900.

Using same design cable *without* diodes, You can both use USB devices, and charge N900.

/Estel

Ps.

charge.sh isn't my script, it's shadowjk's/joerg_rw's one, probably based on Meego (now Mer) charge.sh

@bingomion
You may consider building/purchasing dual-scud battery alongside Mugen Cover (3000 mAh of real capacity). It's relatively cheap, and battery life boost is unimaginable.

Re: [Announce] USB hostmode beta release
 

Noooo.... I love my otter box too much :D

I've bought these little beauties and hacked a USB male cable to the red/black wires for charging.. works very well.

http://www.ebay.com.au/itm/5-pcs-NEW...item2a1413254b

Re: [Announce] USB hostmode beta release
 

definitely not. ShadowJK's script is based on my original POC, and mer/meego is based on shadowJK's

and all those scripts use bq24150 built in intelligence to treat battry nicely, no overcharging, no keeping it floating at max voltage. Actually it's bme that does such nasty things, not though our script ;-). For your usecases where charging hostmode would get in the way: they sound rather niche case to me, and you better deal with them in a special manner taking into account the default behaviour of whatever BlueLED comes up with, rather than requesting that this convenience function gets not implemented into H-E-N.

cheers
jOERG

Re: hostmode . the script
 

thanks for this great app... Makes life easy!!...

But im having some problems when unmounting a drive...
It successfuly unmounts it but it reboots the phone after..
Need some help please.... Thx...

Re: hostmode . the script
 

thank you blue_led for this nice and useful script! :)
i've used it with several different usb-sticks and it always detected the correct speed. but in some cases there seem to be a problem with mounting. some of the sticks i tried weren't mounted automatically while manual mounting after the "speed detection" process was no problem. so i think it should be possible with the script too (was no problem with the mount-button in hen gui either).
what could be the problem here?

another problem is that no device is found when i use my highspeed usb hub (using one or two sticks at the same time doesn't make a difference).

i would be happy to help with testing - so if there is anything i can do let me know...

i really like how the awesome devs here make the n900 better and better with all the useful stuff they create :D

Re: [Announce] USB hostmode beta release
 

I've installed the script. My tests show that as long as a flash drive no problems.

Recognizes the speed and mounts ... the problem has arisen with my hard drives or self-powered devices. Here I have never located the devices must use the manual interface H-E-N.

This script promises.

I try to add the functionality to power the battery charging mode automatically.

Re: [Announce] USB hostmode beta release
 

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

Re: [Announce] USB hostmode beta release
 

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
so there is two solutions
a) charging_hostmode-hardware_assisted mean a delay circuit controlled by vbus and controlling voltage applied to the vbus. A delay of 40s from first high transition of vbus is enough to allow n900 to detect and controll usb-phy
a variant of this solution can be ID pin signalling on external charger after a delay. this is very easy to detect ( kernel side ) and easy to write a udev rule . ( this will be my final choice for myself )

b) status area aplet with "Charge" button > more friendly with users who are not electronic engineers

i will provide both solutions ( with schematic )

2) some mount problems
i tested my script with direct attached flash media . in case if hub is used this add a delay until flash media is detected. i assume 7s is enough .
qiuck workaround > increase the delay ( sleep 7 ) after (banner "$m13";sleep 1) line until the hdd are mounted . try 15s

some hubs don't properly handle full speed timings. in the next release high speed will have priority

the mount job will be removed from the script but unmount will be keep for a while.
automount is tested and working but abrupt remove of media can cause some problems
filemanager go crazy ( cpu ^ 80% ) if a device is removed and usb virtualhub can't handle reset event properly messing badly the things.

now i test some nasty ideas :D

the script can be used with any usb device !!
please report if anyone use script icon on desktop

Re: [Announce] USB hostmode beta release
 

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

Re: [Announce] USB hostmode beta release
 

That should be fixed in next KP

Re: [Announce] USB hostmode beta release
 

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
 

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
 

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
 

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
 

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
 

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
 

alas this won't work
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