This is a cache of https://discuss.96boards.org/t/unable-to-recover-hikey-960/2951. It is a snapshot of the page at 2024-11-01T06:46:44.688+0000.
Unable to recover Hikey 960 - HiKey 960 - 96Boards Forum

Unable to recover Hikey 960

Products Support HiKey 960
#1

Hello,

After my first attempt at flashing the Hikey 960 with images that I compiled from https://wiki.linaro.org/LHG/Build-AndroidTV-For-Hikey, I rendered my Hikey 960 unbootable.

I tried following the recovery mode instructions on https://github.com/96boards-hikey/tools-images-hikey960 and am running into difficulties. I tried this on 2 different machines both running ubuntu. In both cases the board is recognized on /dev/ttyUSB0, but when I run the recovery script I get a series of errors like these:

retry: ack 30, len 1, err 0
retry: ack d, len 1, err 0
retry: ack d, len 1, err 0
retry: ack a, len 1, err 0
retry: ack 73, len 1, err 0
retry: ack 65, len 1, err 0
retry: ack 63, len 1, err 0
retry: ack 64, len 1, err 0
retry: ack 62, len 1, err 0
retry: ack 67, len 1, err 0
retry: ack 20, len 1, err 0
retry: ack 6e, len 1, err 0
retry: ack 6f, len 1, err 0
retry: ack 74, len 1, err 0
retry: ack 20, len 1, err 0
retry: ack 44, len 1, err 0
retry: ack 43, len 1, err 0
retry: ack 55, len 1, err 0
retry: ack 2e, len 1, err 0
retry: ack d, len 1, err 0
retry: ack d, len 1, err 0
retry: ack a, len 1, err 0
retry: ack 53, len 1, err 0
retry: ack 65, len 1, err 0
retry: ack 63, len 1, err 0
retry: ack 44, len 1, err 0
retry: ack 62, len 1, err 0
retry: ack 67, len 1, err 0
retry: ack 56, len 1, err 0
retry: ack 65, len 1, err 0
retry: ack 72, len 1, err 0
retry: ack 20, len 1, err 0
send raw data failure

… and the flash procedure fails.

FYI, when I power up the board, I see this in the serial console:

hikey960 boarid:5301 xloader use UART6
scsysstat_value[16].
clear reset source
last_keypoint0,reboot_type0
secdbg not DCU.
SecDbgVer exit

 xloader chipid is: 0x36600110, start at 492ms.
Build Date: Jun 20 2017, 20:37:08
[clock_init] ++
hikey960 [hikey960_clk_init]
hi3660 [clk_setup]
[clock_init] --
storage type is UFS
ufs retry: 6 count v_tx:0 v_rx:0
ufs set v_tx:0 v_rx:0
Hikey960[5301] no need avs_init.
ddr ft:0xf20332a3,mode:1 target:4
UceLdOk
ch 0 gt_errfail, STATUS:0x00000060
ch 0 gdst_errfail, STATUS:0x00000040
ch 1 gt_errfail, STATUS:0x00000060
ch 1 gdst_errfail, STATUS:0x00000040
ch 2 gt_errfail, STATUS:0x00000060
ch 2 gdst_errfail, STATUS:0x00000040
ch 3 gt_errfail, STATUS:0x00000060
ch 3 gdst_errfail, STATUS:0x00000040
timeout
timeout
timeout
timeout
density: 0x0c0c0c0c,0x00000000,0x0c0c0c0c,0x00000000,0x0c0c0c0c,0x00000000,0x0c0c0c0c,0x00000000 
ddr info 0x00000306 
400M
685M
1067M
C0R,V0x0000002c e:113
C1R,V0x0000002c e:193
C2R,V0x0000002c e:66
C3R,V0x0000002d e:66
C0R,V0x0000002d e:66
C1R,V0x0000002d e:66
C2R,V0x0000002d e:66
C3R,V0x0000002e e:66
C0R,V0x0000002e e:66
C1R,V0x0000002e e:66
C2R,V0x0000002e e:66
C3R,V0x0000002f e:66
C0R,V0x0000002f e:65
C1R,V0x0000002f e:65
C2R,V0x0000002f e:66
C3R,V0x00000030 e:65
1244M
1866M
C0R,V0x00000016 e:113
C2R,V0x00000016 e:113                                                                 
C0R,V0x00000017 e:66                                                                  
C1R,V0x00000017 e:66                                                                  
C2R,V0x00000017 e:66                                                                  
iomcu_subsys_init                                                                     
boot_c0 PROFILE 4
#2

No! Please do NOT use https://wiki.linaro.org/LHG/Build-AndroidTV-For-Hikey or for Hikey960. Hikey and Hikey960 are different boards!

Try running the recovery script https://github.com/96boards-hikey/tools-images-hikey960/blob/master/recovery-flash.sh. If you have both usb connections connected to the board, one for the uart and one for data transfer, make sure the /dev/ttyUSB# number refers to the data transfer one. To verify, make sure fastboot devices returns a device id before you start to flash images.

1 Like
#3

Thank you!

Now I’m seeing that in fastboot recovery mode that that USB Type-C port isn’t detected. I am running on Mac OS (Sierra), with ubuntu in a Virtual Box guest. For what it’s worth I was unable to detect the device on Type-C even a dedicated Linux system.

Any ideas?

#4

I am running on Mac OS (Sierra), with ubuntu in a Virtual Box guest.

Again, no! Both boards are not recognized on osx so the guest OS will not be able to detect them. See https://discuss.96boards.org/t/fastboot-devices-not-recognizing-the-hikey-board for previous discussion. Best to either install linux as dual boot or boot into linux using a live usb device.

#5

I was actually able to able to update images on the HiKey 960 from a Mac Book Pro using fastboot. That’s how I wound up putting the wrong images on there in the first place. I also previously put the official images from Google on the card using the instructions here: https://source.android.com/source/devices — again from a MacBook.

(When I did this I also had a serial console attached I saw the console message indicating the USB connection was detected.) I connected using a cable that was USB type C on one end and regular old fashioned USB on the other end.

Also, I tried connecting to the HiKey 960 from a Raspberry Pi, and also the USB-C connection is not recognized.

So do you have any idea why it might not be working now?

#6

Are you using a different USB cable than previously? Recently there have been quite a few people posting problems that turned out to be made cables.

#7

Same (brand new) cable < 2 weeks old. I’ll try another one. I’ll also try my fancy new Thunderbolt to USB-C converter. I’m not optimistic, given how many different permutations I’ve tried I think I’ve rendered my board soft bricked. :frowning:

#8

I’m afraid I don’t disagree… although I guess I should observe that the recovery proceedure runs directly from ROM. No software on the board is needed to get ttyUSBx to fire up it. Thus if you see nothing, you’re not soft bricked… its in the hardware!

On that basis the last tests are to disconnect every cable and SD card, running only with USB-C and power. Off for a long time, set jumpers, then on… if you don’t see anything in dmesg log on the RPi then there’s not really anything more to do. However do make sure you check the dmesg log… there is a timeout in the ROM which means ttyUSBx comes and goes very quickly. I typically find it times out faster than I can type so I have to pre-type the recovery command, reboot the board and then strike return.

#9

Note that the short timeout is the other reason why trying to recovery on MacOS via a VM tends to be unreliable…

#10

Hmm. I’d like to just gut check that I’m doing the recovery issue properly, because a few weeks ago I made a similar mistake but was actually able to recover the board back to the Google AOSP image.

IIRC what I did that time was connect a UART Serial connector (UART Serial - 96Boards) to my Mac and reset it once to show it was in recovery mode. Then I was able to use the USB-C to flash images from the Mac to the 960.

Is there a simpler procedure? I understand that by simply setting the right jumpers the board can get into recovery mode but I was never able to get that to work.

#11

The procedure is essentially fixed because is it implemented in the ROM of the SoC and therefore cannot be changed. The best guide to the procedure is here and, as @vchong already indicated, it should not be run from any kind of virtual machine (it is also best to run with everything disconnected from the board except for power and USB type C):

As a debug technique you can run dmesg | tail instead of Step 4. This will indicate whether the ROM firmware enumerated as a USB gadget (it helps distribute blame between hardware and software).