The files exist and are readable, they are freshly cloned from the GIT repo. So not sure what you mean by “Compare it against the 1st image …”? Is there any documentation about what these files contains and how the download protocol looks like?
Hope this is not a EMMC hardware issue; so before we really suspect the EMMC issue, could you help check below things:
-
When the board run into recovery mode, there have two ttyUSB devices, one is for console, another is for OTG device; so in some case some users may get reversed ttyUSB device than other users. So usually we expect ttyUSB0 is used for UART6 from low speed port; ttyUSB1 is for OTG. Please ensure if this is same at your side? If your OTG port is ttyUSB0, then please change argument when use hisi-idt command;
-
Could you try below command on PC: sudo apt-get remove modemmanager? Please NOTE, this command will remove the deamon ‘modemmanager’, so we can totally avoid the serial transferring from serial.
As a background, I’m running Linux Mint 18.2 with kernel 4.10.0-26. I’ve uninstalled modemmanager. There is no process or service running that matched “modem” in the name. This is what dmesg reports when I connect the device now. But there is no change from what happened when modemmanager was still installed:
usb 2-1.2.1: new full-speed USB device number 27 using xhci_hcd
usb 2-1.2.1: New USB device found, idVendor=0403, idProduct=6015
usb 2-1.2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1.2.1: Product: FT230X 96Boards Console
usb 2-1.2.1: Manufacturer: FTDI
usb 2-1.2.1: SerialNumber: DAZ9PA7G
ftdi_sio 2-1.2.1:1.0: FTDI USB Serial Device converter detected
usb 2-1.2.1: Detected FT-X
usb 2-1.2.1: FTDI USB Serial Device converter now attached to ttyUSB0
usb 2-1.2.4: new full-speed USB device number 28 using xhci_hcd
usb 2-1.2.4: New USB device found, idVendor=12d1, idProduct=3609
usb 2-1.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-1.2.4: Product: USB SER
usb 2-1.2.4: Manufacturer: HISILICON
option 2-1.2.4:1.0: GSM modem (1-port) converter detected
usb 2-1.2.4: GSM modem (1-port) converter now attached to ttyUSB1
When I run “sudo ./hikey_idt -c config -p /dev/ttyUSB1” this happens:
usb 2-1.2.4: USB disconnect, device number 28
option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
option 2-1.2.4:1.0: device disconnected
...
usb 2-1.2.4: new full-speed USB device number 29 using xhci_hcd
usb 2-1.2.4: New USB device found, idVendor=12d1, idProduct=3609
usb 2-1.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-1.2.4: Product: USB SER
usb 2-1.2.4: Manufacturer: HISILICON
option 2-1.2.4:1.0: GSM modem (1-port) converter detected
usb 2-1.2.4: GSM modem (1-port) converter now attached to ttyUSB1
Not sure, are the lines about the GSM mode converter supposed to disappear? IN the past there used to be a message “GSM modem (1-port) converter now disconnected from ttyUSB1” after a few seconds, but this does not happen any longer since the last update. But I can run the recovery procedure on a Hikey620 board without any issues using the python script hikey_idt.py. So the serial port seems to be accessible.
Is there a python script for the HiKey920 also, so I can debug the internal steps and log what happens?
I also think after finishing to download sec_fastboot.img, the GSM mode converter should be replaced by ‘fastboot’ device. So this is very likely the image sec_fastboot.img has not been downloaded successfully; if file sec_fastboot.img is broken, could you try again for the latest images from: https://github.com/96boards-hikey/tools-images-hikey960?
Sorry, so far Hisilicon has not opened related code. I think the first step for us is to narrow down the broken is happened in which step?
So, what else can we test then to narrow down the issue?
There are the SHA-1 hashed of the files I have locally
52ccaa9bc47f826c16d5e700d065269612af2af8 sec_usb_xloader.img
7040b13835085571b77b3e51dd3d86d1bd12ae53 sec_uce_boot.img
888bf1f57ce4ff91d4d269d141e8c09e58ec6aad sec_fastboot.img
642fc9c9c98c6b4fd51e6d62d8c5cc560c901e75 hikey_idt
and “config” contains:
./sec_usb_xloader.img 0x00020000
./sec_uce_boot.img 0x6A908000
./sec_fastboot.img 0x1AC00000
Running “sudo ./hikey_idt -c config -p /dev/ttyUSB1” manually always and the the same logs as what I’ve already posted. Form the logs and the UART output it seem that “sec_usb_xloader.img” can be downloaded and runs. When “hikey_idt” prints that it downloads “uce_boot”, there is a short delay and the UART and console start printing the errors (see posts above). Seems the board resets afterward, as I can run “hikey_idt” again and again with the same results.
Not sure what else I can try to give you more information here.
I have run out idea currently; so have forwarded you log to Hisilicon and landing team to check furthermore.
Thanks very much, hightly appreciated. I really hope they can help out here and hopefully the board is not broken…
I have two small improvement recommendations:
- recovery-flash.sh should have “#!/bin/bash -e” as first line, so the script fails on error
- hikey_idt it should return an non-zero exit code on error. Seem it’s always returning zero, which is painful when using this in a script.
Thanks a lot for the suggestions; have sent out pull request for this: https://github.com/96boards-hikey/tools-images-hikey960/pull/11
Have shared related info with Hisilicon and see if have chance to enhance for this.
the shebang symbol ‘#!’ is missed in the header, so send out pull request for this: https://github.com/96boards-hikey/tools-images-hikey960/pull/12; Thanks!
yes, should have mentioned the missing shebang explicitly. This drove me crazy at first, when parameters were not working here at all 
I’ve created https://github.com/96boards-hikey/tools-images-hikey960/issues/13 for the hikey_idt exit code issue.
@axel, Hisilicon engineer gave the feedback, from the log the UFS has tried to run with low frequency but still fail. So they suspect this is related with EMMC chip broken or has not mounted well.
So please contact the board Manufacturer for this; you could provide this forum link to manufacturer so they can see the evidence that it is a hardware problem.
Thanks for you help, will follow up there.
Is there UFS/EMMC chip required actually? I wonder if the board works with an SD card also. Might be slower, but that is not a problem for the stuff I’m doing.
AFAIK, Hikey960 SoC cannot directly boot images from sdcard or USB stick. The bootROM needs to load image from EMMC to SRAM, after that it’s flexible to load images from USB/EMMC/Sdcard; so the bootROM has decided the EMMC is mandatory.
ok, that explains why all my attempts have failed with the card so far.
Hi, seems I meet the similar issue when i tried to recover my HiKey960 boards, did you fix the issues?
When I tried to run hikey_idt, below messages were printed out and it never stop.
Config name: config
Port name: /dev/ttyUSB0
0: Image: ./sec_usb_xloader.img Downalod Address: 0x20000
1: Image: ./sec_uce_boot.img Downalod Address: 0x6a908000
2: Image: ./l-loader.bin Downalod Address: 0x1ac00000
Serial port open successfully!
Start downloading ./sec_usb_xloader.img@0x20000…
file total size 99648
downlaod address 0x20000
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
send raw data failure
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
retry: ack 0, len 1, err 0
no, I was never able to fix this.See the discussion above, conclusion was, that it must be broken somewhere and thus needs to be exchanged. I don’t know if anybody will ever look at this board to analyze the issue in detail eventually. But it sounded like there’s a hardware issue and it’s unlikely this can be fixed in the field. However, now that you have a similar issue…maybe his raises the attention?
Hi Axel, Thanks a lot for your reply.
Same problem on my side.
Board stopped booting after unplugging power supply while Android was running (hard reset).
After plugging power back - device was dead, not even green power led flashed.
Flashing recovery according to this guide gave me below error:
$ sudo ./hikey_idt -c config -p /dev/ttyUSB1
Config name: config
Port name: /dev/ttyUSB1
0: Image: ./hisi-sec_usb_xloader.img Downalod Address: 0x20000
1: Image: ./hisi-sec_uce_boot.img Downalod Address: 0x6a908000
2: Image: ./hisi-sec_fastboot.img Downalod Address: 0x1ac00000
Serial port open successfully!
Start downloading ./hisi-sec_usb_xloader.img@0x20000…
file total size 99584
downlaod address 0x20000
Finish downloading
Start downloading ./hisi-sec_uce_boot.img@0x6a908000…
file total size 23680
downlaod address 0x6a908000
retry: ack 0, len 0, err 0
retry: ack 0, len 0, err 5
retry: ack 0, len 0, err 5
retry: ack 0, len 0, err 5
retry: ack 0, len 0, err 5
Recovery binaries was taken from here, MD5 sums match.
Nothing changed here? Really no way to boot from SD card?
It really depends if you are using the AOSP firmware (officially supported) or the UEFI firmware (which I think is just unreleased snapshots). @Mani tested the later fairly recently:
