InitialiseProtocol: reset device before handshake #478
Conversation
Heimdall fails to handshake with device on my Linux installation: Initialising protocol... 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 handshake! ERROR: Failed to receive handshake response. Result: -7 ERROR: Protocol initialisation failed! However, with the same USB cable, port and device, Heimdall successfully handshake with the device on Windows via WinUSB. This indicates handling of USB devices of host (AMD X570) on Linux might lead to undesired results. Though, without further testing, the interference from userspace (Ubuntu 20.04, KDE) can not be ruled out. Thus, this patch calls libusb_reset_device to ensure the USB port is in a clean state before we send the data. Fixes issues with newer devices and hosts. Signed-off-by: Jesse Chan <[email protected]>
|
@Benjamin-Dobell ping |
|
@luk1337 - I still get this error, even after applying this patch :( |
|
nevermind, i did something silly. used the wrong arguments to heimdall. The following worked: |
|
@luk1337 do you get the error when flashing a single partition, or only when flashing multiple partitions? The other PR that fixes issues with newer devices also adds a libusb_reset_device() call, but in |
I pulled the patch you linked but it doesn't work for my device ^^ |
|
Thanks for checking! I guess reset needs to go in both places then |
|
I had the same issue on device SM-A300FU, and I confirm that this patch fix the issue. |
|
I can confirm that this pull request fixes a connection problem for device SM-T720 ( +1 to merging |
|
I can second that this pull request fixes a connection problem for device SM-T720. So few lines in the commit but it fixes it. Some links to help you use the unmerged pull request in your clone of the repo : https://stackoverflow.com/questions/14947789/github-clone-from-pull-request This certainly fixed the immediate error message and handshake problem, but I've still not managed yet to get TWRP onto this tablet from linux, bunch of other problems beyond what this pull request fixes. |
|
@Benjamin-Dobell seams to be inactive here. Very sad. |
|
No updates since 2017. |
|
This apparently causes issues on some devices, on degaswifi (SM-T230) it prevents successful handshake. Maybe only devices using odin protocol v3 and newer needs this. @mparker17 and @aktivkohle reported that issue happens on SM-T720 though, and that device seem to use the same protocol version as degaswifi (v0). So, don't know how to properly deal with this. Maybe heimdall need to detect which distro it is running on and only do libusb_reset() on ubuntu (that would be very annoying). Protocol version that the device is compatible with can (it seems) be seen in the pit header, with heimdall 1.4.2 it is Unknown 7, so for example: or with Heimdall 2.0.0 from my repo |
|
@Grimler91, |
|
@Grimler91, thanks for continuing the work on Heimdall. Is there an issue tracker? Using your repo, I have the same problem as described in this discussion. Any idea what might cause this? |
|
@davux sorry, missed your message here. What device is this for? I have set up a mailing list for the sourcehut repo here: https://lists.sr.ht/~grimler/Heimdall-devel, so discussion/bug reports can be sent to ~grimler/[email protected] |
|
@Grimler91 https://forum.xda-developers.com/t/official-samsung-odin-v4-1-2-1-dc05e3ea-for-linux.4453423/, imo Heimdall lost it's purpose. |
|
@TheAirBlow there's plenty of reasons why one could prefer a tool like heimdall over odin on Linux, including:
|
Well, the first one can be simply ignorer as Odin for Windows is around for a lot of time now and Samsung didn't take any legal action. I do agree with others though, but if you just want to flash on an everyday use computer you can do it. |
|
@Grimler91 also, it you have a testing device for Thor I may resume development, not promising but it can happen |
Your docs are already very helpful, I have plenty of things to catch up with and try to implement in heimdall from there :) The newest device I have access to at the moment is a galaxy tab s6 lite. Do you have a good test to see if it supports the updated Thor protocol/software? (Reported protocol from the device is 0x03, so not one of the most recent versions) |
I have checked Thor's (not to be confused with mine, this is Samsung's) source code, and it doesn't use the Thor handshake and just does everything Heimdall can in the exact same way (packets are the same) The only thing it can do other than flashing with regular Odin protocol is the one that is for very old phones, I don't remember how it's called exactly. |
You mean it supports both odin mode and the older "Multi Downloader" type of flash, for Galaxy W/Y/whatever devices? |
|
I've got the same problem as described in the original message and in #517 on Manjaro (Arch) with my S21+ (SM-G996B/DS). I tried building Heimdall with the branch from this PR, which resulted in You can find the outputs of Photo of phone in Odin mode If there's anything I can try out or do to help, I'd be happy to! Also, huge thank you to everyone who did work on Heimdall so far. |
|
@felurx did you run the same command, with Commands after using
|
|
@Grimler91 Ah, thanks, I somehow managed to completely miss that! (I think I didn't even read --help, just skimmed the README, sorry about that...) Just like last time, I ran Here's the full output (of just the second command with |
|
@felurx so seems something is wrong with --no-reboot/--resume for your device. What are you trying to achieve? If print-pit works then flashing probably works as well, as long as --no-reboot/--resume is not used. You can also try the updated heimdall sources here: https://git.sr.ht/~grimler/Heimdall, it has some of the various PRs in this repo merged and might work better. To actually fix the --no-reboot/--resume issue we would need to sniff usb traffic from odin when it successfully does (the equivalent of) --no-reboot/--resume with this device, and compare what heimdall does differently |
i am trying to flash a Samsung Galaxy S5e wifi here and it's also failing with that source code, compiled fresh out of today's git: am i doing something wrong? also, how do people create the famous .pit files? I can't seem to find those online, and guides such as LineageOS or /e/ all assume you run windows and the Odin crap... |
|
Seems like you may have sent a second command in the same session. Either reboot the phone after each heimdall command or use the |
|
well at this point i did manage to flash ... something, but i also somehow managed to do it the wrong way and totally hosed the tablet. it's now showing this funky screen on boot:
i tried a lot of things from here, loading a new vbmeta from lineage, from TWRP, same with recovery, nothing seems to work. communication with the tablet is flaky over Heimdall, it frequently fails halfway with errors similar to those described here. |
|
@anarcat you forgot to unlock bootloader...? |
i did not, OEM lock is OFF, the thing is just hosed. |
|
i think my main problem here is it's not very clear how one is supposed to use heimdall in the first place. in the frontend, there's talk about having Heimdall packages, but on the commandline you pass arbitrary files as --RECOVERY and so on... i've tried my way around this but it feels like a minefield and, well, i think stepped on a mine. my last hope is that locking the bootloader is somehow going to do a factory reset that's going to reset the normal recovery and firmware so that i get something working, but it would sure be nice to have some documented way of flashing tablets (my case is the Samsung Galaxy Tab S5e aka gts4lvwifi aka SM-T720... otherwise i'm back to square one, minus all my data, apps and configuration. and that's the good scenario where the device is usable at all... it looks like @Grimler91 is the new upstream, is there a forum somewhere where users can get (self?) support on this stuff? i suspect the LOS people will not be happy to see people trying to explicitly not follow their documentation (ie. not using windows...) but surely us linux folks could hang out somewhere better than an append-only log that pretends to be a pull request? :) |
|
On a OEM-unlocked SMT500, I ran Advice greatly appreciated! Thank you!! |
|
Confirming same issue on Galaxy Tab S5e (gts4lv) on Manjaro (Arch), Heimdall 1.4.2-7. |
|
This fix worked for me for Galaxy A31, nixos |
|
@Benjamin-Dobell - Any reason this isn't merged in if it fixes the issue? |
For whatever it's worth, I tried this yesterday on a Ubuntu 22.04 laptop and for this exact model, and it did not work for me. My laptop, however, only has usb-c ports, no usb-a, I'm not sure whether that is a factor, but thought I'd share for visibility. |
Heimdall fails to handshake with device on my Linux installation:
Initialising protocol...
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 handshake!
ERROR: Failed to receive handshake response. Result: -7
ERROR: Protocol initialisation failed!
However, with the same USB cable, port and device, Heimdall
successfully handshake with the device on Windows via WinUSB.
This indicates handling of USB devices of host (AMD X570) on
Linux might lead to undesired results. Though, without further
testing, the interference from userspace (Ubuntu 20.04, KDE) can
not be ruled out.
Thus, this patch calls libusb_reset_device to ensure
the USB port is in a clean state before we send the data.
Fixes issues with newer devices and hosts.
Signed-off-by: Jesse Chan [email protected]