Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues With Newer Samsung Bootloaders And Heimdall #209

Closed
utkanos opened this issue Jun 11, 2014 · 122 comments
Closed

Issues With Newer Samsung Bootloaders And Heimdall #209

utkanos opened this issue Jun 11, 2014 · 122 comments

Comments

@utkanos
Copy link

utkanos commented Jun 11, 2014

Hi Ben,

Since Samsung has pushed some changes in their 4.4 OTAs for a few devices (hlte, i9506) heimdall, even 1.4.1 is unable to communicate with the device and retrieve a PIT or handshake properly at all.

Attached are some logs of the hlte with '4.4' Samsung Bootloader update

heimdall 1.4.0:

heimdall print-pit --verbose --no-reboot
Heimdall v1.4.0

Copyright (c) 2010-2014 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: "MSM8960"

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

Initialising protocol...
Protocol initialisation successful.

Beginning session...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...

Some devices may take up to 2 minutes to respond.
Please be patient!

WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
Session begun.

Downloading device's PIT file...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer.
ERROR: Failed to send request to end PIT file transfer!
ERROR: Failed to download PIT file!
Ending session...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer.
ERROR: Failed to send end session packet!
Releasing device interface...
Re-attaching kernel driver...

and with heimdall 1.4.1:

heimdall print-pit --verbose
Heimdall v1.4.1

Copyright (c) 2010-2014 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: "MSM8960"

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

Initialising protocol...
ERROR: Failed to receive handshake response. Result: -7
ERROR: Protocol initialisation failed!

Releasing device interface...

Thanks for looking into this when you can!
utkanos

edit: here is another device on 1.4.1 with this issue and slightly diff behavior:

heimdall print-pit --verbose
Heimdall v1.4.1

Copyright (c) 2010-2014 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: "MSM8960"

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

Initialising protocol...
Protocol initialisation successful.

Beginning session...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...

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

@bachy
Copy link

bachy commented Jun 22, 2014

got the exact same error. heimdall un-usable for me (linux)
i found it so sade to have to switch to windows to free my android (GS4 gt-i9506)
it would be so appreciated if you could fixe this issue

@Benjamin-Dobell
Copy link
Owner

@bachy

Is there any chance you’d be able to do the following for me on Windows?

  1. Install Simple USB Logger -http://www.incentivespro.com/downloads.html#usb-logger
  2. Boot the Samsung device into download mode. If this requires hooking up the USB, then disconnect the USB cable once you're in download mode.
  3. Use Odin/Kies to prepare a full system (or near enough to) flash.
  4. Launch Simple USB Logger and click the "Create New Monitoring Session" button (looks like a new document button).
  5. Plug in the Samsung device.
  6. When the flash is complete stop logging and save the USB capture to disk.
  7. Send me the capture file.

This would help immensely in fixing support for these devices.

@kennysgithub
Copy link

On Sun, 22 Jun 2014, Benjamin Dobell wrote:

Is there any chance you’d be able to do the following for me on Windows?
[ How to log the USB traffic on Windows ]
This would help immensely in fixing support for these devices.

I have a Galaxy Note 10.1 2014 Edition (specifically, the SM-P607T) and I
also have this same issue (had to use Windows in VMware, which was a pain)
so I'll try and get a dump to you this week as well.

-Kenny

Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Silicon Valley

@utkanos
Copy link
Author

utkanos commented Jun 26, 2014

Ben,

I was able to get the log you were after thanks to a kind user who ran the steps you asked for. Hopefully this helps. Sent to your email.

@bachy
Copy link

bachy commented Jun 29, 2014

@Benjamin-Dobell
glad someone did it,
because i am real newbe in flashing custom roms on android, never did it, yet ...
thanks for your work!

@Benjamin-Dobell
Copy link
Owner

@utkanos Thanks for the capture.

Looking at the capture, I noticed that for some reason the device sends an empty bulk transfer to the computer right before the computer sends the packet to end the PIT transfer. So I've made a change to emulate this behaviour. However, it seems you were only getting that far with 1.4.0 and that 1.4.1 was failing earlier. Looking at this capture I see no reason why this particular device would fail before the end of the PIT transfer. It might be different for other devices though.

Anyway, I've pushed a new commit to the master branch which includes the new behaviour that should fix the PIT transfer issue. If you could please retry with that commit and let me know how you go that would be great.

@utkanos
Copy link
Author

utkanos commented Jul 5, 2014

@Benjamin-Dobell, thanks, I will test this and get back to you. A user named sytse made similar conclusions with the bulk transfer and PIT end session behavior and modified the source and was able to resolve the issue as well. I will play with both fixes and let you know what happens. Thanks very much for getting back with me on this!

@slayher
Copy link

slayher commented Jul 9, 2014

I just tested the latest commits, and I am still seeing issues.
https://www.dropbox.com/s/7aheexlkkwby0ej/heimdall-7-9-14.txt

@utkanos
Copy link
Author

utkanos commented Jul 9, 2014

@Benjamin-Dobell slayher tested it and another user and they had the exact same experience. I am emailing you a diff file from the user that solved the issue for themself in the hopes that you can work with that to patch master. He's just removing some checks from happening and forcing a pit file instead of trying to read it from the device which does work but might not be the most elegant solution. I will send the file to your email, thanks for continuing to work on this.

@Erikmu
Copy link

Erikmu commented Jul 11, 2014

Hello all, i have the same problem with galaxy s3 L710 sprint
on the other hand i've also have a problem with Galaxy s5 G900v wich i'm not able to "print pit"
@Benjamin-Dobell i'have a couple of samsung phones, if you need i can send to you some info

@utkanos
Copy link
Author

utkanos commented Aug 16, 2014

@Benjamin-Dobell any update on this issue? Thanks.

@sanchom
Copy link

sanchom commented Aug 30, 2014

@Benjamin-Dobell Any updates?

@kalvdans
Copy link

kalvdans commented Sep 4, 2014

The patch from sshimko fixes recovery flashing for me on Galaxy S4 GT-I9506. I'm not able to boot into the recovery yet, but the heimdall flashing proceeds without any error.

@Astragalus
Copy link

Hi - just randomly chiming in :) I tried the patch from sshimko and am still unable to download the pit file; I am getting "ERROR: Failed to receive handshake response. Result: -7" which is the same error I got before the change. My device is a (T-Mobile) Samsung Galaxy S5 SM-P900T. Alas!

@sshimko
Copy link

sshimko commented Sep 11, 2014

There seem to be multiple types of failures here. The patch fixes the issue wherein the session is successfully established, the PIT download has been initiated, then it fails.

On OSX, it fails much earlier for me on both Mavericks and Yosemite, but seemingly in different ways.

I believe they are distinct problems with different sources.

@Astragalus which OS was this on?

@Astragalus
Copy link

This was on Linux Mint 17, amd64, and I should add that the libusb I used was built from the git source. Please let me know if there's anything I can grab for you, I'm happy to help.

@antanst
Copy link

antanst commented Sep 20, 2014

I have problem flashing a Galaxy Tab Pro 8.4" as well. Version 1.4.0 exist with "libusb error -7" message, both on Mac OS X and on Ubuntu. Tried different computers with different USB cables.

I've just compiled this day's Heimdall build. Still unable to flash. Verbose output follows:

Heimdall v1.4.1

Copyright (c) 2010-2014 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: "MSM8960"

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

Initialising protocol...
Protocol initialisation successful.

Beginning session...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...

Some devices may take up to 2 minutes to respond.
Please be patient!

ERROR: libusb error -7 whilst receiving bulk transfer.ERROR: libusb error -7 whilst receiving bulk transfer. Retrying...
 Retrying...
ERROR: libusb error -7 whilst receiving bulk transfer.ERROR: libusb error -7 whilst receiving bulk transfer. Retrying...
 Retrying...
ERROR: libusb error -7 whilst receiving bulk transfer.ERROR: libusb error -7 whilst receiving bulk transfer. Retrying...
 Retrying...
ERROR: libusb error -7 whilst receiving bulk transfer.ERROR: libusb error -7 whilst receiving bulk transfer. Retrying...
 Retrying...
ERROR: libusb error -7 whilst receiving bulk transfer.ERROR: libusb error -7 whilst receiving bulk transfer. Retrying...
 Retrying...
ERROR: libusb error -7 whilst receiving bulk transfer.ERROR: libusb error -7 whilst receiving bulk transfer.

Releasing device interface...

@yorrd
Copy link

yorrd commented Oct 16, 2014

Same here, please investigate! My log is identical to many others here, won't spam now.

@tgalal
Copy link

tgalal commented Oct 16, 2014

Try #232

@yorrd
Copy link

yorrd commented Oct 16, 2014

@tgalal I have changed the files as described to

if (ReceiveBulkTransfer(nullptr, 1, kDefaultTimeoutEmptyTransfer, false) < 0 && verbose)

and

success = ReceivePacket(receiveFilePartPacket, kDefaultTimeoutReceive, receiveEmptyTransferFlags);

and recompiled heimdall. The error is still the same though.

@AbiJobs
Copy link

AbiJobs commented Oct 20, 2014

@tgalal

sudo heimdall print-pit --verbose --stdout-errors --no-reboot

WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
ERROR: libusb error -7 whilst sending bulk transfer.ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
 Retrying...
ERROR: libusb error -7 whilst sending bulk transfer.ERROR: libusb error -7 whilst sending bulk transfer.

ERROR: Failed to send request to end PIT file transfer!

@ndorf
Copy link

ndorf commented Oct 20, 2014

Same here with Galaxy Tab Pro 8.4" (SM-T320) :(

My output is identical to that posted by @AbiJobs and @antanst, above.

This is a major bummer for me, so if there's anything I can do to help get this fixed please let me know.

@ndorf
Copy link

ndorf commented Oct 20, 2014

Odin 3.07 worked from inside a VirtualBox VM running Win7 Ultimate x86, on the same Ubuntu 14.04 x64 host where Heimdall had failed. (It successfully flashed TWRP, which I used to install CM11).

@fat-tire
Copy link

Same issue on ubuntu.

To even get to the ERROR: Failed to receive handshake response. Result: -7 I first had to first get past a:

Claiming interface...
ERROR: Claiming interface failed!

Error. Fixed that by changing heimdall/source/BridgeManager.cpp, line ~230

-       int result = libusb_claim_interface(deviceHandle, interfaceIndex);
+       int result = libusb_detach_kernel_driver(deviceHandle, interfaceIndex);
+       result = libusb_claim_interface(deviceHandle, interfaceIndex);

But still had the issue.

@Techwolf
Copy link

Any update on this? I have a Galaxy Tab Pro 8.4" (SM-T320).

@ddevault
Copy link

Having this same problem with a Galaxy S5 Sprint, Arch Linux user here. Going to try passing my phone off to a VM.

@ddevault
Copy link

Identical problem when passing my phone off to a VM. I suppose I'll just live with the default OS.

@basharam
Copy link

On SAMSUNG Galaxy S5 G900F

$sudo ./heimdall print-pit --verbose

Heimdall v1.4.1

Copyright (c) 2010-2014 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: "MSM8960"

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

Initialising protocol...
ERROR: Failed to receive handshake response. Result: -7
ERROR: Protocol initialisation failed!

Releasing device interface...

@crabilld
Copy link

@moismailzai Your method worked for me on a G900T. I did it from Windows, so of course I had to remove sudo ./ from the commands. I also had to change the last command to this:

heimdall flash --RECOVERY myrecovery.img --pit mypit.pit --no-reboot

It wouldn't recognize the term "recovery" unless it was capitalized, and I needed to add --no-reboot to the end to prevent the system from rebooting, which would cause the stock firmware to overwrite the new recovery.

@kn00tcn
Copy link

kn00tcn commented Dec 31, 2015

@crabilld maybe since mine is refurbished, samsung may have put a newer recovery on it? i just cant get the pit file on windows

ERROR: Failed to send request to end PIT file transfer!
ERROR: Failed to download PIT file!
Ending session...
ERROR: Failed to send end session packet!

............
edit/update: well after a horrible mess & a few mistakes, i'm eventually good... used odin to flash instead

@hackslikeus
Copy link

not sure of the resolution here....why was this closed ?
I can flash most files,(Recovery, boots and mbn's) but the larger ones , (above 2gb) - .img.ext4 extensions fail immediately.
ubuntu heimdall vesion 1.4.1:
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
I can paste the verboseness, but is there a size limit on what can be sent?
Samsung Galaxy S4 Verison SCH-I545,

@sen4ik
Copy link

sen4ik commented Feb 22, 2016

I was facing this issue on T-Mobile Galaxy Note 3.
Compiled latest from sources for windows and it worked perfect!
In case you want to download the one i compiled, here is the link https://s3.amazonaws.com/sen4ik/files/heimdall.exe
It was compiled couple days ago.

@pwlin
Copy link

pwlin commented Feb 27, 2016

@sen4ik thank you very much for the windows binary.

@calebunleashed
Copy link

This happened for me on v1.4.1. There's a few ways to fix it:

  1. Ensure you have the latest & greatest version of Heimdall
  2. Install all this:
    sudo apt-get install build-essential cmake zlib1g-dev qt5-default libusb-1.0-0-dev libgl1-mesa-glx libgl1-mesa-dev
  3. Reboot your computer
  4. Try connecting on a different USB port - 3 of my USB ports didn't work, and one did!

@javsav
Copy link

javsav commented Mar 12, 2016

@sen4ik Thanks so much for compiling and uploading that dude, saved me a lot of trouble!

@ericzolf
Copy link

Hi,

got it working under Fedora 23 (not sure all the packages installed are necessary, but it works):

as root:

dnf install cmake zlib-devel libusb-devel
dnf builddep heimdall
dnf install gcc gcc-c++ kf5-kconfigwidgets-devel
dnf remove heimdall    # make sure you install heimdall's build dependencies but not heimdall

then follow the instructions at the end of Linux/README, as normal user, and calling heimdall (as root) works for a Samsung Galaxy TabPro 8.4, where it didn't work previously with the packaged heimdall 1.4.1-5.fc23

Hope this helps someone, Eric

@vectorsigma
Copy link

@ericzolf : I had to do something very similar. I ended up building a new RPM/SRPM of what I cloned as of 20160603. That seemed to have fixed all the things. I had the same problem here as a lot of folks, but 1.4.1 (what Fedora ships) is just way old. The latest commits from master solved the problems I had. HTH!

@sjs205
Copy link

sjs205 commented Jul 7, 2016

For what it is worth, I had this issue when my device was plugged into a USB3 port. Moving it to a USB2 port fixed it.

@CapnSpellcheck
Copy link

I experienced this issue on OS X with JOdin3/Heimdall 1.4.0. My phone is Galaxy Alpha SM-G850M. Can anyone offer a guess as to a fork of the code I could try?

@Benjamin-Dobell I installed your 1.4.1 unofficial dmg (hopefully it works as an upgrade; after the install, command line 'heimdall version' still gave 1.4.0) but it did not seem to resolve anything.

@ezpc98
Copy link

ezpc98 commented Sep 22, 2016

Thanks to @sen4ik for the windows binary. It worked great and did not face "ERROR: Failed to send request to end PIT file transfer!"error. Device -Samsung Galaxy Tab Pro 8.4.

@alpha-beta-soup
Copy link

Had the same issue using Heimdall with Ubuntu 14.04 x64, with a Galaxy S5. The SaburoJiro fork worked fine.

@ghost
Copy link

ghost commented Nov 29, 2016

FYI I just had success using the commandline (not frontend) compiled from source 1.4.1 on Samsung Galaxy S5 G900F #348 (comment)
Thanks to everyone for contributing to make this work 👍

@clach04
Copy link

clach04 commented Dec 3, 2016

Having same problem with version 1.4.0 binaries downloaded from main web site with Samsung S5.

#209 (comment) binary built by sen4ik worked! 👍

@wolftune
Copy link

On Ubuntu 16.04 (KDE Neon really) #209 (comment) comment above did it for me (I was also using that other forked build, dunno if that mattered or not)

@u2n
Copy link

u2n commented Mar 28, 2017

Repo version (Ub.16.04 /64) gave this error; built version did not.

Used CLI to flash SGN3, N900T, which seemed to work for all partitions, but could not overcome the secure boot error (a separate issue). Have read that Odin writes data to the MD5 partition with a private key. Would be great if that could be cracked. Much prefer using Heimdall.

@futurama140
Copy link

I hope I'm not spamming you with what may still be an existing issue , but I figured my specific variables may be useful info:
-Dell latitude e6420
-USB 2.0 port (no 3.0 on my ancient laptop)
-Heimdall 1.4.0 via terminal on:
-Debian 8 (Jessie)
-Samsung SM-G360T1 (Galaxy Core Prime with MetroPCS)
-Tried to flash Stock ROM and had the error about not finding the PIT file, same as is posted in the early comments (I'm not going to read this whole page of comments at one time)

I Flashed the stock ROM from Odin on Windows, and thought maybe it was the bricked phone causing the Heimdall issue, so just now I tried to flash the phone back on Debian with the Unofficial TWRP build for this phone and received the error again.

From one Ben to another,
L'Chaim!

@ghost
Copy link

ghost commented Oct 20, 2017

i can confirm following is true in my case:

For what it is worth, I had this issue when my device was plugged into a USB3 port. Moving it to a USB2 port fixed it.

If you don't have a USB 2.0 port, you can try connecting via a USB 2.0 hub, as in my case

@cprima
Copy link

cprima commented Nov 7, 2017

The USB2.0 and re-insert the USB cable did the trick for me, too. (This is November 2017, and I am on klte.)

@unsigned-nerd
Copy link

Device: Samsung Galaxy Note 3 (hlte)

Last night, I tried to flash a custom recovery using heimdall from apt repository of Subgraph OS, a Debian-based distro, without success. So, I followed the suggestions from this thread by uninstalling heimdall from apt and install the latest version from github instead and it just worked. The git commit id is 5377b62 . Thank you very much.

@arrkaye
Copy link

arrkaye commented Dec 25, 2017

Had the same issue with Samsung T700. Compiled my own Heimdall (1.4.2) and it worked.

@ericzolf
Copy link

I'm not sure if the original purpose of this issue is still current: I've recently used heimdall 1.4.2 packaged in Fedora 27 and successfully flashed TWRP on a Galaxy S7 with Android 7, so it sounds to me like the issue is solved and should be closed.

@anothernerd02
Copy link

anothernerd02 commented Dec 31, 2017 via email

@philfry
Copy link

philfry commented Jan 19, 2018

unfortunately, it's still broken.
Fedora 27
Lenovo Carbon X1
USB 2.0 port
Samsung S4 VE (i9515)

@jedisct1
Copy link

jedisct1 commented Jan 20, 2018

No joy here either, with a Galaxy Tab S2.

@borg1622
Copy link

borg1622 commented Feb 5, 2018

I ran into the same issues with heimdall 1.4.0 running on linux which is still provided on the heimdall download page.
To solve the problem you could try to:

  • compile heimdall from sources (github)
    or
  • install heimdall from your linux distro package manager. there is a good chance that you get a newer heimdall version from there.

I've tried the latter and it worked for me because my distro provides version 1.4.1.

@thany
Copy link

thany commented May 15, 2018

I've ran into this a good while back, when I wanted to reflash my Galaxy S7.
Now I wanted to reflash my new shiny Galaxy S9, and this issue still exists. What gives?

Running Heimdall 1.4.2 (compiled version here) works absolutely fine.

Please, Mr Heimdall author sir, could you please get on with releasing an official new version?

@russnes
Copy link

russnes commented May 19, 2018

Worked after compiling 1.4.2 from source, and running the cli, aka NOT frontend. Had to try two different usb cables

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests