T-Mobile Samsung Galaxy S II (SGH-T989) support #29

Closed
s--d opened this Issue Nov 29, 2011 · 19 comments

Projects

None yet
@s--d
s--d commented Nov 29, 2011

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.

@s--d
s--d commented Nov 29, 2011

Being a moron n00b, I of course was not in download mode. The above protocol error still stands (and is identical to the DoCoMo problem in issue #28):

#:~/$ ./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: "Sasmsung"
           Product: "MSM8x60"
         Serial No: "?"

            length: 18
      device class: 2
               S/N: 0
           VID:PID: 04E8:685D
         bcdDevice: 0100
   iMan:iProd:iSer: 1:2:0
          nb confs: 1

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

interface[1].altsetting[0]: num endpoints = 2
   Class.SubClass.Protocol: 0A.00.00
       endpoint[0].address: 81
           max packet size: 0200
          polling interval: 00
       endpoint[1].address: 01
           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...
@sjuxax
sjuxax commented Jan 22, 2012

Same here, same device. Using Arch Linux with kernel 3.2. I wonder if it involves recent kernels or recent libusb. Has anyone tried with an older distro?

@s--d
s--d commented Mar 5, 2012

Nope, the ODIN protocol handshake (I think) is different for these devices. I'm (poorly and lazily...) trying to convince someone else to submit a USB log of ODIN writing to a device. I even got a volunteer, but I need to show them how to acquire the log (I've only done USB wire capture on Linux and with a hardware analyzer, never from windows). We should probably use whatever Benjamin's favorite method is.

@ambrice
ambrice commented Mar 6, 2012

Recent Wireshark will do USB captures on linux. You have to run it as root. I was able to do a USB capture of ODIN by running wireshark on linux and running ODIN in a virtualbox Windows VM. See the results here: http://forum.xda-developers.com/showpost.php?p=22877504&postcount=9 which were for a different device..

@marshray
marshray commented Mar 7, 2012

You might try my experimental fork at https://github.com/marshray/Heimdall for the GT-P7510 (Galaxy Tab 10.1).

@dmag
dmag commented Jun 10, 2012

@marshray: I got your fork to work (and downloaded the pit from a SGH-T989). I had to change "Unexpected device info response!\nExpected: 180, 0 or 3" to allow 30.

@marshray

@dmag That's great. Perhaps we should just downgrade that error to a warning.

@rykerwilliams

@marshray I used your fork and made the change @dmag suggested. I was then able to flash recovery using that build.

@chuntr
chuntr commented Sep 13, 2012

I also used the modifications courtesy of @marshray and @dmag and got Heimdall able to flash my SGH-T989. Thanks!

@RichardBronosky

What's with the lack of links to forks of this project? I'm always surprised by the way the XDA community will talk about changes rather than submitting patches or linking to commits. It's so different from the FOSS communities I work in professionally.

@jethrogb

With modifications from @marshray @dmag, print-pit works on SGH-T699 (Galaxy S Relay 4G), I haven't dared flashing yet.

@chuntr
chuntr commented Sep 28, 2012

Here is the diff I used to @marshray 's fork:

diff --git a/heimdall/source/BridgeManager.cpp b/heimdall/source/BridgeManager.cpp
index 1faa626..a3ac6c8 100644
--- a/heimdall/source/BridgeManager.cpp
+++ b/heimdall/source/BridgeManager.cpp
@@ -1622,9 +1622,9 @@ bool BridgeManager::BeginSession(void)
        int deviceType = setupSessionResponse.GetUnknown();

        // TODO: Work out what this value is... it has been either 180 or 0 for Galaxy S phones, 3 on the Galaxy Tab, 190 for SHW-M110S.
-       if (deviceType != 180 && deviceType != 0 && deviceType != 3 && deviceType != 190)
+       if (deviceType != 180 && deviceType != 0 && deviceType != 3 && deviceType != 190 && deviceType != 30)
        {
-               Interface::PrintError("Unexpected device info response!\nExpected: 180, 0 or 3\nReceived:%d\n", deviceType);
+               Interface::PrintError("Unexpected device info response!\nExpected: 180, 0, 3, or 30\nReceived:%d\n", deviceType);
                return (false);
        }
        else
@Benjamin-Dobell
Owner

Please try the Heimdall 1.4 release candidate to ensure this is fixed. If not, you can let me know if the problem still persists by re-opening the issue.

@getochkn getochkn referenced this issue Oct 17, 2012
Closed

T959W Support #66

@s--d
s--d commented Dec 10, 2012

The initial issue ("ERROR: Failed to initialise protocol! 105:-9") is absolutely fixed in 1.4 RC1. However, the patch posted above is a patch on a patch, and is not enough to make Heimdall function correctly on the SGH-T989.

Marsh Ray's fork (mentioned in #29 (comment)) encompasses a LOT of changes, one commit which facilitates support for similar devices, and one which do not (notably, he rewrites a very large portion of Heimdall to change the naming convention of dozens of functions for no reason). The two commits in the fork are marshray@bb3e0a5 ...and... marshray@bce17dc

Those, plus chuntr's patch (in #29 (comment)) permit me to successfully print/download the PIT file (I've not tried anything else).

The first patch is a Grand Renaming, and the second patch is a detailed, frame-by-frame, reverse engineering of ODIN traffic from a capture session on the model of Galaxy Tab 10.1 to which he was porting Heimdall (GT-P7510), though a casual look through his repo didn't reveal the pcap file.

So, a fair bit of work would be needed to make the patch merge cleanly back into mainline Heimdall, but I believe it can be done.

UPDATE: Above I mention that Heimdall is not fully functional, but neglected to mention in what way it fails. Here's the current output:

Heimdall v1.4 RC1
Copyright (c) 2010-2012, 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: "Sasmsung"
           Product: "MSM8x60"
            length: 18
      device class: 2
               S/N: 0
           VID:PID: 04E8:685D
         bcdDevice: 0100
   iMan:iProd:iSer: 1:2:0
          nb confs: 1
interface[0].altsetting[0]: num endpoints = 1
   Class.SubClass.Protocol: 02.02.01
       endpoint[0].address: 82
           max packet size: 0010
          polling interval: 09
interface[1].altsetting[0]: num endpoints = 2
   Class.SubClass.Protocol: 0A.00.00
       endpoint[0].address: 81
           max packet size: 0200
          polling interval: 00
       endpoint[1].address: 01
           max packet size: 0200
          polling interval: 00
Claiming interface...
Setting up interface...
Checking if protocol is initialised...
Protocol is initialised.
Beginning session...
Session begun with device of type: 30.
In certain situations this device may take up to 2 minutes to respond.
Please be patient!
ERROR: libusb error -7 whilst receiving packet. Retrying...
ERROR: libusb error -7 whilst receiving packet. Retrying...
ERROR: libusb error -7 whilst receiving packet. Retrying...
ERROR: libusb error -7 whilst receiving packet. Retrying...
ERROR: libusb error -7 whilst receiving packet.
Releasing device interface...
@s--d
s--d commented Jan 9, 2013

Updating to confirm that Marshray's fork, with chuntr's patch, permits me to flash CWMR on my T989's (where 1.4 RC1 does not).

@jwmh
jwmh commented Feb 3, 2013

@s--d You mentioned that you also needed @chuntr's patch (in addition to @Marshray's fork).
However, according to the comments by @jamiejackson here:

... That shouldn't be necessary? Admittedly, chuntr's patch isn't mentioned, but it sounds as though Marshray's fork should work for the SGH-T989 as is.
(I haven't tried it yet, as I'm a bit hesitant to risk bricking my only device.)

Can others confirm or deny this? IS chuntr's patch redundant?

@s--d
s--d commented Feb 3, 2013

Yeah, deviceType 30 is in @Marshray's fork now (actually for months). I had pulled his fork a while back and not updated (so I didn't see the patch pushed in). Oops! So, you should be good to go (of course, YMMV).

Here is where it happened: marshray@e2dba6c

@Benjamin-Dobell
Owner

I have no intention of merging in Marshray's fork due to the excessive amount of unnecessary changes.

Could someone please provide me with a Kies/Odin packet capture:
http://www.youtube.com/watch?v=qFIg5fu0PTg

That way I'll be able to work out what changes are necessary and cleanly implement support (assuming the latest Git commit hasn't already fixed the issue).

Please continue the discussion over here #62

@s--d
s--d commented Feb 3, 2013

Yeah, that bit left me puzzled as well. Though, I could mechanically undo that and give you a clean patch to play with. It would be tedious, but I'm not sure it's worth it (it looks a bit hard-codey for my liking). Anyway, can't be arsed to do anything with Windows (how would I even locate an ISO and key without $$$ or popups, block lists, and all that BS I left behind years ago). That said, I'm grateful that the effort was made to build something I could use to make my T989's useful.

The best I could provide would be a pcap of a session with my Marshray Heimdall binary flashing recovery on one of my T989's (which seems a bit perverse). I'm sure you'd prefer an actual Odin capture, just to be safe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment