Re: N900 does now allow USB hostmode!
 

I researched a log and a kernel. The diagnostics shows that with VBUS=1 from BQxxxxx chip (no setup of VBUS in TWL4030) hard disk doesn't respond while N900 reads messages from it...

EDIT: USB memory stick, not hard disk.

But self-powered hub still responds.

Re: N900 will not allow USB OTG!
 

Success!

I just was able to mount USB stick via self-powered HUB and read it.

Device - /dev/sda1

Details will be later, but now - modified kernel. I am looking into right modification.

BTW, the USB stick problem with VBUS from BQxxxxx seems to be a connector problem - I was able to communicate with it too (USB stick directly connected to N900).

Re: N900 will not allow USB OTG!
 

I'm sure it goes without saying... but you are the man. Well, you and all the other people who helped are the collective man. Any chance the requisite fixes can be folded into titan's kernel?

Re: N900 will not allow USB OTG!
 

I just got a hostmode-only kernel running!
it boots up normally, battery info and USB charging is broken (as expected)
WARNING: this is only for experienced developers! do not install as noob
http://maemory.com/N900/kernel/hostmode/
you need to replace /etc/event.d/bme with my modified file (make a backup!).
In the worst case it ends up in a reboot loop due to bme.
you could uncomment the line "cp /etc/event.replace.d/..." in the script to
restore the original at the first start. if it fails to boot you would
only need to reflash the stock kernel.

EDIT: bascially bme dies during boot but booting continues. so no workarounds for bme are needed :)

now if I only had my USB F/F adapter here...

Re: N900 will not allow USB OTG!
 

Titan just booted a hostmode-only kernel this very moment.
Egoshin's method implies conecting the N900 to a PC prior to switching to hostmode, and that won't help a lot out in the field, will it?
See 1. to 5. For the answer "PC suite" part see also http://talk.maemo.org/showthread.php...357#post635357

So we still struggle to get GENERIC hostmode, not a tricky way to put OTG statemachine into a pathological state by fiddling with VBUS timings, where it detects a drive as another OTG peer.
Stay calm and patient and wait what's going on, all the smart people know you want hostmode as soon as possible, and neither Titan nor anybody else will hesitate to ship whatever is needed to put it to work for everybody, once we figured how to implement a reliable useful thing. At the moment this is still bleeding edge R&D, and surely it's strongly discourraged for non-developers to try and put it to use, as there's no evaluation whatsoever about risks, and it's simply not yet working for the intended usecases.

cheers
jOERG

[edit] titan beat me on posting speed ;-) so please excuse if this sounds a bit weird, as I wasn't aware of his previous post when I hit the "reply" button

Re: N900 will not allow USB OTG!
 

look into /etc/bme & /etc/event.d/bme.dpkg-new
at the end of bme f* script !

description "starting bme"
author "Simo Piiroinen"

console output

start on started dsme
stop on starting shutdown

service
nice -1

env LOGGER='/usr/bin/logger -s -tBME'
env STOP_FLAG=/tmp/bme.was.stopped

env SYSFS_VBUS_PATH=/sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/vbus
env BACKLIGHT_PATH=/sys/class/backlight/acx565akm/brightness

pre-start script
set +e
$LOGGER -pdaemon.notice 'pre-start'

EXPORT_CARDS=0

case $(cat /tmp/STATE) in
USER)
if [ -e /var/lib/ke-recv/usb_phonet_mode ]; then
modprobe g_nokia || true
initctl emit G_NOKIA_READY
else
modprobe g_file_storage luns=2 stall=0 removable || true
fi
;;
ACT_DEAD)
modprobe g_file_storage luns=2 stall=0 || true
EXPORT_CARDS=1
;;
*)
$LOGGER -pdaemon.notice 'skip modprobe g_*'
;;
esac

DISC='/dev/mmcblk0p1'
CARD='/dev/mmcblk1'

LUN0='/sys/devices/platform/musb_hdrc/gadget/gadget-lun0/file'
LUN1='/sys/devices/platform/musb_hdrc/gadget/gadget-lun1/file'

if [ $EXPORT_CARDS -eq 1 ]; then
if [ -b $DISC ]; then
echo $DISC > $LUN0 || true
fi
if [ -b $CARD ]; then
echo $CARD > $LUN1 || true
fi
fi

if ! /usr/sbin/waitfordsme ; then
$LOGGER -pdaemon.crit 'waitfordsme failed'
exit 1
fi

# check dead battery pre-charge
# (or poweroff if battery can't be charged)
if [ $(cat $SYSFS_VBUS_PATH) -eq 1 ]; then
$LOGGER -pdaemon.notice 'starting battery precharge'

# Minimize power usage during pre-charge
echo 0 > $BACKLIGHT_PATH

# Drive yellow led with device charging pattern to improve UX
# Must be done before actually running the "bme-RX-51 -b" - its slow

# Clearing LED-state to be sure
echo "disabled" > /sys/class/i2c-adapter/i2c-2/2-0032/engine1_mode
echo "disabled" > /sys/class/i2c-adapter/i2c-2/2-0032/engine2_mode
echo 0 > /sys/class/leds/lp5523:r/brightness
echo 0 > /sys/class/leds/lp5523:g/brightness
echo 0 > /sys/class/leds/lp5523:b/brightness

# Setting yellow light pattern and running it
echo "load" > /sys/class/i2c-adapter/i2c-2/2-0032/engine1_mode
echo "000001100" > /sys/class/i2c-adapter/i2c-2/2-0032/engine1_leds
echo "9d804000427f0d7f7f007f0042000000" > /sys/class/i2c-adapter/i2c-2/2-0032/engine1_load
echo "load" > /sys/class/i2c-adapter/i2c-2/2-0032/engine2_mode
echo "000000000" > /sys/class/i2c-adapter/i2c-2/2-0032/engine2_leds
echo "9d800000" > /sys/class/i2c-adapter/i2c-2/2-0032/engine2_load
echo "run" > /sys/class/i2c-adapter/i2c-2/2-0032/engine2_mode
echo "run" > /sys/class/i2c-adapter/i2c-2/2-0032/engine1_mode
echo 20 > /sys/class/leds/lp5523:r/led_current
echo 2 > /sys/class/leds/lp5523:g/led_current
echo 0 > /sys/class/leds/lp5523:b/led_current

/usr/sbin/bme_RX-51 -b
case $? in
0)
$LOGGER -pdaemon.notice 'precharge -> ok'
;;
2)
$LOGGER -pdaemon.crit 'precharge -> power off'
# power off request has been sent to dsme

# Turn off charging-LED to avoid "ghost charging" when cable removed
echo "disabled" > /sys/class/i2c-adapter/i2c-2/2-0032/engine1_mode
echo "disabled" > /sys/class/i2c-adapter/i2c-2/2-0032/engine2_mode
echo 0 > /sys/class/leds/lp5523:r/brightness
echo 0 > /sys/class/leds/lp5523:g/brightness
echo 0 > /sys/class/leds/lp5523:b/brightness

exit 1
;;
*)
$LOGGER -pdaemon.crit 'precharge -> failure'
# some mystery failure, continue startup
;;
esac
fi
end script

script
set +e
$LOGGER -pdaemon.notice 'start'
exec /usr/sbin/bme_RX-51
end script

# create flag file if bme is stopped on purpose (via upstart)
pre-stop script
set +e
$LOGGER -pdaemon.notice 'pre-stop'
touch $STOP_FLAG
end script

# reboot the device if flag file is not present (bme crashed)
post-stop script
set +e
$LOGGER -pdaemon.notice 'post-stop'
if [ -e $STOP_FLAG ]; then
rm $STOP_FLAG
else
$LOGGER -pdaemon.crit "crash detected -> rebooting"
/usr/sbin/dsmetool --reboot
fi
end script

Re: N900 will not allow USB OTG!
 

Mentioned that on #maemo over the IRC, no idea if joerg_rw checked it out or not

Re: N900 will not allow USB OTG!
 

Thanks all of you! I have no idea what anyone is talking about, but it looks like some real progress is being made :)

Re: N900 will not allow USB OTG!
 

I looked into that by going over the results of 'grep bme /etc', so I was of course aware of that. Why do you think I suggested 'stop bme', and why I suggested to Titan (and others) to remove bme references in init.d/upstart-event scripts?
It's pretty clear bme needs to be started first, if it wants to tear down the device. So if we don't start it in init/upstart it probably won't reboot the kernel.

I'm a little unsure though about that (from top):
[2010-05-13 16:25:28] <DocScrutinizer> t-tan: [2010-05-13 00:41:14] <DocScrutinizer> PP:hald-runer PID:821 hald-addon-usb-cable: listening on /sys/devices/platform/musb_hdrc/usb1/../mode

I.E. we don't know what relies on a working BME and in which way.

There's one thing we can be sure though: battery will not explode or otherwise be killed when there's no bme. The bq24150 will wake up to sane safe defaults like max USB current 100mA, max battery charge voltage 3.7V, and it should start charging with these parameters, for at least 32min ("recover from flat battery" scheme). With a little luck (and support from a correctly configured 1707 PHY chip) the bq24150 will detect a dedicated charger (D+/- short) and crank up max USB current to 500mA. But no matter if it starts charging, and at which rate - it never will overcharge the battery unless there's a bme forcing it to do that. So removing / replacing bme is as safe as any other software project, you can do nasty things if you *want*, but they won't happen by accident. A failing or nonexistent bme will NOT cause any hazard.

/j

Re: N900 will not allow USB OTG!
 

If you want repeat a test, some detailed explanation is here:

A. You need a modified kernel build from 2.6.28-20100903+0m5. A default kernel configuration arch/arm/configs/rx51_defconfig should be modified:

1 - remove CONFIG_USB_OTG_WHITELIST and CONFIG_USB_OTG_BLACKLIST_HUB options.

2 - Apply an attached patch (u.txt) to kernel sources.

3 - Build a kernel.

B. Boot a kernel

C. Connect to PC and answer "PC Suite" to mode question.

D. echo host >/sys/devices/platform/musb_hdrc/mode
You should see in /var/log/syslog a message "twl4030_set_host() after 4030 OTG_CTRL=0x26" - the '2' is a significant.

E. echo H >/proc/driver/musb_hdrc

F. reattach USB cable from PC to self powered USB hub with memory stick or to external hard disk.

E. Look into /var/log/syslog - You can see a lot of messages and two are most valuable - "Initializing USB Mass Storage driver" and "
USB Mass Storage support registered". And in between you may see "scsi0 : SCSI emulation for USB Mass Storage devices".

F. After some time the scanning finishes and you may execute

mount /dev/sda1 /mnt

(check /dev/sda1 first!)

Viola!

If somebody could repeat it - it would be a very good information, I worries about some HW differences or wrong setup of D+/D-.

I also attach a copy of my log for reference (a lot of debug output here).

Note: ke_recv has some problem with storage recognition and it is a reason why a manual mount is needed. Don't forget to unmount before cable detachment. Or just switch N900 OFF.