[KERNEL][ICS-CM9 or JVU] USB Host mode (OTG) driver for SGS i9000 [BUILD 5]

Search This thread

sztupy

Inactive Recognized Developer
Dec 21, 2008
1,061
877
Edinburgh
sztupy.hu
Well, I do have it working correctly now on your ICS-CM9 kernel. It will be working from DSLR Controller v0.85. Should be on the Market in a few

Good to hear, but I'm curious what the problem was, cause if DSLR controller works on other devices with built in host support, that means something is missing here (either in the kernel or in the ICS ROM itself)
 

sztupy

Inactive Recognized Developer
Dec 21, 2008
1,061
877
Edinburgh
sztupy.hu
I'm not sure what's up with Semaphore 2.6.0/JVU, but as soon as I switch the device into host mode, the device freezes and reboots (only if hub connected). This is with the exact same setup as under ICS-CM9.

I haven't seen how the backporting was done, so I have no idea either. I did fixed the root hub though, so in build2 connecting the camera should as simple as using only an y cable with power (as fortunately canon use miniusb ports), no external hub is needed.


Sent from my GT-I9000 using XDA App
 

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,452
87,862
www.chainfire.eu
I just didn't knew how it worked on other devices, as I only own an SGS. And I thought that mounting in external_sd is considered bad practice (like ext sd is mounted in emmc in non samsung roms). But that's also why there is an option to change the mount point.

This is not mounting in /sdcard/external_sd/, it is mounting in /sdcard/usbStorage/...

As for it being bad practise... according to whom? Douchebags? HTC? Is it ideal? No it isn't, but it's a lot less silly than mounting a secondary card in /mnt/whatever or /emmc or whatnot. Why? Because the Android API has no provisions to detect or use these things, so it's all completely useless to normal apps not specially designed to take advantage of these non-standard paths (which are often hardcoded as well).

From a Linux viewpoint /mnt/whatever would make more sense. From an Android standpoint, /sdcard/whatever is the place to be.

Until such times that a proper mechanism and API is devised by Google to work with this, the only practical place to mount world-writable disks/partitions/drivers/usbsticks/networkdrives/etc is in /sdcard/... And for USB mounted stuff other Samsung devices happen to use /sdcard/usbStorage/sda (sda1, sdb, etc).

(upon re-reading, the above sounds a bit unfriendly - it is not meant to be unfriendly)

Good to hear, but I'm curious what the problem was, cause if DSLR controller works on other devices with built in host support, that means something is missing here (either in the kernel or in the ICS ROM itself)

There are multiple parts to USB host. You have your basic kernel support that your patch (in combo with your app) offers, then you have the Android USB host APIs (that require USB host kernel, obviously). These are Java APIs officially introduced in Honeycomb (3.1).

DSLR Controller is mostly based on those Java APIs, because it allows you to get raw access to USB devices without root.

Older devices may support only kernel USB host and not the APIs (like various Gingerbread Samsungs). For those, I have backported the Android USB host APIs, BUT this requires root to get permissions on the USB device.

So if you do not have root but a proper 3.1+ Android build, DSLR Controller will work. Else, DSLR Controller requires root.

There is a third class of USB host supporting devices: devices that actually do have the Android USB host APIs AND "advertise" to apps that this works, AND have working USB host kernels, BUT the API doesn't actually work (actually not uncommon!). The SGS with ICS and your kernel falls into this category. DSLR Controller was _meant_ to handle this situation, but I never had a device with this problem so I couldn't test it. And it appears there was a bug in this handling. This is now fixed (literally a one-line fix in the code).

... or, to make a long story short: a bug in DSLR Controller has been fixed :)

I haven't seen how the backporting was done, so I have no idea either. I did fixed the root hub though, so in build2 connecting the camera should as simple as using only an y cable with power (as fortunately canon use miniusb ports), no external hub is needed.

Will it still work with an external HUB ? (I don't have a y-cable only hubs... any advice on where to get a good one?)
 

sztupy

Inactive Recognized Developer
Dec 21, 2008
1,061
877
Edinburgh
sztupy.hu
(upon re-reading, the above sounds a bit unfriendly - it is not meant to be unfriendly)

Yeah, it was. not that I care :)

I too think the main problem is the lack of official android devices with more external memories than one. But there is a good reason while CM didn't choose the /sdcard way: mounting in /sdcard has the unfortunate disadvantage that the sd card might be removed (like when using the phone as a mass storage device - although this is not a problem in this case as you cannot use the phone as a mass storage device _and_ have usb host at the same time). That's why they mainly chose to have separate mount points in /mnt. Meanwhile the standard on samsung is to mount everything in /sdcard (I don't know how other vendors with external and internal memory solve this. I think they go the samsung way though for reasons you have mentioned).

I will extend UHC to handle both mount points the easy way though. It's better to support both standards than to use only one.

There is a third class of USB host supporting devices: devices that actually do have the Android USB host APIs AND "advertise" to apps that this works, AND have working USB host kernels, BUT the API doesn't actually work (actually not uncommon!).

This is the actual part I want to fix. I know there aren't many usb host supporting apps there, but the proper API support would be nice. It seems I have to fix the ICS build for this though.

Will it still work with an external HUB ? (I don't have a y-cable only hubs... any advice on where to get a good one?)

Of course, it's just that the root hub had some bugs that made using an external hub more stable (I think I mentioned this in the intro too). I fixed this bug, so connecting the device straight to the phone should be as stable as connecting it through an external hub now. This does simplify connecting to one device if it has a mini-usb connector (and most stuff that you want to connect to /external hard drives and canon dslr's/ are among them).

I have a lot of Y cables, as it's a usual accessory for small, bus powered external hard drives, which I have a few. And it's only 0,8€ in the cheapest local store. (and not much more expensive from some sellers at ebay) "Frankensteining" together a Y-cable and an USB-A extension cord is also very easy (you don't even have to solder anything) and cheap. Much cheaper than an (powered) external hub, and has the advantage that it works for sure (as you will connect it to a device that is proper USB 2.0). I never thought there will be much problems with external hubs, but it seems a common problem :(
 
Last edited:

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,452
87,862
www.chainfire.eu
This is the actual part I want to fix. I know there aren't many usb host supporting apps there, but the proper API support would be nice. It seems I have to fix the ICS build for this though.

Probably, yes. It can't be a big change that is needed - if it was, DSLR Controller (in rooted native code mode) wouldn't work either (same codebase) ! I'm not sure how I could help, though.


Would this work ?

PT-C165L-usb-a-mini-5p-kabel-g.jpg
 

sztupy

Inactive Recognized Developer
Dec 21, 2008
1,061
877
Edinburgh
sztupy.hu
Probably, yes. It can't be a big change that is needed - if it was, DSLR Controller (in rooted native code mode) wouldn't work either (same codebase) ! I'm not sure how I could help, though.

Unfortunately I only own an SGS, and I don't really know how other devices work. (I did order very a cheap chinese tablet with ics and otg support though, should be getting it in a few weeks). If it's not a problem I might PM you if I've found out something in the ICS code that makes this working / not working.


Yep.
 

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,452
87,862
www.chainfire.eu
Unfortunately I only own an SGS, and I don't really know how other devices work. (I did order very a cheap chinese tablet with ics and otg support though, should be getting it in a few weeks). If it's not a problem I might PM you if I've found out something in the ICS code that makes this working / not working.

PM me anytime. Can't always guarantee quick response, but I'll do my best.

It may simply be something that gets automatically excluded if the kernel isn't built with USB host in the build setup...


Great! I wasn't sure if that was really the type of cable I needed.
 
  • Like
Reactions: sztupy

nsa666

Senior Member
Jan 16, 2008
258
14
@Chainfire Can you post here when the new version of dslr-controller is out? Just waiting for working version to buy it.
 

AdamOutler

Retired Senior Recognized Developer
Feb 18, 2011
5,224
9,827
Miami, Fl̨̞̲̟̦̀̈̃͛҃҅͟orida
Haven't used a serial console on the phone. What's the easiest way to get / create a cable where pins 4-5 have a 619k resistance?

I saw this one here: http://attachments.xda-developers.com/attachment.php?attachmentid=443036&d=1289991784 which seems to be nice, though the best I thing I could find in the local store is a miniusb-microusb converter, where I could solder some wires to the miniusb part (as it's a bit easier to handle than a microusb). Not sure whether it has all 5 pins connected though.

Could you also direct me to a link where I could find more about SBL commands that can be used in a serial console? Thanks!

There's no real link where you can learn about the SBL> prompt, officially. I did set up something here: http://xdaforums.com/showthread.php?t=1209288
If you want to develop bootloaders, you'll need internal UART because the PBL initializes the FSA chip which was used in the last link: http://xdaforums.com/showthread.php?t=1235219 and http://xdaforums.com/showthread.php?t=1206216 I don't have the internal points for i9000

Here's the code I run on my Arduino: http://xdaforums.com/showpost.php?p=13351363&postcount=223


I just received a Samsung GalaxyS2 yesterday and I was able to get in on internal UART to obtain this for you....
normal:
Code:
SBL> usb_read 
---------read MUIC register : multiple
(0x0 : 0x5d),  (0x1 : 0x0),  (0x2 : 0x0),  (0x3 : 0x0),  
(0x4 : 0x3f),  (0x5 : 0x0),  (0x6 : 0x0),  (0x7 : 0x0),  
(0x8 : 0x0),  (0x9 : 0x0),  (0xa : 0xd),  (0xb : 0x0),  
(0xc : 0x0),  (0xd : 0x3a),  (0xe : 0x0),  
SBL>

with USB-OTG cable connected
Code:
SBL> usb_read
---------read MUIC register : multiple
(0x0 : 0x5d),  (0x1 : 0x3),  (0x2 : 0x0),  (0x3 : 0x0),  
(0x4 : 0x0),  (0x5 : 0x0),  (0x6 : 0x0),  (0x7 : 0x0),  
(0x8 : 0x0),  (0x9 : 0x0),  (0xa : 0xd),  (0xb : 0x0),  
(0xc : 0x0),  (0xd : 0x3a),  (0xe : 0x0),  
SBL>

Kernel commandline:
Code:
ATAG_CMDLINE: 39 54410009 'loglevel=4 console=/dev/ttySAC2 sec_debug.enable=0 sec_debug.enable_user=0 c1_watchdog.sec_pet=5 sec_log=0x100000@0x5ea00000 s3cfb.bootloaderfb=0x5ec00000 ld9040.get_lcdtype=0x2 consoleblank=0 lpj=3981312 vmalloc=144m

Your Params.lfs file:
Code:
SBL> printenv
PARAM Rev 1.3
SERIAL_SPEED : 7
LOAD_RAMDISK : 0
BOOT_DELAY : 0
LCD_LEVEL : 97
SWITCH_SEL : 1
PHONE_DEBUG_ON : 1
LCD_DIM_LEVEL : 0
LCD_DIM_TIME : 6
MELODY_MODE : 1
REBOOT_MODE : 0
NATION_SEL : 0
LANGUAGE_SEL : 0
SET_DEFAULT_PARAM : 0
FLASH_LOCK_STATUS : 1
PARAM_INT_14 : 0
VERSION : I9000XXIL
CMDLINE : loglevel=4 console=ram
DELTA_LOCATION : /mnt/rsv
PARAM_STR_3 : 
PARAM_STR_4 :

This is the meat of what is available from the SBL prompt. It's quite a bit. However, there is alot more. These are only what I find interesting currently...
 
  • Like
Reactions: sztupy

sztupy

Inactive Recognized Developer
Dec 21, 2008
1,061
877
Edinburgh
sztupy.hu
There's no real link where you can learn about the SBL> prompt, officially. I did set up something here: http://xdaforums.com/showthread.php?t=1209288
If you want to develop bootloaders, you'll need internal UART because the PBL initializes the FSA chip which was used in the last link: http://xdaforums.com/showthread.php?t=1235219 and http://xdaforums.com/showthread.php?t=1206216 I don't have the internal points for i9000

Here's the code I run on my Arduino: http://xdaforums.com/showpost.php?p=13351363&postcount=223


I just received a Samsung GalaxyS2 yesterday and I was able to get in on internal UART to obtain this for you....
normal:
Code:
SBL> usb_read 
---------read MUIC register : multiple
(0x0 : 0x5d),  (0x1 : 0x0),  (0x2 : 0x0),  (0x3 : 0x0),  
(0x4 : 0x3f),  (0x5 : 0x0),  (0x6 : 0x0),  (0x7 : 0x0),  
(0x8 : 0x0),  (0x9 : 0x0),  (0xa : 0xd),  (0xb : 0x0),  
(0xc : 0x0),  (0xd : 0x3a),  (0xe : 0x0),  
SBL>

with USB-OTG cable connected
Code:
SBL> usb_read
---------read MUIC register : multiple
(0x0 : 0x5d),  (0x1 : 0x3),  (0x2 : 0x0),  (0x3 : 0x0),  
(0x4 : 0x0),  (0x5 : 0x0),  (0x6 : 0x0),  (0x7 : 0x0),  
(0x8 : 0x0),  (0x9 : 0x0),  (0xa : 0xd),  (0xb : 0x0),  
(0xc : 0x0),  (0xd : 0x3a),  (0xe : 0x0),  
SBL>

Kernel commandline:
Code:
ATAG_CMDLINE: 39 54410009 'loglevel=4 console=/dev/ttySAC2 sec_debug.enable=0 sec_debug.enable_user=0 c1_watchdog.sec_pet=5 sec_log=0x100000@0x5ea00000 s3cfb.bootloaderfb=0x5ec00000 ld9040.get_lcdtype=0x2 consoleblank=0 lpj=3981312 vmalloc=144m

Your Params.lfs file:
Code:
SBL> printenv
PARAM Rev 1.3
SERIAL_SPEED : 7
LOAD_RAMDISK : 0
BOOT_DELAY : 0
LCD_LEVEL : 97
SWITCH_SEL : 1
PHONE_DEBUG_ON : 1
LCD_DIM_LEVEL : 0
LCD_DIM_TIME : 6
MELODY_MODE : 1
REBOOT_MODE : 0
NATION_SEL : 0
LANGUAGE_SEL : 0
SET_DEFAULT_PARAM : 0
FLASH_LOCK_STATUS : 1
PARAM_INT_14 : 0
VERSION : I9000XXIL
CMDLINE : loglevel=4 console=ram
DELTA_LOCATION : /mnt/rsv
PARAM_STR_3 : 
PARAM_STR_4 :

This is the meat of what is available from the SBL prompt. It's quite a bit. However, there is alot more. These are only what I find interesting currently...

Thanks for this. I couldn't figure out what MUIC stand for. Do you know?

I checked the kernel code of the SGS2, which had two differences than the code of the SGT:

1. when initializing the otg controller, it sets one of the bits as true, while the SGT set it as false. I tried both, haven't noticed anything changing
2. It initializes a charge pump using GPIO GPX3.3. Probably this is what is powering the device. Couldn't find anything related to this in the SGT/SGS files. I've tried setting some of the unused gpio pins (there are a few unused GPH pins) but nothing changed

About the UART: I usually use a USB-RS232 converter and a simple homemade RS232-UART (5v or 3.3v) converter for debugging. (giving serial commands from the PC). This setup should work too, right?

Btw. I don't think I'll tear the SGS apart for the internal uart. I haven't got any other phones :)
 

sztupy

Inactive Recognized Developer
Dec 21, 2008
1,061
877
Edinburgh
sztupy.hu
2. It initializes a charge pump using GPIO GPX3.3. Probably this is what is powering the device. Couldn't find anything related to this in the SGT/SGS files. I've tried setting some of the unused gpio pins (there are a few unused GPH pins) but nothing changed

Ah, now that I have the S5PV210 documentation it states that it's GPIO ETC2.5 (page 2-122):

ETC2[5] XuotgDRVVBUS USB OTG charge pump enable 0
ETC2[6] XuhostPWREN USB HOST charge pump enable 0
ETC2[7] XuhostOVERCUR USB HOST oevercurrent flag 0

changing this pin doesn't seem to do anything though
 

AdamOutler

Retired Senior Recognized Developer
Feb 18, 2011
5,224
9,827
Miami, Fl̨̞̲̟̦̀̈̃͛҃҅͟orida
Ah, now that I have the S5PV210 documentation it states that it's GPIO ETC2.5 (page 2-122):

ETC2[5] XuotgDRVVBUS USB OTG charge pump enable 0
ETC2[6] XuhostPWREN USB HOST charge pump enable 0
ETC2[7] XuhostOVERCUR USB HOST oevercurrent flag 0

changing this pin doesn't seem to do anything though

you'll likely need to change that pin and route it through the FSA chip registers. the FSA is the gateway... its an input and output to many lines on the processor including audio, video, UART2, USB PHY0 (OTG) and USB PHY1(HOST). It has an I2C connection with the processor for controlling functions like "play" and "pause". It also has 2 separate lines which control boot mode and power modes. This chip is very important. It would not surprise me if tweaking those registers AND enabling charge pump is required.
 

sztupy

Inactive Recognized Developer
Dec 21, 2008
1,061
877
Edinburgh
sztupy.hu
you'll likely need to change that pin and route it through the FSA chip registers. the FSA is the gateway... its an input and output to many lines on the processor including audio, video, UART2, USB PHY0 (OTG) and USB PHY1(HOST). It has an I2C connection with the processor for controlling functions like "play" and "pause". It also has 2 separate lines which control boot mode and power modes. This chip is very important. It would not surprise me if tweaking those registers AND enabling charge pump is required.

To bad the FSA documentation avialable is for the 928x, while the phone has a 948x, the former lacking USB OTG support (this can be seen in the kernel sources as the register values the 9480 gives are considered reserved in the 9280 documentation)

On the SGS2 the FSA is not really used for this. Instead the MAX PMIC/MUIC does the job. I couldn't find anything about that chip either.
 

AdamOutler

Retired Senior Recognized Developer
Feb 18, 2011
5,224
9,827
Miami, Fl̨̞̲̟̦̀̈̃͛҃҅͟orida
To bad the FSA documentation avialable is for the 928x, while the phone has a 948x, the former lacking USB OTG support (this can be seen in the kernel sources as the register values the 9480 gives are considered reserved in the 9280 documentation)

On the SGS2 the FSA is not really used for this. Instead the MAX PMIC/MUIC does the job. I couldn't find anything about that chip either.


Looks like the MAX8998 line we're concerned with is VBUS_5V, or V_BAT.

1zywmdz.png
 

sztupy

Inactive Recognized Developer
Dec 21, 2008
1,061
877
Edinburgh
sztupy.hu
Looks like the MAX8998 line we're concerned with is VBUS_5V, or V_BAT.

Oh, haven't seen this file. To bad it still lacks a scematic that shows all the pins of the AP. The OTGDRVVBUS pin is pin number F7. Well, at least it shows it's not yellow, so it might actually be connected somewhere, that's good to see.

And according to it the power from the usb port is avtually routed through the FSA until it gets to the PMIC? I think it's a bit strange though. There is actually nothing power related in the fsa9480.c.
 
  • Like
Reactions: Chainfire

sztupy

Inactive Recognized Developer
Dec 21, 2008
1,061
877
Edinburgh
sztupy.hu
Build2

BUILD 2
  • Upgraded to latest driver from SGS2 sources.
  • Fixed root hub device enumeration issue
  • Driver now clears allocated resources after cable is disconnected

I also added a "nice" painting describing how to connect external devices to the phone.

I'm working on stock gingerbread support now.
 

Epic_VS

Senior Member
Dec 6, 2011
173
42
Is anybody working on porting this to the Nexus S? If so I can test.
Sorry for my impatience.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 144
    USB Host mode driver for Samsung Galaxy S (i9000)

    Also available on the Samsung Captivate and Nexus S
    Vibrant and i9000B builds are avialable in some onecosmic kernels

    Disclaimer: This kernel will enable some very early, and rough usb OTG support for your phone. Currently the phone DOES NOT give out power, so you NEED an external power source to be able to use this kernel. This is true for ALL USB devices, even with those that have their own power source, and doesn't requre external bus powering. Solving this limitation is a TODO, but we cannot guarantee anything. There are some other phones that have usb host support the same way this kernel has (eg. they need external power), like the Nexus One, and there is also a community using this, so if you're saying that usb host support has no sense if you need an external power source then you are definitely mistaken.

    This kernel is built upon teamhacksung's ICS Build 14 kernel, and will only work with that particular ROM (and later b15 and b16 versions of it). There is also a build for stock JVU (Gingerbread). It is possible to port this to older ROMs too (like CM7, or pre-GB ROMs). Ask your favourite kernel developer to do this for you. I only plan to support the CM9 and the stock Gingerbread version.

    The patches are quite device-independent, so they should also work for other similar handsets, like all SGS variants (Captivate, Vibrant, epic, etc.), and also some distant relatives like the Nexus S, or the Galaxy Tab. I do not own these handsets, so you have to ask your favourite kernel developer to port the changesets to the other variants. I have already a build script for Captivate (CM9) and Nexus S (ICS) ports.

    I might also try to create kernels for other devices if the following are true:
    • The kernel source is avialable on github. It is either a kernel for gingerbread (>=2.6.35) or for ICS (>=3.0)
    • It also contains (or has links to) the initramfs and all the other files needed to create an update.
    • If creating the update is not straightforward I also need a script to do this for me
    • After the update is made I need someone with the device to test it for me. If the feedback is positive I'll build versions for that device too, whenever something is changed.

    Credits goes to:
    • The misterious guy at Samsung(?) called chul2 for the original s3c host drivers
    • Kevin Hester (kevinh, probably also nicknamed geeksville, punkgeek and humcycles) for fixing the s3c host driver for the Samsung Galaxy Tab
    • Ever kernel developer at teamhacksung for bringing ICS goodness to Galaxy S

    This is a very early, and very rough usb host support. Expect crashes, freezes and things that are not working! You will also need external power (probably through a Y-cable or a powered usb hub, see the device connection guide below). Also make sure you are only using USB 2.0 (high-speed) devices. The driver does has some quirks with USB 1.x low-speed and full-speed devices, like mice, keyboards, gamepads and similar things. Read the FAQ for more information about them. And of course it doesn't work with USB 3.0 (super-speed) devices.

    Device conection guide:

    attachment.php


    FAQ: see post 2
    ChangeLog: see post 3
    Developer notes: see post 4
    Download links: see post 6

    Usb Host Controller: see it's own topic
    48
    FAQ!

    Terminology
    • USB Host: The ability to connect other USB external devices to your device.
    • USB OTG: The ability of a device to work either as a client or as a host in an USB network.
    • OTG cable: An USB-micro male - USB-A female cable. It also has pins 4 and 5 connected inside the USB-micro male part.
    • USB Y-cable: A special USB cable that has three ends: two USB male-A ends (one data, one power port) and one USB-mini-B male end.
    • LS: USB 1.0 Low-speed (1.5 Mb/s)
    • FS: USB 1.1 Full-speed (12 Mb/s)
    • HS: USB 2.0 High-speed (460 Mb/s)
    • USB Hub: A device that lets you split the USB signal
    • Powered USB Hub: A hub that has an external power supply support
    • Upstream: The direction from the client device to the host device.
    • Control Transfer: One of the five transfer types used by the USB specification. It is responsible for maintainin the state of the USB devices.
    • Bulk Transfer: One of the five transfer types used by the USB specification. This is the most used one, used by drives, cameras and most proprietary usb devices.
    • Interrupt Transfer: One of the five transfer type used by the USB specification. This is mainly used in HID devices, like mice, keyboards and game controllers.
    • Isochronous Transfer: One of the five transfer types used by the USB specification. This is used in streaming devices, like usb audio and usb video devices, dvb receivers, etc.
    • Split Transfer: One of the five transfer types used by the USB specification. It is responsible for converting USB 1.x signals into USB 2.0 signals.

    How to connect the things:

    You will need:
    • The phone
    • An OTG-cable (make sure it's not NOKIA branded, as they have square connectors. You can use some sandpaper to smooth those edges though, so they'll fit inside a normal micro-USB base)
    • Either a powered USB hub (preferably that powers the upstream connection as well)
    • Or a simple USB hub, with a mini-USB connector and a Y-cable, and some USB power source (in this case the upstream powering works out of the box). You will need a decent usb power source though (5V/750mA at least)
    • Make sure the HUB support USB 2.0 and IS indeed an USB 2.0 high-speed hub. USB 1.x Full-speed hubs are very instable Even if it's an USB 2.0 hub it might not work. Either try to find another one, or connect the device directly to the phone (check the connection graphical guide below)
    • And, but not least, some things to connect to the phone.

    Here is a short video of me demonstrating how bad my spoken English is (among other things): http://youtu.be/Yqfk7BOd8J4
    And here is a graphical connection guide:
    attachment.php


    Here is another one (from developersdevelopers), showing how to solder a cable for yourselves:
    attachment.php


    How to install the kernel:

    For CM9/ICS versions: Boot to recovery and use CWM to flash the update. DO NOT TRY to flash this to anything else than teamhacksung's ICS ROM.
    For stock GB versions: Use Odin to flash the new kernel. Make sure you already have a recent GB ROM on your phone.

    How to use:

    By default host mode is turned off, and won't be activated even if you put in an OTG cable. This is for stability reasons. There is an application on Market called "Usb Host Controller" that allows you to enable host functionality. (It can also be downloaded separately) For best results connect the devices in this order:

    • Add power to the USB Hub / connect the power part of the Y cable to a source of power
    • Set Operation Mode in "Usb Host Controller" to OTG
    • Connect the OTG cable to the USB hub or device
    • Connect the OTG cable to the phone

    If everything is fine, you should see the USB hub inside the USB tab in UHC. Next you might try to connect your peripherals one by one to the hub. You should always check whether they are enumerated or not. (by pressing refresh)

    What is working:

    USB 2.0 devices seem to work fine. This includes flash drives, and other accessories like Canon DSLRs. This concludes all USB 2.0 devices I have at home.

    What does not work:

    USB 1.x devices are very quirky (more about this later). USB 1.x devices include almost all HID devices (like keyboard and mice). Some external hubs are failing too. If you cannot connect your hub to the device try with another one, or try connecting the device without an external hub in the middle.

    Also you will need to power the devices externally, as the phone doesn't give out power on the OTG connector.

    USB device enumeration is also broken with mass storage devices: it will not re-enumerate the partitions and devices avialable after they have been connected. Since the 0.2 version of UHC it has a new function: reloading the partition table of a device. You have to do this manually. This might solve most of the "no partition found" problems, and will also lets you connect other Android devices.

    Do I need a hub to get it working?

    No, if you only want to connect one device you can connect it straight to the phone (if you provide it with +5V power). This means you can connect the one end of a Y cable to a power source, the other end to your device and the third end to the phone's OTG cable, and it will work. As it seems there are problems with some external hubs, if you can, then connect to the external device without using a hub in the middle.

    What is "Usb Host Controller"?

    Usb Host Controller is a small app, that let's you enumerate the USB devices that are connected to your phone. It also let's you easily mount and unmount FAT32 based partitions of the flash drives you connect. Besides these globally useful functions it also let's you control how the host mode should be working with.

    Does DSLR Controller work?

    According to chainfire the latest version (0.85) of DSLR Controller will work on CM9-ICS + Galaxy S and this kernel. On JVU even older versions (0.83) should work too.

    Does it work on CM7, stock ROM, other Galaxy S variants, Nexus S, etc?

    It currently works on the folloving devices and ROM versions:
    • Galaxy S i9000
      • CM9 / ICS
      • JVU / Gingerbread
    • Captivate
      • CM9 / ICS
    • Nexus S
      • (official) ICS 4.0.3

    For other S5PV210/S5PC110/Hummingbird based devices this can be probably ported easily. I will do this if you ask me and the following things are present:

    • The kernel source is avialable on github. It is either a kernel for gingerbread (>=2.6.35) or for ICS (>=3.0)
    • It also contains (or has links to) the initramfs and all the other files needed to create an update.
    • If creating the update is not straightforward I also need a script to do this for me
    • After the update is made you will test it for me. If the feedback is positive I'll build versions for that device too, whenever something is changed.

    Is there a chance that this will work without having an external power source?

    Maybe. In theory the S3C controller has the appropriate functionality, but in practice it might not work (for example there might be missing connections inside the PCB, etc.)

    What about USB 1.x devices

    USB 1.x devices work since build 3 (the first JVU build), but only if you connect them to the device without a hub involved (you still need external power). They will still not work if you connect them to an USB 2.0 hub. You might connect more USB 1.x devices together if you happen to have an USB 1.x hub, but it needs patience (I managed to connect a mouse a keyboard and an external hard drive at one through an USB 1.x hub, but I had to try it at least 20 times to get them all properly enumerated. After that they worked though)

    More info about USB 1.x devices: http://xdaforums.com/showpost.php?p=21673976&postcount=101

    Since Build 5, you can also choose to disable the USB 2 functionality of the phone. This will increase stability for USB 1.x devices, but will decrease the transfer speed of USB 2 devices, like external drives. If you want to connect USB 1.x devices through an USB 2.0 HUB, you will need to disable USB 2 mode though.

    How to debug

    The easiest way to debug is the following:

    Turn on "Wireless ADB" on your phone. You can use UHC, or any other app that supports this for that.

    Next connect to your phone wirelessly from your PC, and use the following commands:

    Code:
    > adb connect 192.168.1.100     (enter the actual ip address you get for your phone)
    > adb shell
    $ su
    # echo o > /sys/devices/platform/s3c-usbgadget/opmode
    # cat /proc/kmsg

    The above command includes setting the operation mode of the host controller to "OTG mode", so you don't have to do it on the UHC.

    If everything is fine, you should see results similar to this: http://xdaforums.com/showpost.php?p=21686936&postcount=117

    If devices don't get enumreated properly try switching back to client mode, then to OTG mode again, without disconnecting the devices. You might also try simply reconnecting the devices to the USB cable. Also make sure your power source can give out enough power. For debugging purposes I advice you to use the USB port of a computer / notebook as a power source because they can usually give out 1A of current out of one port. Most external chargers can only give out 500mA-600mA, which might not be enough for multiple devices.

    It still doesn't work

    There are unfortunately a lot of factors that might make the USB Host mode break. These include:

    • Non-conformant USB devices
    • Low quality cables
    • Low quality power soruces (chargers)
    • Solar flares
    • Underground nuclear tests
    • etc.

    Try replacing the cables / devices / power sources and hope it will work next time.
    29
    Downloads

    Downloads

    CWM Kernel Update:

    Odin kernel updates:

    Usb Host Controller:
    All releases can be found here: http://xdaforums.com/showthread.php?t=1468531

    Directory listing of all released files: http://android.sztupy.hu/dl/usbhost/

    Source code of kernel driver:
    If you build a kernel that use the above source, please also link to Usb Host Controller and this topic, because without them the modification is not really usable for an end-user! If you do link both, and also drop me a PM, I will add your kernel to this list.

    External resources:
    28
    ChangeLog

    ChangeLog

    28
    For developers

    For developers

    Getting USB host mode was not really a priority for developers, and it wasn't also very easy. The kernel that Samsung provided had traces of EHCI and OHCI support, but they all seemed to be dead-ends. There was a working Host driver though on some releases, most notably the EA24 release of the Galaxy Tab. (From it we know that it is actually the same driver that is used on odroid2 and probably SGS2 too). This driver was actually not usable, but a fellow developer "Kevin Hester" fixed it, and posted it on his github account. Unfortunately his solution was based on a very old kernel, which used a lot of junk Samsung kernel stuff and deprecated features. Also he based the whole client-host switching code on the proprietary 30 pin connector, which is only used in Galaxy Tab variants. The above things meant that his code was not as easily portable as he probably thought.

    My involvment was mainly to incorporate his fixed S3C Host driver to the latest 3.x kernel branch, fix some of it's internal workings, and put the client-host changer routines somewhere else (it actually landed in the client mode driver called s3c_udc_otg).

    The driver works as following (if you find it inelegant note that the SGS2 does work the same way!):

    The client mode gadget driver is always loaded. It is signalled by the FSA, if it sees that a cable is connected or disconnected. The FSA knows whether the cable is an OTG or a simple client one, and sends this information to the client driver.

    Next the client driver decides whether it needs to change to host mode or not. If it changes, it deregisters his interrupt requests, and loads up the host driver. The client driver stays in memory, but without the interrupt handler routines it will not interfere with the host drivers working.

    The host driver grabs the interrupt handler, and does the enumeration of the devices. It seems the root hub of the driver only does it once, so if anything changes between the phone and the first device (power loss, cable disconnection etc.) the driver won't notice it! (Thiks is why the first device should be a proper external usb hub, as it will re-enumerate devices if they are connected and disconnected. Losing the power supply will hang the host mode still though). EDIT: this is already solved.

    The client driver still listens on cable changes by the FSA. For example if a cable is disconnected and the client driver is not in "host" mode, then it will shut down the host driver (it will unload it from the memory).


    The client driver can be in 4 modes:
    • client: only client mode whatever happens
    • host: always host mode. The client will load the host mode driver the instant the client driver mode changes to host, and will stay so until the mode is changed again to something else
    • otg: client mode when no cable or a client cable is connected. Will switch to host mode if an otg cable is connected.
    • auto-host: client mode when no cable is connected. Will switch to host mode if an otg or a simple client cable is connected.

    The actual mode can be queried from the file:

    Code:
    /sys/devices/platform/s3c-usbgadget/opmode

    The actual mode can be set by echoing 'c','h','o' or 'a' to the previous file. (Or by using Usb Host Controller, which actually does the same internally)

    After connecting external mass storage devices be aware that udev won't create the appropriate nodes inside /dev for them. Usb Host Controller will do this autoamtically, but from the console one needs to do an mknod, befure it can be mounted as a file system.

    Build 5 notices

    From Build 5 there are more host drivers built in: S3C in HS mode (original), S3C in LS/FS (eg. USB 1) mode, and an initial DWC driver. The latter is included as it uses the same specification, and it seems it might get into the upstream kernel branch too sometimes, meaning if it can be loaded it might actually get decent support later on. It also supports isochronous and split transactions, which the original S3C drivers lack.

    The DWC driver does not work currently however, choosing it will usually crash the phone, and force a restart!

    To change the driver you have to write 'l','f' or 'd' into the file:

    Code:
    /sys/devices/platform/s3c-usbgadget/hostdriver

    Apart form that there is also a version file there, containing a few informations about the module.

    There is also support to turn off charging, while the phone is connected to a charger. You can turn charging on/off inside the file disable_charger, which can be found somewhere in the sysfs (it's location might change between devices)