search

Benjamin-Dobell / Heimdall

Heimdall is a cross-platform open-source tool suite used to flash firmware (aka ROMs) onto Samsung Galaxy devices.
MIT License
2.62k stars 587 forks source link

print-pit fails on Samsung Galaxy W (samsung-i8150): ERROR Protocol initialisation failed #489

Open onny opened 3 years ago

onny commented 3 years ago

Hey, trying to use heimdall for an older Samsung device (samsung-i8150) somehow fails:

heimdall print-pit
Heimdall v1.4.2

Copyright (c) 2010-2017 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...

Initialising protocol...
ERROR: Protocol initialisation failed!

Releasing device interface...

I'll look if I could find some workarounds :)

Best regards Jonas

Grimler91 commented 3 years ago

Are you running heimdall as root? (see https://github.com/Benjamin-Dobell/Heimdall/issues/403)

Stupid question but have to ask: have you tried reseting/restarting the phone? I know that an error like this happens if you try to run several heimdall commands in a row without reseting the phone in between

onny commented 3 years ago

Hey thank you for the tipps. I tried with root and also as normal user. Restarting/resetting the phone several times did not help :(

Grimler91 commented 3 years ago

Try capturing debug logs: heimdall print-pit --usb-log-level debug, and the libusb traffic with for example wireshark, and (if you have the possibility) the libusb traffic when flashing stock android with odin. Heimdall just mimics odin, so we need libusb traffic logs from odin to see how Heimdall is suppose to work with this device

onny commented 3 years ago

Try capturing debug logs: heimdall print-pit --usb-log-level debug, and the libusb traffic with for example wireshark, and (if you have the possibility) the libusb traffic when flashing stock android with odin. Heimdall just mimics odin, so we need libusb traffic logs from odin to see how Heimdall is suppose to work with this device

Cool I'll try this! Unfortunately I didn't have luck with Odin on Windows 10 nor Windows 7. Installing the Samsung USB drivers is quite unstable and Odin is unable to establish an connection :/

Grimler91 commented 3 years ago

I didn't have luck with Odin on Windows 10 nor Windows 7

When flashing stock android? In "proper" windows or a virtual box? (I have never gotten it to work in a virtual box)

If it does not work with odin on windows either, then maybe your usb cable is bad?

onny commented 3 years ago

@Grimler91 I used your Heimdall fork and run it debugging option:

$ heimdall print-pit --usb-log-level debug
Heimdall v1.4.2

Copyright (c) 2010-2017 Benjamin Dobell, Glass Echidna
https://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:
https://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
[timestamp] [threadID] facility level [function call] <message>
--------------------------------------------------------------------------------
[ 6.788668] [00006436] libusb: debug [libusb_get_device_list]  
[ 6.788690] [00006436] libusb: debug [discovered_devs_append] need to increase capacity
[ 6.788697] [00006436] libusb: debug [libusb_get_device_descriptor]  
[ 6.788703] [00006436] libusb: debug [libusb_get_device_descriptor]  
[ 6.788708] [00006436] libusb: debug [libusb_get_device_descriptor]  
[ 6.788714] [00006436] libusb: debug [libusb_get_device_descriptor]  
[ 6.788718] [00006436] libusb: debug [libusb_get_device_descriptor]  
[ 6.788725] [00006436] libusb: debug [libusb_open] open 1.100
[ 6.788752] [00006436] libusb: debug [usbi_add_event_source] add fd 7 events 4
[ 6.788758] [00006436] libusb: debug [libusb_get_device_descriptor]  
[ 6.788762] [00006436] libusb: debug [libusb_get_config_descriptor] index 0
Claiming interface...
[ 6.788775] [00006436] libusb: debug [libusb_claim_interface] interface 1
Setting up interface...
[ 6.788803] [00006436] libusb: debug [libusb_set_interface_alt_setting] interface 1 altsetting 0

Initialising protocol...
[ 6.791324] [00006436] libusb: debug [libusb_reset_device]  
[ 6.943760] [00006436] libusb: debug [libusb_alloc_transfer] transfer 0x1d43b18
[ 6.943783] [00006436] libusb: debug [libusb_submit_transfer] transfer 0x1d43b18
[ 6.943789] [00006436] libusb: debug [add_to_flying_list] arm timer for timeout in 1000ms (first in line)
[ 6.943806] [00006436] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 4
[ 6.943829] [00006436] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 6.943852] [00006436] libusb: debug [handle_events] event sources modified, reallocating event data
[ 6.943873] [00006436] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms
[ 6.943974] [00006436] libusb: debug [usbi_wait_for_events] poll() returned 1
[ 6.943992] [00006436] libusb: debug [reap_for_handle] urb type=3 status=0 transferred=4
[ 6.944007] [00006436] libusb: debug [handle_bulk_completion] handling completion status 0 of bulk urb 1/1
[ 6.944011] [00006436] libusb: debug [handle_bulk_completion] all URBs in transfer reaped --> complete!
[ 6.944018] [00006436] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer
[ 6.944035] [00006436] libusb: debug [usbi_handle_transfer_completion] transfer 0x1d43b18 has callback 0x7ff5bb601e20
[ 6.944047] [00006436] libusb: debug [sync_transfer_cb] actual_length=4
[ 6.944064] [00006436] libusb: debug [libusb_free_transfer] transfer 0x1d43b18
[ 6.944081] [00006436] libusb: debug [libusb_alloc_transfer] transfer 0x1d26c98
[ 6.944091] [00006436] libusb: debug [libusb_submit_transfer] transfer 0x1d26c98
[ 6.944102] [00006436] libusb: debug [add_to_flying_list] arm timer for timeout in 1000ms (first in line)
[ 6.944134] [00006436] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 7
[ 6.944167] [00006436] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 6.944174] [00006436] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms
[ 7.944124] [00006436] libusb: debug [usbi_wait_for_events] poll() returned 1
[ 7.944158] [00006436] libusb: debug [libusb_cancel_transfer] transfer 0x1d26c98
[ 7.947251] [00006436] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer
[ 7.947265] [00006436] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 7.947279] [00006436] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms
[ 7.947286] [00006436] libusb: debug [usbi_wait_for_events] poll() returned 1
[ 7.947295] [00006436] libusb: debug [reap_for_handle] urb type=3 status=-2 transferred=0
[ 7.947303] [00006436] libusb: debug [handle_bulk_completion] handling completion status -2 of bulk urb 1/1
[ 7.947309] [00006436] libusb: debug [handle_bulk_completion] abnormal reap: urb status -2
[ 7.947314] [00006436] libusb: debug [handle_bulk_completion] abnormal reap: last URB handled, reporting
[ 7.947321] [00006436] libusb: debug [usbi_handle_transfer_cancellation] detected timeout cancellation
[ 7.947329] [00006436] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer
[ 7.947335] [00006436] libusb: debug [usbi_handle_transfer_completion] transfer 0x1d26c98 has callback 0x7ff5bb601e20
[ 7.947343] [00006436] libusb: debug [sync_transfer_cb] actual_length=0
[ 7.947350] [00006436] libusb: debug [libusb_free_transfer] transfer 0x1d26c98
ERROR: Protocol initialisation failed!

Releasing device interface...
[ 7.947389] [00006436] libusb: debug [libusb_release_interface] interface 1

[ 7.947428] [00006436] libusb: debug [libusb_close]  
[ 7.947437] [00006436] libusb: debug [usbi_remove_event_source] remove fd 7
[ 7.947451] [00006436] libusb: debug [libusb_exit]  
[ 7.947458] [00006436] libusb: debug [libusb_exit] destroying default context
[ 7.947464] [00006436] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 7.947470] [00006436] libusb: debug [handle_events] event sources modified, reallocating event data
[ 7.947479] [00006436] libusb: debug [usbi_wait_for_events] poll() 2 fds with timeout in 0ms
[ 7.947486] [00006436] libusb: debug [usbi_wait_for_events] poll() returned 0
[ 7.947492] [00006436] libusb: debug [libusb_unref_device] destroy device 2.3
[ 7.947498] [00006436] libusb: debug [libusb_unref_device] destroy device 2.2
[ 7.947505] [00006436] libusb: debug [libusb_unref_device] destroy device 2.1
[ 7.947511] [00006436] libusb: debug [libusb_unref_device] destroy device 1.7
[ 7.947518] [00006436] libusb: debug [libusb_unref_device] destroy device 1.100
[ 7.947524] [00006436] libusb: debug [libusb_unref_device] destroy device 1.2
[ 7.947530] [00006436] libusb: debug [libusb_unref_device] destroy device 1.1
[ 7.947536] [00006436] libusb: debug [libusb_unref_device] destroy device 4.1
[ 7.947543] [00006436] libusb: debug [libusb_unref_device] destroy device 3.1
[ 7.947549] [00006436] libusb: debug [usbi_remove_event_source] remove fd 6
[ 7.947562] [00006436] libusb: debug [usbi_remove_event_source] remove fd 5
[ 7.947585] [0000643a] libusb: debug [linux_udev_event_thread_main] udev event thread exiting

I captured this session with usbmon and tshark: https://onny.project-insanity.org/files/heimdall_linux.cap

Will try to do the same on the Windows 7 VM :) Maybe I also should prepare Windows 7 on a physical machine ...

onny commented 3 years ago

DRAFT:

Using the latest heimdall 1.4.2 of your fork:

heimdall flash --RECOVERY recovery.img

Here's the capture file.

Using Odin Multi Downloader 4.43 on Windows 7 (KVM):

signal-2021-08-18-200134_002 signal-2021-08-18-200134_001

Here's the capture file.

Files:

I really would like to look into the capture files but I haven't worked with them nor Heimdall yet so it might be a bit more complicated.

Grimler91 commented 3 years ago

Seems something went wrong when you pasted the capture file link, could you send it again?

Grimler91 commented 3 years ago

Your heimdall capture shows that the phone does not even respond to the first message sent, so will be interesting to see how different the "Odin Multi Downloader 4.43" protocol is

onny commented 3 years ago

Hey thanks for the feedback. I have some issues capturing traffic on Windows but will try again tomorrow :)

Grimler91 commented 3 years ago

Going through some of the old issues it seems some galaxy phones, like the Galaxy Y (and so perhaps the Galaxy W) use a different flashing protocol, see https://github.com/Benjamin-Dobell/Heimdall/issues/335#issuecomment-196208128.

Still interesting to see the differences in how it is flashed if you can capture the usb traffic, but adding support for it is probably quite a lot of work

onny commented 3 years ago

I finally was able to capture the Win 7 usb traffic ;) Here's the Odin Multi Downlaoder flashing session capture: https://onny.project-insanity.org/files/samsungw/odin_flash_recovery.cap

Grimler91 commented 3 years ago

Thanks! Some quick observations: the bootloader seem to be based on qcom's little kernel, and it claims that it is a MSM7230 device (not MSM8255T). I guess samsung did not bother s/7230/8225/..