FORUMS
Remove All Ads from XDA

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

1,061 posts
Thanks Meter: 878
 
Post Reply Email Thread
20th January 2012, 07:14 PM |#81  
sztupy's Avatar
OP Inactive Recognized Developer
Flag London
Thanks Meter: 878
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

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)
 
 
20th January 2012, 07:19 PM |#82  
sztupy's Avatar
OP Inactive Recognized Developer
Flag London
Thanks Meter: 878
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

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
20th January 2012, 08:15 PM |#83  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,671
 
Donate to Me
More
Quote:
Originally Posted by sztupy

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)

Quote:
Originally Posted by sztupy

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

Quote:
Originally Posted by sztupy

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?)
20th January 2012, 08:42 PM |#84  
sztupy's Avatar
OP Inactive Recognized Developer
Flag London
Thanks Meter: 878
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

(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.

Quote:
Originally Posted by Chainfire

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.

Quote:

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
20th January 2012, 09:02 PM |#85  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,671
 
Donate to Me
More
Quote:

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.

Quote:

...y cable...

Would this work ?

20th January 2012, 09:10 PM |#86  
sztupy's Avatar
OP Inactive Recognized Developer
Flag London
Thanks Meter: 878
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

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.

Quote:
Originally Posted by Chainfire

Would this work ?

Yep.
20th January 2012, 09:47 PM |#87  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,671
 
Donate to Me
More
Quote:
Originally Posted by sztupy

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...

Quote:

Yep.

Great! I wasn't sure if that was really the type of cable I needed.
The Following User Says Thank You to Chainfire For This Useful Post: [ View ]
21st January 2012, 12:24 PM |#88  
nsa666's Avatar
Senior Member
Thanks Meter: 14
 
More
@Chainfire Can you post here when the new version of dslr-controller is out? Just waiting for working version to buy it.
21st January 2012, 05:00 PM |#89  
Quote:
Originally Posted by sztupy

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.co...6&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://forum.xda-developers.com/show....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://forum.xda-developers.com/show....php?t=1235219 and http://forum.xda-developers.com/show....php?t=1206216 I don't have the internal points for i9000

Here's the code I run on my Arduino: http://forum.xda-developers.com/show...&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...
The Following User Says Thank You to AdamOutler For This Useful Post: [ View ]
21st January 2012, 05:20 PM |#90  
sztupy's Avatar
OP Inactive Recognized Developer
Flag London
Thanks Meter: 878
 
Donate to Me
More
Quote:
Originally Posted by AdamOutler

There's no real link where you can learn about the SBL> prompt, officially. I did set up something here: http://forum.xda-developers.com/show....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://forum.xda-developers.com/show....php?t=1235219 and http://forum.xda-developers.com/show....php?t=1206216 I don't have the internal points for i9000

Here's the code I run on my Arduino: http://forum.xda-developers.com/show...&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
21st January 2012, 06:03 PM |#91  
sztupy's Avatar
OP Inactive Recognized Developer
Flag London
Thanks Meter: 878
 
Donate to Me
More
Quote:
Originally Posted by sztupy

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
The Following 2 Users Say Thank You to sztupy For This Useful Post: [ View ] Gift sztupy Ad-Free
Post Reply Subscribe to Thread

Tags
host, ics, kernel, usb

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes