Yes, it would be great.
And I would concentrate on kernel side - going through hub and process a disk/USB stick (I assume that this stuff is more interesting for anybody).

Just fact : when I play with usb port & procfs, on my n900, pc suite mode status hang-on even there is no usb charger, pc or any device connected !??

So good nwes for us ( from egoshin ) bme fault the otg usb host.
Q why I say still otg ?
A (my opinion ) : egoshin make work otg module. it is the only one activated by configs . Initial connection to pc is needed to initialize otg state machine as a peripheral then switch to host by HNP. The great discovery of egoshin is initial connection to pc. All previous attempt to activate host mode was made without this phase. Mode selection: usb device | pc suite, feat bme is a garbage bunch of software. We need to change all of this.
As i know, echo H > .... force HNP
egoshin, please, please try without " echo host > ..../mode

i think programmers don't read all of usb specifications
charging on host mode is now accepted by ( patched ) usb 2.0 standard . because charging circuit is INDEPENDENT from usb stuff nothing prevent this on N900
we have 2 situation
1) vbus =5v ( from external source) THEN charge if is needed. IF PC don't host . IF D+/D- short then high power charge ELSE can host if wanted.
2) vbus =0 THEN IF host then BOOST

More: this settings are made on only one f.. asic
no rocket science

From ancient n900 times : ... limitation at hardware level ....
My a.. . sorry for language.

I'm not sure whether this has been posted here already:
excerpt from drivers/usb/musb/Kconfig (it would be possible to build it with USB host only)

config USB_MUSB_HOST
depends on USB
bool "USB Host"
help
Say Y here if your system supports the USB host role.
If it has a USB "A" (rectangular), "Mini-A" (uncommon),
or "Mini-AB" connector, it supports the host role.
(With a "Mini-AB" connector, you should enable USB OTG.)

# use USB_GADGET_MUSB_HDRC not USB_MUSB_PERIPHERAL to #ifdef peripheral
# side support ... OTG needs both roles
config USB_MUSB_PERIPHERAL
depends on USB_GADGET
bool "USB Peripheral (gadget stack)"
select USB_GADGET_MUSB_HDRC
help
Say Y here if your system supports the USB peripheral role.
If it has a USB "B" (squarish), "Mini-B", or "Mini-AB"
connector, it supports the peripheral role.
(With a "Mini-AB" connector, you should enable USB OTG.)

config USB_MUSB_OTG
depends on USB && USB_GADGET && PM && EXPERIMENTAL
bool "Both host and peripheral: USB OTG (On The Go) Device"
select USB_GADGET_MUSB_HDRC
select USB_OTG
help
The most notable feature of USB OTG is support for a
"Dual-Role" device, which can act as either a device
or a host. The initial role choice can be changed
later, when two dual-role devices talk to each other.

At this writing, the OTG support in this driver is incomplete,
omitting the mandatory HNP or SRP protocols. However, some
of the cable based role switching works. (That is, grounding
the ID pin switches the controller to host mode, while leaving
it floating leaves it in peripheral mode.)

Select this if your system has a Mini-AB connector, or
to simplify certain kinds of configuration.

To implement your OTG Targeted Peripherals List (TPL), enable
USB_OTG_WHITELIST and update "drivers/usb/core/otg_whitelist.h"
to match your requirements.

endchoice

If you disable OTG, will that break the N900's ability to charge and be a peripheral?
I don't think we really want OTG, do we? We want USB host...
If we disabled OTG, is there a way to manually switch between peripheral / PC Suite mode (USB client) and USB host?
Or do egoshin's tests (success via forcing OTG mode) suggest that OTG is our only hope?

/* whitelist */
and about uB connector.... always chinese people made an adapter

and I present to you my spring collection

@titan
i don't think so . srp is there even hnp ( egoshin prove this ) but routines are full of bugs and applications know nothing about otg

@blue_led

1. "Initial connection to pc is needed to initialize otg state machine as a peripheral then switch to host by HNP. "

Not exactly. The initial connection to PC is used to avoid a problem of changing "suspend"/"resume" modes in HW and SW - the accurate procedure programming without that will take time. The HNP negotiations happens with a target device (HUB, USB stick or hard disk). If you look into /proc/driver/musb_hdrc in a mean time (after writing 'H' and while cable is connected to PC or disconnected but not connected to HUB/disk) then you can see the DEVCTL state like '9b' which means that there is not yet 'HOSTMODE' bit set. Only after you connect to hub/disk then this bit shows 1. And VBUS is needed to prevent dropping session in 1707 while you reconnect cable.

Why it is not set while connected to PC? - because HOSTREQ is activated only during transition to suspend mode but while N900 is connected to PC it is still active. And setting that bit while cable is not connected to anywhere doesn't start hostmode after subsequent connection to hub/disk.

BTW, this is only intermediate stuff - I am on crash course to find out all potential problems. The real code may use 'FORCE_HOST'. For a moment we need to find out all missed stuff.

2. Charging. I looked into debug output while connect N900 to wall charger. The last message is "musb_stop()". HW effectively is stopped.

Yes, specs allows charging while in USB working mode but that is not for high-performance charger. VBUS voltage is not enough - shortcut of D-/D+ is needed to prepare an effective charging.

So, I suspect that BME is not fixed after Nokia added 1707 and removed TWL4030 from USB path. 1707 is able to start high-speed charging without software intervention but TWL4030 is not. So, BME just prepared USB subsystem for charging while it is absent and that preparation assumes that there is TWL4030, BQXXXXX chip and it knows nothing about 1707 and it's ability for charging high-speed without software.

we'll see. perhaps the device would not even boot?
but getting host-mode working at all would be a good start, even if conflicts with charging and other USB device functions.
I'm just rebuild a kernel...
EDIT: build fails with
drivers/usb/musb/musb_core.c: In function 'musb_charger_detect':
drivers/usb/musb/musb_core.c:244: error: 'struct musb' has no member named 'g'
drivers/usb/musb/musb_core.c:245: error: 'struct musb' has no member named 'g'
drivers/usb/musb/musb_core.c: In function 'musb_stage0_irq':
drivers/usb/musb/musb_core.c:577: warning: unused variable 'r'
drivers/usb/musb/musb_core.c: In function 'musb_connect_show':
drivers/usb/musb/musb_core.c:1983: error: 'struct musb' has no member named 'softconnect'
drivers/usb/musb/musb_core.c: In function 'musb_connect_store':
drivers/usb/musb/musb_core.c:2014: error: 'struct musb' has no member named 'softconnect'
drivers/usb/musb/musb_core.c: In function 'musb_irq_work':
drivers/usb/musb/musb_core.c:2128: warning: unused variable 'old_suspend'
drivers/usb/musb/musb_core.c: In function 'musb_init_controller':
drivers/usb/musb/musb_core.c:2465: error: 'struct musb' has no member named 'g'
drivers/usb/musb/musb_core.c:2466: error: 'struct musb' has no member named 'g'

@ egoshin
Correct.
A ( time) )
A-device finishes using bus and stops all bus activity, (i.e. suspends the bus). This is pc doing someting on bus
B time )
B-device ( N900 ) detects that bus is idle for more than TB_AIDL_BDIS min and begins HNP by turning off pull-up on D+ (*) . This allows the bus to discharge to the SE0 state
so Q :WHo discharge the bus to SE0 state ?
A: the two 15k resistors on datalines but when charging is running those resistors are disabled ! right ? and for high power charger detection a source current is applied on D+ ! right ?
This curent source prevent switching to HOST by holding D+ high

isn't this a heavy & long discussed hardware limitation ?

By switching off charger & bme you allow bus discharge and reach nirvana

your procedure absolutely have sense for "manual mode" HNP
i was able to put state machine in wait to connect with ONLY a resistor of 1.5 k between vbus and D+ and a capacitor of 4.7 uF to ground but there is nobody connection capable ( for evident reason ) hnp fail. i thought to put a pic microcontroller doing hnp sequence on vbus and D+ but i have no time for that.

* If the bus was operating in HS mode, the B-device will first enter the full-speed mode

i discover this yesterday. i charge from office pc with an handmade a male to a female adapter with data shorted using stock data cable , bonus no viruses no mode selection.

I was talking about this on a previous post. The OS fails to boot; I guessed because someone is modprobing some now-incompatible module, or bme doesn't find the expected sysfs nodes.

Either way, as it is now, disabling OTG does more damage than help, as some interesting pieces of code are only built if it is enabled.

wrong post - sorry