Benjamin-Dobell/Heimdall — Issue #29: T-Mobile Samsung Galaxy S II (SGH-T989) support
Author: jaggers
Created: 2011-11-29 22:41:41+00:00
State: open

Heimdall is having trouble communicating with the T-Mo GSII variant, the SGH-T989. It has a different USB product ID (685E instead of the common 685D). I've corrected that hurdle on my own box, but it is not the only problem.

Here is the output from a PIT print:

#:~$ ./heimdall print-pit --verbose
Heimdall v1.3.1, Copyright (c) 2010-2011, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
Manufacturer: "SAMSUNG"
Product: "SAMSUNG_Android"
Serial No: "fece4578"

length: 18
device class: 239
S/N: 3
VID:PID: 04E8:685E
bcdDevice: 0400
iMan:iProd:iSer: 1:2:3
nb confs: 1

interface[0].altsetting[0]: num endpoints = 2
Class.SubClass.Protocol: 08.06.50
endpoint[0].address: 81
max packet size: 0200
polling interval: 00
endpoint[1].address: 01
max packet size: 0200
polling interval: 01

interface[1].altsetting[0]: num endpoints = 1
Class.SubClass.Protocol: 02.02.01
endpoint[0].address: 85
max packet size: 000A
polling interval: 09

interface[2].altsetting[0]: num endpoints = 2
Class.SubClass.Protocol: 0A.00.00
endpoint[0].address: 84
max packet size: 0200
polling interval: 00
endpoint[1].address: 03
max packet size: 0200
polling interval: 00

interface[3].altsetting[0]: num endpoints = 2
Class.SubClass.Protocol: FF.42.01
endpoint[0].address: 86
max packet size: 0200
polling interval: 00
endpoint[1].address: 04
max packet size: 0200
polling interval: 00
Claiming interface...
Attempt failed. Detaching driver...
Claiming interface again...
Setting up interface...

Checking if protocol is initialised...
Protocol is not initialised.
Initialising protocol...
ERROR: Failed to initialise protocol! 105:-9
Re-attaching kernel driver...

Notice the "failed to initialise..." line. I've added "\_\_LINE\_\_, result" to that error print. The "-9" is the value returned by the call on line 101 (100 in the mainline without my USB product ID line added near the top) of BridgeManager.cpp;

int result = libusb_control_transfer(deviceHandle, LIBUSB_REQUEST_TYPE_CLASS, 0x22, 0x3, 0, nullptr, 0, 1000);

It's LIBUSB_ERROR_PIPE (-9) returned by libusb_control_transfer(). From the libusb docs, "LIBUSB_ERROR_PIPE if the control request was not supported by the device". Further, in the above we see:

device class: 239
S/N: 3
VID:PID: 04E8:685E

The device class (239, or "Miscellaneous") is a big difference; it appears that device class 2 (comms device) is expected. Perhaps that is responsible for the pipe error. In fact, "lsusb -v" says:

Bus 002 Device 012: ID 04e8:685e Samsung Electronics Co., Ltd
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x04e8 Samsung Electronics Co., Ltd
idProduct 0x685e
bcdDevice 4.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1

This suggests that the phone is presenting as a class 239/subclass 2/protocol 1 device, which according to http://www.usb.org/developers/defined_class/#BaseClassEFh means that it is an "Interface Association" descriptor; a way to multiplex multiple device classes on one "function". Later on we see:

Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 1
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 2 Abstract (modem)
bFunctionProtocol 1 AT-commands (v.25ter)
iFunction 7
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 5
CDC Header:
bcdCDC 1.10
CDC Call Management:
bmCapabilities 0x00
bDataInterface 2
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Union:
bMasterInterface 1
bSlaveInterface 2
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x000a 1x 10 bytes
bInterval 9
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 6
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 66
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0

Two things appear to be of interest here; specifically, "bInterfaceClass 2" and "bFunctionClass 2", which are possibly what Heimdall is used to interacting with. ??? Rampant speculation, there. If so, then what we need for the T989 is probably to switch the comms, based on the product ID, and retrieve a handle to the class 2 interface, and issue the Loke protocol to that instead.

My USB-foo is weak, and I'd appreciate it if either another programmer with a T989 and USB experience could poke at this, or, a Windows-savvy developer with a T989 could snoop on ODIN and just scoop the protocol initialization bytes.