galaxy tab P7510 "ERROR: Failed to initialise protocol!" #26

Closed
hugochinchilla opened this Issue Nov 24, 2011 · 51 comments
@hugochinchilla

Can't perform any action on a Galaxy Tab P7510. I'm using Ubuntu 11.10 64bits

~$ 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: "SEC DEV"
         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...
Setting up interface...

Checking if protocol is initialised...
Protocol is not initialised.
Initialising protocol...
ERROR: Failed to initialise protocol!
@Fiouz

Same here, below is the LIBUSB_DEBUG=3 output:

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...
libusb:debug [libusb_init] 
libusb:debug [find_usbfs_path] found usbfs at /dev/bus/usb
libusb:debug [op_init] found usb devices in sysfs
libusb:debug [usbi_add_pollfd] add fd 3 events 1
libusb:debug [usbi_io_init] using timerfd for timeouts
libusb:debug [usbi_add_pollfd] add fd 5 events 1
libusb:debug [libusb_init] created default context
Detecting device...
libusb:debug [libusb_get_device_list] 
libusb:debug [sysfs_scan_device] scan usb1
libusb:debug [sysfs_scan_device] sysfs descriptors available
libusb:debug [sysfs_scan_device] bus=1 dev=1
libusb:debug [enumerate_device] busnum 1 devaddr 1 session_id 257
libusb:debug [enumerate_device] allocating new device for 1/1 (session 257)
libusb:debug [sysfs_scan_device] scan usb2
libusb:debug [sysfs_scan_device] bus=2 dev=1
libusb:debug [enumerate_device] busnum 2 devaddr 1 session_id 513
libusb:debug [enumerate_device] allocating new device for 2/1 (session 513)
libusb:debug [sysfs_scan_device] scan 1-1
libusb:debug [sysfs_scan_device] bus=1 dev=2
libusb:debug [enumerate_device] busnum 1 devaddr 2 session_id 258
libusb:debug [enumerate_device] allocating new device for 1/2 (session 258)
libusb:debug [sysfs_scan_device] scan 2-1
libusb:debug [sysfs_scan_device] bus=2 dev=2
libusb:debug [enumerate_device] busnum 2 devaddr 2 session_id 514
libusb:debug [enumerate_device] allocating new device for 2/2 (session 514)
libusb:debug [sysfs_scan_device] scan 2-1.5
libusb:debug [sysfs_scan_device] bus=2 dev=3
libusb:debug [enumerate_device] busnum 2 devaddr 3 session_id 515
libusb:debug [enumerate_device] allocating new device for 2/3 (session 515)
libusb:debug [sysfs_scan_device] scan 2-1.6
libusb:debug [sysfs_scan_device] bus=2 dev=4
libusb:debug [enumerate_device] busnum 2 devaddr 4 session_id 516
libusb:debug [enumerate_device] allocating new device for 2/4 (session 516)
libusb:debug [sysfs_scan_device] scan 2-1.7
libusb:debug [sysfs_scan_device] bus=2 dev=5
libusb:debug [enumerate_device] busnum 2 devaddr 5 session_id 517
libusb:debug [enumerate_device] allocating new device for 2/5 (session 517)
libusb:debug [sysfs_scan_device] scan 2-1.6.1
libusb:debug [sysfs_scan_device] bus=2 dev=6
libusb:debug [enumerate_device] busnum 2 devaddr 6 session_id 518
libusb:debug [enumerate_device] allocating new device for 2/6 (session 518)
libusb:debug [sysfs_scan_device] scan 2-1.6.3
libusb:debug [sysfs_scan_device] bus=2 dev=7
libusb:debug [enumerate_device] busnum 2 devaddr 7 session_id 519
libusb:debug [enumerate_device] allocating new device for 2/7 (session 519)
libusb:debug [discovered_devs_append] need to increase capacity
libusb:debug [sysfs_scan_device] scan 1-1.6
libusb:debug [sysfs_scan_device] bus=1 dev=14
libusb:debug [enumerate_device] busnum 1 devaddr 14 session_id 270
libusb:debug [enumerate_device] allocating new device for 1/14 (session 270)
libusb:debug [libusb_get_device_descriptor] 
libusb:debug [libusb_get_device_descriptor] 
libusb:debug [libusb_get_device_descriptor] 
libusb:debug [libusb_get_device_descriptor] 
libusb:debug [libusb_get_device_descriptor] 
libusb:debug [libusb_get_device_descriptor] 
libusb:debug [libusb_get_device_descriptor] 
libusb:debug [libusb_get_device_descriptor] 
libusb:debug [libusb_get_device_descriptor] 
libusb:debug [libusb_get_device_descriptor] 
libusb:debug [libusb_unref_device] destroy device 1.1
libusb:debug [libusb_unref_device] destroy device 2.1
libusb:debug [libusb_unref_device] destroy device 1.2
libusb:debug [libusb_unref_device] destroy device 2.2
libusb:debug [libusb_unref_device] destroy device 2.3
libusb:debug [libusb_unref_device] destroy device 2.4
libusb:debug [libusb_unref_device] destroy device 2.5
libusb:debug [libusb_unref_device] destroy device 2.6
libusb:debug [libusb_unref_device] destroy device 2.7
libusb:debug [libusb_open] open 1.14
libusb:debug [usbi_add_pollfd] add fd 6 events 4
libusb:debug [libusb_get_device_descriptor] 
libusb:debug [libusb_submit_transfer] arm timerfd for timeout in 1000ms (first in line)
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=2 status=0 transferred=4
libusb:debug [handle_control_completion] handling completion status 0
libusb:debug [disarm_timerfd] 
libusb:debug [ctrl_transfer_cb] actual_length=4
libusb:debug [libusb_submit_transfer] arm timerfd for timeout in 1000ms (first in line)
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=2 status=0 transferred=16
libusb:debug [handle_control_completion] handling completion status 0
libusb:debug [disarm_timerfd] 
libusb:debug [ctrl_transfer_cb] actual_length=16
      Manufacturer: "SAMSUNG"
libusb:debug [libusb_submit_transfer] arm timerfd for timeout in 1000ms (first in line)
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=2 status=0 transferred=4
libusb:debug [handle_control_completion] handling completion status 0
libusb:debug [disarm_timerfd] 
libusb:debug [ctrl_transfer_cb] actual_length=4
libusb:debug [libusb_submit_transfer] arm timerfd for timeout in 1000ms (first in line)
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=2 status=0 transferred=16
libusb:debug [handle_control_completion] handling completion status 0
libusb:debug [disarm_timerfd] 
libusb:debug [ctrl_transfer_cb] actual_length=16
           Product: "SEC DEV"
libusb:debug [libusb_submit_transfer] arm timerfd for timeout in 1000ms (first in line)
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=2 status=0 transferred=4
libusb:debug [handle_control_completion] handling completion status 0
libusb:debug [disarm_timerfd] 
libusb:debug [ctrl_transfer_cb] actual_length=4
libusb:debug [libusb_submit_transfer] arm timerfd for timeout in 1000ms (first in line)
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=2 status=0 transferred=4
libusb:debug [handle_control_completion] handling completion status 0
libusb:debug [disarm_timerfd] 
libusb:debug [ctrl_transfer_cb] actual_length=4
         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
libusb:debug [libusb_get_config_descriptor] index 0

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...
libusb:debug [libusb_claim_interface] interface 1
Setting up interface...
libusb:debug [libusb_set_interface_alt_setting] interface 1 altsetting 0

Checking if protocol is initialised...
libusb:debug [submit_bulk_transfer] need 1 urbs for new transfer with length 1024
libusb:debug [libusb_submit_transfer] arm timerfd for timeout in 100ms (first in line)
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=3 status=0 transferred=1024
libusb:debug [handle_bulk_completion] handling completion status 0 of bulk urb 1/1
libusb:debug [handle_bulk_completion] last URB in transfer --> complete!
libusb:debug [disarm_timerfd] 
libusb:debug [bulk_transfer_cb] actual_length=1024
libusb:debug [submit_bulk_transfer] need 1 urbs for new transfer with length 8
libusb:debug [libusb_submit_transfer] arm timerfd for timeout in 100ms (first in line)
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [handle_events] timerfd triggered
libusb:debug [disarm_timerfd] 
libusb:debug [libusb_cancel_transfer] 
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=3 status=-2 transferred=0
libusb:debug [handle_bulk_completion] handling completion status -2 of bulk urb 1/1
libusb:debug [handle_bulk_completion] abnormal reap: urb status -2
libusb:debug [handle_bulk_completion] abnormal reap: last URB handled, reporting
libusb:debug [usbi_handle_transfer_cancellation] detected timeout cancellation
libusb:debug [disarm_timerfd] 
libusb:debug [bulk_transfer_cb] actual_length=0
Protocol is not initialised.
Initialising protocol...
libusb:debug [libusb_submit_transfer] arm timerfd for timeout in 1000ms (first in line)
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=2 status=-32 transferred=0
libusb:debug [handle_control_completion] handling completion status -32
libusb:debug [handle_control_completion] unsupported control request
libusb:debug [disarm_timerfd] 
libusb:debug [ctrl_transfer_cb] actual_length=0
ERROR: Failed to initialise protocol!
libusb:debug [libusb_close] 
libusb:debug [usbi_remove_pollfd] remove fd 6
libusb:debug [libusb_unref_device] destroy device 1.14
libusb:debug [libusb_exit] 
libusb:debug [usbi_remove_pollfd] remove fd 3
libusb:debug [usbi_remove_pollfd] remove fd 5
libusb:debug [libusb_exit] freeing default context

In fact, the issue is similar to #29 (libusb_control_transfer returning LIBUSB_ERROR_PIPE)

@marshray

I am experiencing this issue as well with Heimdall v1.3.1 and the same device.

@marshray

I think the ERROR_PIPE message is a red herring. The USB layer returns this error any time an operation is not supported by the device, which seems typical for configuration messages to the Galaxy Tab 10.1.

The good news is that I have code to make Heimdall work with the Galaxy Tab 10.1. It's some rather extensive changes to BridgeManager.cpp. I need to clean it up quite a bit to make it presentable, but I plan to put it up on a GitHub fork soon.

@rmsc

Hi marshray, any news on this?
I'm also having trouble with the Galaxy W, except that most of the times it fails even before that, at "libusb_set_interface_alt_setting":

libusb:debug [libusb_set_interface_alt_setting] interface 1 altsetting 0
libusb:error [op_set_interface] setintf failed error -1 errno 110
This is ETIMEOUT

libusb:debug [libusb_set_interface_alt_setting] interface 1 altsetting 0
libusb:error [op_set_interface] setintf failed error -1 errno 71
This is EPROTO.

When it does get past through the alt setting step, I do get the EPIPE:
libusb:debug [libusb_submit_transfer] arm timerfd for timeout in 1000ms (first in line)
libusb:debug [libusb_handle_events_timeout_completed] doing our own event handling
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=2 status=-32 transferred=0
libusb:debug [handle_control_completion] handling completion status -32
libusb:debug [handle_control_completion] unsupported control request
libusb:debug [disarm_timerfd]
libusb:debug [ctrl_transfer_cb] actual_length=0
ERROR: Failed to initialise protocol!

@marshray

Thanks for the reminder. I'll put my code up on a fork for testing even though it's not quite presentable.

If I can't get to it this evening, it will be this weekend.

@rmsc

Thanks! I would appreciate that!

@johngalambos

I'm looking forward to seeing your fix too marshray!

@x414e54

Any update on the availability of the fork?

@marshray

Please read the README -- highly experimental.
marshray@bce17dc
Feedback appreciated!

@rmsc

Hi marshray, sorry for the delayed feedback. Unfortunately it doesn't work with my Galaxy W... I guess I'll have to try odin and rev-eng from there.. Thanks anyway!

@marshray

Perhaps Galaxy W has a different PID that just needs to be added to the table at https://github.com/marshray/Heimdall/blob/master/heimdall/source/BridgeManager.h#L91

Let me know if I can help with the RE.

@rockstarmode

Still getting this error with Galaxy tab 10.1 32GB GT-7510 using Heimdall 1.3.2 on OSX Lion 10.7.3

# heimdall print-pit --verbose
Heimdall v1.3.2, 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: "SAMSUNG"
           Product: "SEC DEV"

            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 not initialised.
Initialising protocol...
ERROR: Failed to initialise protocol!
@atippett

ping.. no way to flash the galaxy tab using osx without heimdall

@kLeZ

Ping from me, I cannot flash Galaxy Tab 10.1 P7500, on linux and Mac OS X it is a critical issue.
My debug session is:

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: "SEC DEV"
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...
Setting up interface...

Checking if protocol is initialised...
Protocol is not initialised.
Initialising protocol...
LibUSB result is: -9[3bf5cf18]...
ERROR: Failed to initialise protocol!

Last line (before the error) was put there by me, it is the result code of the lib_control_transfer function in libusb-1.0.
Can you do something for this issue?

@asnowfix

I have the exact same issue, with the same device. I checked with heimdall-1.3.1 & 1.3.2. Same failure, same message. Did you recently reflash your gtab with the experimental Jelly-Bean? This is what has led me to try to use heimdall (/data no longer mounts). If yes, then JLB is possibly the culprit, if not, heimdall is a possible candidate culprit.

@kLeZ

No, it was a broken FOTA update, installing the ICS 4.0.4 update for the italian version of samsung official stock rom.
Yesterday I've pulled down the latest pushed update, stock rom since now, and it resulted in a broken update. Now my tablet loops in the boot procedure for unspoken reasons. So unfortunately it is heimdall to have an issue.

@asnowfix

Did you also try earlier version of heimdall? My boot loop is due to /data being mounted read-only (from the log cat), presumably because of a corrupted FS.

@kLeZ

Yes I tried, I've built the latest heimdall from git sources, 1.3.2, and it is giving the same error as previous.
I had just thought of that issue and I wiped data and cache partitions, now with heimdall I want to restore the FS but since it has this bug I cannot :(

@asnowfix

By earlier I meant "1.3.1" not "latest 1.3.2" as 1.3.2 is saids from the Heimdall home page as having a backward compatibility issue. Take no offence: I am only trying to narrow down this problem, which could also be another instance of the eMMC brick-bug: http://forum.xda-developers.com/showthread.php?t=1879941

@kLeZ

I appreciate your help, thanks! Sorry for my tone, maybe it resulted in an anger one, but it was not :-)
I've tried Heimdall downloading source trees of v1.1.1, v1.3.1, v1.3.2 tags, all of them unfortunately give the same problem, and the control bytes for the libusb transfer request seems to be the same, and seems to be our problem.
I hope someone of the Heimdall team can help us in this bad issue. :-)

@Benjamin-Dobell

I don't think they're likely to be the issue in this particular circumstance, usually the issues mentioned below result in the device not being detected. However, it could be one of the following:

1) Permissions/ownership are set incorrectly for the codeless kext used by Heimdall. Open a terminal and run the following in order to ensure this is not the problem:

sudo chown -R root:wheel /System/Library/Extensions/heimdall.kext/
sudo chmod 755 /System/Library/Extensions/heimdall.kext/
sudo chmod 0644 /System/Library/Extensions/heimdall.kext/Contents/Info.plist

After doing this you will need to reboot your machine.

2) There are other kexts on your system interfering with Heimdall's codeless kext. Typically this would occur if you've tried to install Kies for Mac as Samsung's kernel extensions are given higher priority. If the Samsung's kext does exist it can be removed using the following command:

sudo rm -rf /System/Library/Extensions/ssuddrv.kext/

Again, after running this command you will be required to reboot your machine.

@kLeZ

Hi Benjamin, I'm using linux, openSuSE 12.1 64 bit, and I've compiled from source so no problems of that type can be the cause. I run heimdall with root privileges with sudo and with that privileges I can read the same things as lsusb -v can. Can you manage to figure out what is happening? Maybe Samsung has bricked my device with a wrong update?

@asnowfix

I made the same test on OSX 10.8 & Ubuntu Linux 12.04 / amd64. I used the binary kits in both cases (did not rebuilt anything). Same results for 1.3.1 & 1.3.2. Is there anything I can provide to help narrow-down this issue? (should it be heimdall-related or eMMC-related).

@bigroots

Same test. OSX 10.7.4, Galaxy Tab GT-P7500, Samsung stock Android 3.2 (never hacked nor rooted). File permissions checked as suggested, info.plist permission was 755 --> now corrected and machine rebooted.
Same problem as before.

@kLeZ

Hi Benjamin, have you any news about this issue?
Have you discovered something useful that can solve the problem?

@rvowles

This same issue with a stock Galaxy Tab 10.1 is affecting me on Windows 7.

@Benjamin-Dobell

Could someone with a Galaxy Tab please test the Heimdall 1.4 release candidate?

@rvowles

Where from?

@Benjamin-Dobell

@rvowles: Here... Github. There are no binaries for the release candidate. Are you able to pull from Git and compile yourself? The README has instructions so the only real hurdle is having Xcode, libusb-1.0 and pkg-config installed. The latter two you can grab from Macports, homebrew etc.

@rvowles

I'm on Windows at the moment, Linux in a VM (if that would work?)

@Benjamin-Dobell

Oops, I assumed OS X for some reason.

If you have Visual Studio 2010 installed, you can compile and test on Windows. Heimdall Frontend requires Qt, but for testing purposes all you need to compile is libpit and Heimdall CLI.

If you don't have Visual Studio, then you can certainly try inside a Linux VM. It should work as long as you enable USB pass-through.

@kLeZ

Hi Ben, There is the (bad) result of my try with GT-P7500.

P7500XXLQ8_P7500OXALQ8_ITV> sudo heimdall flash --factoryfs system.img --cache cache.img --modem modem.bin --primary-boot boot.img --secondary-boot bootloader.bin --hidden hidden.img --recovery recovery.img --verbose
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: "SAMSUNG"
           Product: "SEC DEV"

            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...
ERROR: libusb error -7 whilst receiving packet.
Protocol is not initialised.

Initialising protocol...
WARNING: Control transfer #1 failed. Result: -9
WARNING: Control transfer #2 failed. Result: -9
WARNING: Control transfer #3 failed. Result: -9
WARNING: Control transfer #4 failed. Result: -9
WARNING: Control transfer #5 failed. Result: -9
WARNING: Control transfer #6 failed. Result: -9
ERROR: Failed to receive handshake response. Retrying...
Protocol initialisation successful.

Beginning session...
Session begun with device of type: 3.

Downloading device's PIT file...
PIT file download successful.

ERROR: Partition name for "cache" could not be located
Ending session...
Rebooting device...
Releasing device interface...
Re-attaching kernel driver...
@Benjamin-Dobell

@kLez: Don't stress just yet. That just means that Heimdall couldn't identify a hard-coded partition that matches the "--cache" argument. You can still flash partitions using partition ID, or even better, by using the new --<partition name> arguments. You can retrieve partition names by running "heimdall print-pit".

However, I should probably verify that this is actually a result of an unknown named cache partition, rather than a bug that's causing Heimdall not to find the "CACHE" partition. As such, could you please upload the output from print-pit.

Thanks

@kLeZ

Here is the pit table.

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...
Claiming interface...
Attempt failed. Detaching driver...
Claiming interface again...
Setting up interface...

Checking if protocol is initialised...
Protocol is not initialised.

Initialising protocol...
Protocol initialisation successful.

Beginning session...
Session begun.

Downloading device's PIT file...
PIT file download successful.

Entry Count: 17
Unknown 1: 0
Unknown 2: 0
Unknown 3: 0
Unknown 4: 0
Unknown 5: 0
Unknown 6: 0
Unknown 7: 0
Unknown 8: 0


--- Entry #0 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 0
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size: 512
Partition Block Count: 0
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SMD
Flash Filename: emmc.img
FOTA Filename: 


--- Entry #1 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 2
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size: 512
Partition Block Count: 6
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BCT
Flash Filename: bct.bin
FOTA Filename: 


--- Entry #2 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 3
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size: 512
Partition Block Count: 1
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: PT
Flash Filename: 
FOTA Filename: 


--- Entry #3 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 4
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size: 512
Partition Block Count: 4
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: EBT
Flash Filename: bootloader.bin
FOTA Filename: 


--- Entry #4 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 5
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size: 512
Partition Block Count: 4
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: EB2
Flash Filename: 
FOTA Filename: 


--- Entry #5 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 6
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size: 512
Partition Block Count: 8
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: GP1
Flash Filename: fusetrigger.bin
FOTA Filename: 


--- Entry #6 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 7
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size: 512
Partition Block Count: 24
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: EFS
Flash Filename: efs.img
FOTA Filename: 


--- Entry #7 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 8
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size: 512
Partition Block Count: 10
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SOS
Flash Filename: recovery.img
FOTA Filename: 


--- Entry #8 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 9
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size: 512
Partition Block Count: 16
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: LNX
Flash Filename: boot.img
FOTA Filename: 


--- Entry #9 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 10
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size: 512
Partition Block Count: 1156
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: APP
Flash Filename: system.img
FOTA Filename: 


--- Entry #10 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 11
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size: 512
Partition Block Count: 896
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: CAC
Flash Filename: cache.img
FOTA Filename: 


--- Entry #11 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 12
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size: 512
Partition Block Count: 4
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: MSC
Flash Filename: 
FOTA Filename: 


--- Entry #12 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 13
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size: 512
Partition Block Count: 24
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: MDM
Flash Filename: modem.bin
FOTA Filename: 


--- Entry #13 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 14
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size: 512
Partition Block Count: 27285
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: UDA
Flash Filename: data.img
FOTA Filename: 


--- Entry #14 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 15
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size: 512
Partition Block Count: 16
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: OTA
Flash Filename: 
FOTA Filename: 


--- Entry #15 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 16
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size: 512
Partition Block Count: 600
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: HID
Flash Filename: hidden.img
FOTA Filename: 


--- Entry #16 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 17
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size: 512
Partition Block Count: 2
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: GPT
Flash Filename: 
FOTA Filename: 

Ending session...
Rebooting device...
Releasing device interface...
Re-attaching kernel driver...

Thanks for your support, if you know something I could do to help just ask I will be pleased to do so.

@Benjamin-Dobell

@kLeZ Ah, Here you go, try the following:

heimdall flash --APP system.img --CAC cache.img --MDM modem.bin --LNX boot.img --EBT bootloader.bin --HID hidden.img --SOS recovery.img --verbose

As you can probably see I've just mapped the filenames you mentioned to the corresponding partition names printed by print-pit. Perfect example of the new --<partition name> flashing :)

@kLeZ

Thanks Ben! Tablet up and running! It worked flawlessly!
Only a question: don't you think that it could be a more tricky to use heimdall from cmd with this options system?
Why you've done this choice?

@Benjamin-Dobell

The reason I've done this is because partition names are not consistent between devices, in fact they're totally arbitrary even when using different PIT files on the same device. There's really nothing stopping ROM developers (or Samsung) from creating new PIT files and naming partitions however they please.

This might be a bit long-winded, but I'll try explain why this is a problem...

Heimdall needs to know partition names in order to determine which files should be flashed to which partition on the device. In fact Heimdall actually needs uses the partition IDs. But the partition ID can be grabbed by looking up a partition name in a PIT file. The partition ID is what is sent to the phone when flashing.

When I first started developing Heimdall it only supported one device, the GT-I9000. As such I hard-coded the partition names to match arguments. Here's the official mapping as supported by Heimdall 1.4 RC1:

argumentPartitionNamesMap["pit"].push_back("PIT");
argumentPartitionNamesMap["factoryfs"].push_back("FACTORYFS");
argumentPartitionNamesMap["cache"].push_back("CACHE");
argumentPartitionNamesMap["dbdata"].push_back("DBDATAFS");

argumentPartitionNamesMap["primary-boot"].push_back("IBL+PBL");
argumentPartitionNamesMap["primary-boot"].push_back("BOOT");

argumentPartitionNamesMap["secondary-boot"].push_back("SBL");
argumentPartitionNamesMap["secondary-boot"].push_back("SBL1");

argumentPartitionNamesMap["secondary-boot-backup"].push_back("SBL2");
argumentPartitionNamesMap["param"].push_back("PARAM");
argumentPartitionNamesMap["kernel"].push_back("KERNEL");
argumentPartitionNamesMap["recovery"].push_back("RECOVERY");
argumentPartitionNamesMap["efs"].push_back("EFS");
argumentPartitionNamesMap["modem"].push_back("MODEM");
argumentPartitionNamesMap["radio"].push_back("RADIO");
argumentPartitionNamesMap["normal-boot"].push_back("NORMALBOOT");
argumentPartitionNamesMap["system"].push_back("SYSTEM");
argumentPartitionNamesMap["user-data"].push_back("USERDATA");
argumentPartitionNamesMap["fota"].push_back("FOTA");
argumentPartitionNamesMap["hidden"].push_back("HIDDEN");
argumentPartitionNamesMap["movinand"].push_back("MOVINAND");
argumentPartitionNamesMap["data"].push_back("DATAFS");
argumentPartitionNamesMap["ums"].push_back("UMS.EN");
argumentPartitionNamesMap["emmc"].push_back("GANG");

As you can see that list is already a bit ridiculous, and some parameters like --primary-boot can correspond with multiple partition names eg. "IBL+PBL" or "BOOT".

Potentially I could keep updating this list every time someone encounters a new partition name. But between the time someone encounters the new partition and the time it takes me to update Heimdall, users would be stuck, and totally unable to flash.

However, I already solved this problem with the introduction of partition ID based flashing (in Heimdall 1.3?) through numbered arguments. This allows Heimdall to flash partitions that aren't in the list of known hard-coded partition names (shown above). Theoretically this allows Heimdall to flash any device that uses PIT files.

This is actually how the Heimdall Firmware Package format works, through use of partition IDs. Although I'm considering migrating it to use partition names instead.

The new partition name arguments are just an extension of this system, instead of using the partition ID, you specify the exact partition name and Heimdall looks it up in the PIT file for you.

In fact as of v1.3, Heimdall Frontend was already using partition names. If you load up your devices PIT file in Heimdall Frontend you see the complete list of partitions on the device using their actual partition names (much like print pit).

Basically what I'm saying is that the --kernel, --secondary-boot etc. way of flashing has reached its limits and is no longer useful. This is particularly true when you look at the Qualcomm phones in US. Unfortunately they don't match the --primary-boot, --secondary-boot model at all. If I recall correctly, there are 6 different files that are required to perform roughly the same task as just boot.bin and Sbl.bin on Exynos devices. They also have two different modem partitions one called MODEM, and one called MDM. Rather than trying to define and maintain separate arguments for all these different partitions its much easier just to allow users to flash using partition names directly.

HOWEVER, I am considering adding the following command:

heimdall autoflash [--pit <filename>] --files <filename[, filename, ...]>

For example, your flash would have looked like:

heimdall autoflash --files system.img cache.img modem.bin boot.img bootloader.bin hidden.img recovery.img

What autoflash would do, is what I just did for you manually. Which is map filenames to particular partitions.

However, this autoflash method would give up one of the most significant advantages of Heimdall, which is that you can name your files however you please. For autoflash to work, you'd have to name your files precisely how they appear in the PIT file, but this is how Odin works anyway so it's not too big of an issue. The other downside is of course that autoflash would be limited to flashing partitions that actually have a filename. If you look at the output of your print-pit command you'll see some partitions don't have filenames. Odin is not capable of flashing these partitions, but Heimdall is.

@Benjamin-Dobell

The simple named arguments (--kernel, --primary-boot etc.) should probably be treated as deprecated behaviour. I'll add some better output before I release 1.4.0 (final) and probably include the above rant in the the README ;)

When I implement autoflash I'll officially drop support for these simple named parameters. However, as autoflash should actually be much simpler to use it shouldn't be a problem.

@kLeZ

Wow, great explaination! thanks for this post Ben, it will be useful for a better understanding of your project!

@getochkn getochkn referenced this issue Oct 17, 2012
Closed

T959W Support #66

@navrev

I have gone through some of your recent posts and upgraded to 1.4 RC but I still get this problem
I am trying on a Samsung S2 GT-I9100
I am using fedora 17.

[root@Ganakayantra naveen]# heimdall flash --BOOT Desktop/android\ tools/mynewimage.img --no-reboot
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...
Claiming interface...
Setting up interface...

Checking if protocol is initialised...
Protocol is not initialised.

Initialising protocol...
ERROR: Protocol initialisation failed!

Releasing device interface...

@jantheofel

Hello,

I get the "ERROR: Protocol initialisation failed!" in every situation. Even when I try to "print PIT" in the grahicl frontend. I'm using Max OS X 10.7.4 and heimdall 1.3.2. Can anyone plese help me? Thanks!

Jan

@mcandre

Bump.

@reubenscratton

This bug is preventing Heimdall working with the Galaxy Tab 10.1 P7500.

@kLeZ

Hi Ben, this is a regression bug, please review the code.

@sterichards

Hi,

I've read all the above posts and I'm still getting the original problem of "Failed to initialise protocol" using Ubuntu and a 7510.

I tried "heimdall flash --APP system.img --CAC cache.img --MDM modem.bin --LNX boot.img --EBT bootloader.bin --HID hidden.img --SOS recovery.img --verbose" but got "ERROR: "-APP" is not a valid argument" returned.

Not sure where to go from here except to try this on a Windows box.

@smunaut

I tried 1.3.1 1.3.2 and 1.4.1RC2 and those 3 version fail with "Failed to initialise protocol" when trying to print-pit.

On P7510 tablet

@Benjamin-Dobell

Could someone please provide a USB capture:
http://www.youtube.com/watch?v=qFIg5fu0PTg

@smunaut

Sorry, I don't have any access to a physical windows machine ...

But in the end I managed to make it work:

  • I first used the fork https://github.com/marshray/Heimdall to try and dumped the PIT.
  • That actually didn't really work and it even segfaulted
  • BUT after having used that fork once, the tablet was now in a state where the mainstream Heimdall from git worked and I was able to flash.

Also something confusing is that the tablet seem to have two different 'mode' depending on how long you press on the volume down button. One says "upload mode" and the other says "ODIN3 download mode". The first one is actually recognized by Heimdall as valid, but fails all the time. The second one also fails at first, but if you use the trick above to first use the fork and then flash with the mainstream heimdall, it works.

@Benjamin-Dobell

I'm closing this issue because as far as I can tell the original problem was resolved. For those of you who had similar problems please try the latest 1.4.0 release (https://github.com/Benjamin-Dobell/Heimdall/tree/v1.4.0).

If it doesn't work please check if there is an issue that already exists for your device. If one exists and is closed, please re-open it and add as much information as you can. If no issue exists for your device, please create a new one with all the details you can muster!

@eMPee584

HOWEVER, I am considering adding the following command:
heimdall autoflash [--pit <filename>] --files <filename[, filename, ...]>

You haven't by chance started hacking away at this yet..? #automagic

@Benjamin-Dobell

@eMPee584 I have a branch lying around where I started implementing this. It's actually pretty straight-forward to implement. I might have a crack at it this weekend.

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