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

Quote:

Originally Posted by joerg_rw (Post 1023402)

here an intermediate version of booston, that replaces original file and has some small goodies - a direct uncleaned copy of what's on my hostmode devel device. You might want to edit /etc/mce/mce.ini to define a new pattern "PatternVboost" signalling device is in boostmode (attached my mce.ini for an example).
Of course you may want to keep permissions and owner of original booston, and maybe you need to change the hardcoded path to ic2set in this script (the line "i2cset=/usr/local/sbin/i2cset") to your result of `which i2cset`

This is no official update but just a teaser, as I'm feeling sad with all of you while this is collecting dust on my t900.

Bear with me, a better version is about to include charging and slowly matures here...

/j

Code:

#!/bin/sh

# jrbme "just replaces bme" in fact does more than just that

# It implements FOSS charging via bq24150 and manages hostmode

# For this it implements a daemon mode which is entered by default

# when jrbme is called by user root (i.e. on system init usually) 

# and which cares about keeping battery charged and about signalling

# battery charge status and other events via system dbus 

# When called by any user who's not root, jrbme doesn't enter daemon 

# mode. Instead it serves as a cmd interface between user and a daemonized

# instance of itself, talking to the daemon via signal and named pipes,

# and reporting back to user all result codes, messages to stdout/stderr.

#

# sed -i "s/LEDPatterns=/LEDPatterns=PatternVboost;/" /etc/mce/mce.ini

# vboost with reset on exit and (#'d) partial hostmode for PF-kernel

#(c) 20101030 J.Reisenweber



set -eu

true=true

false=""



${debug=/bin/false} && set -vx; # call like ~# debug="echo -n $0; date" script.sh



#const

PatternVboost=PatternVboost

dbus-send="/usr/bin/run-standalone.sh /usr/bin/dbus-send"

i2cset=/usr/local/sbin/i2cset



#var

: ${start_bme=true}

: ${notify=true}







trap cleanup INT QUIT TERM EXIT

cleanup(){

  trap - INT QUIT TERM EXIT



  # reset bq24150

  $i2cset -y -m 0x80 2 0x6b 0x04 0x80



  # stop LED indicator 

  $dbus-send --system --type=method_call \

    --dest=com.nokia.mce /com/nokia/mce/request \

    com.nokia.mce.request.req_led_pattern_deactivate \

    string:$PatternVboost



  $debug && (

    Reg1=`$i2cget -y 2 0x6b 0x00`

    echo $Reg1

  )

  

  if [ $start_bme ]

  then

    sleep 2

    log "Starting bme"

    /sbin/start --quiet bme

  fi

  exit

}



log(){

  echo "${0}: $@"

}



logn(){

  echo -n "${0}: $@"

}



# the script body. We read in whole text, and then execute a main at end of script,

# this ensures the whole script has correct syntax and there'll be no reads at 

# runtime

main(){

  log "Stopping bme"

  /sbin/stop --quiet bme

  sleep 3

  #echo host >mode

  

  # start vbus boost 5V

  $i2cset -y -m 0x07 2 0x6b 0x01 0x05;

  

  # set notification LED

  $dbus-send --system --type=method_call \

    --dest=com.nokia.mce /com/nokia/mce/request \

    com.nokia.mce.request.req_led_pattern_activate \

    string:$PatternVboost

  

  #sleep 1

  #echo F >/proc/driver/musb-hdrc



  while sleep 5; do

    Reg1=`$i2cget -y 2 0x6b 0x00`

    if [ 8 -ne $(( Reg1 & 0x0F )) ]; then

      errortext1="ERROR in VBUS supply: BQ24150-Reg1=$Reg1"

      case $(( Reg1 & 0x07)) in

        0) errortext2="No error, just stopped";;

        1) errortext2="VBUS OVERVOLTAGE - You just fried your N900";;

        2) errortext2="OVERLOAD - N900 can deliver max 200mA. VBUS got shut off";;

        3) errortext2="Battery too low. VBUS shut off";;

        4) errortext2="Battery OVP - WTF are you doing?";;

        5) errortext2="Thermal Shutdown (too hot)";;

        6) errortext2="Watchdog expired. Script sucks";;

        *) errortext2="WTF? This should not happen";;

      esac



      log "$errortext1"

      log "$errortext2"

      if [ $notify ]; then

        $dbus-send --type=method_call --dest=org.freedesktop.Notifications \

         /org/freedesktop/Notifications \

         org.freedesktop.Notifications.SystemNoteDialog \

         string:"`echo -en "Shutting down 5V supply for USB! Reason:\n$errortext2"`" uint32:0 string:"WARN"; #no idea about WARN

      fi

      cleanup

    fi

    

    # tickle watchdog timer

    $i2cset -y -m 0x80 2 0x6b 0x00 0x80;

  done

  cleanup

}

main "$@"; exit

Using this booston via terminal, I got following error:

Code:

/usr/sbin/booston: line 25: dbus-send=/usr/bin/run-standalone.sh /usr/bin/dbus-send: not found

I've checked that both '/usr/bin/run-standalone.sh' and '/usr/bin/dbus-send' are in correct place. I hope that this will help in improving this script ;)

Also, what may cause this, and, is a chance that this prevent booston for working at all = may prevent hostmode from working correctly? I don't want to assume too early - I got problems with connecting devices (that i know worked flawlessly) with new booston script, but i'm not sure if it's generic hostmode error (i.e. I need to try again few more times), or something with booston.

// Edit

Led pattern is correctly created, ho ever, it doesn't work when I use new booston (even when phone locked or screen off). I suspect it's related to dbus-send fail, ho ever, I still don't know if it prevent booston from working as whole.

Sub-edit:
It seems to me, that due to aforementioned error, new booston doesn't want to work at all on my device. I've tried multiple times to connect device, but even kernel-messages doesn't seem to show any activity on booston, no matter if called from GUI or terminal.

Resurrecting old booston fixed this, and every device, that failed with new booston, works fine now.

// Edit 2

Slightly different topic - I *may* have found something related to "generic hostmode error" (i.e. it doesn't work, and we don't know why), people are experiencing sometimes.

I've checked kernel messages in different situations, when I try to attach my (working flawlessly with HEN, normally) pendrive. Usually, when it does not want to work, it says:

Code:

Forced hostmode error: a full/low-speed device attached but high-speed mode selected

Of course pendrive in question is high-speed device for 100%. Ho ever, I noticed that, when such error appear, and I disconnect my device/adapter/cable at all (same result in every combination), then start from the beginning, kernel messages also state mentioned forced hostmode error - even when no device is attached at all!

Even restarting HEN totally doesn't make difference. If it get "stuck" like that, I've to try again and again, and, it *should* "unstuck" on n attempt. There was no situations, on which I was not able to connect my device at all (but, keep in mind, that I'm somehow stubborn one), it got to work, sooner or later. Still, I got no idea what may cause this type of error.

Of course, trying to use full-speed or low-speed also doesn't solve the problem. It just have to "unstuck". I feel that device may assume something wrong is connected, even before actual device is connected, but I may be wrong.

// Edit 3
sorry for providing so much info/text in one post, but I think it's worth mentioning without delay. Is there any "forced wait" before enabling/disabling booston, and enabling it again?

I'm asking, because, another "scenario" when hostmode reject to work properly, is when I try few devices "in a row". Initially it works, but after few device switches, it stop working, giving constant:

Code:

device descriptor read/64, error -71

I'm thinking it may be related to booston, because, normally, when you call booston, a:

Code:

twl4030_usb twl4030_usb: HW_CONDITIONS 0x50/80: link 1

...appear in kernel messages. Ho ever, when such error situation occur, there is no info about twl4030_usb anywhere in log. I've also tried to just enable booston, without actually connecting and enumerating device - it just doesn't appear to do anything. If i left device alone for few minutes, it work again as it should, and booston result in twl4030_usb info popping up.

I think it may be also responsible for high ammount of user-case fails with hostmode - if people constantly try to connect device, booston doesn't get "unstuck".