Hikey960 recovery - hikey_idt hangs trying to write xloader

I’ve searched for and followed pretty much every recovery instructions online and can’t find anybody else who’s had the following issue.

Host computer is Debian 10 (both WSL under Windows 10 as well as native). Removed “modemmanager” package as per some recovery instructions.

Hikey960 v1, jumpers 1 and 2 are bridged, 3 is open (ie, pins 1-2, 3-4, 5x6)
Console shows nothing (as expected).

Trying to recover with hikey_idt, it always hangs indefinitely (several hours) at the following step:

—>>>
bootloader$ sudo ./hikey_idt -c config
[sudo] password for micha:
Config name: config
0: Image: hisi-sec_usb_xloader.img Downalod Address: 0x20000
1: Image: hisi-sec_uce_boot.img Downalod Address: 0x6a908000
2: Image: recovery.bin Downalod Address: 0x1ac00000
Serial port open successfully!
Start downloading hisi-sec_usb_xloader.img@0x20000…
file total size 99584
downlaod address 0x20000
—<<<

Device is connected to ttyUSB1:
—>>>
[26135.470768] usb 1-12: Detected FT-X
[26135.471044] usb 1-12: FTDI USB Serial Device converter now attached to ttyUSB0
[26140.933341] usb 1-1: new full-speed USB device number 30 using xhci_hcd
[26141.086570] usb 1-1: New USB device found, idVendor=12d1, idProduct=3609, bcdDevice= 0.00
[26141.086575] usb 1-1: New USB device strings: Mfr=1, Product=4, SerialNumber=0
[26141.086579] usb 1-1: Product: \xe3\x84\xb0㌲㔴㜶㤸
[26141.086581] usb 1-1: Manufacturer: 䕇䕎䥎
[26141.088434] option 1-1:1.0: GSM modem (1-port) converter detected
[26141.088657] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1
—<<<

Note that the device does not time-out or disconnect when in this state. When reset in recovery mode without launching the recovery utility the USB device is only active for ~90 seconds (as expected).

Would be grateful for any additional troubleshooting steps.

With best regards,

  • Micha.

Specifically it hangs while trying to read data back from the serial port (read never returns). Would be really nice to have the source code of hikey_idt…

—<<<
Reading symbols from ./hikey_idt…(no debugging symbols found)…done.
Attaching to program: ./hikey_idt, process 31967
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6…Reading symbols from /usr/lib/debug/.build-id/18/b9a9a8c523e5cfe5b5d946d605d09242f09798.debug…done.
done.
Reading symbols from /lib64/ld-linux-x86-64.so.2…Reading symbols from /usr/lib/debug/.build-id/f2/5dfd7b95be4ba386fd71080accae8c0732b711.debug…done.
done.
0x00007f5cee8ed461 in __GI___libc_read (fd=4, buf=0x7fff4497a9e7, nbytes=1) at …/sysdeps/unix/sysv/linux/read.c:26
26 …/sysdeps/unix/sysv/linux/read.c: No such file or directory.
(gdb) bt
#0 0x00007f5cee8ed461 in __GI___libc_read (fd=4, buf=0x7fff4497a9e7, nbytes=1) at …/sysdeps/unix/sysv/linux/read.c:26
#1 0x0000000000400f7b in serial_port_read ()
#2 0x0000000000401141 in send_raw_data ()
#3 0x0000000000401418 in send_data_frame ()
#4 0x0000000000401634 in send_file ()
#5 0x0000000000401a88 in main ()
(gdb) stepi

—>>>

PS. In fastboot mode, fastboot can flash the ptable, so the actual ports and cable etc are working fine…

Hi @mwerle ,
Were you able to resolve this ? facing similar issue

Hi @Shruti_Gupta ,

Sorry, I really can’t recall. I do remember buying a few more boards and possibly using one of those to reflash the board I was having trouble with. Or possibly I just put that board aside as suspected hardware failure.

1 Like