Hikey flashing: over sftp and not finding hikey idt

Products Support HiKey 960
#1 
zack-optee@zackoptee-Inspiron-15-7000-Gaming:/run/user/1000/gvfs/sftp:host=/storage/optee_android_manifest/device/linaro/hikey/installer/hikey960$ ./flash-all.sh /dev/ttyUSB0
android out dir:./../../../../..//out/target/product/hikey960
flashing recovery images.. please wait ~10 seconds
[sudo] password for zack-optee: 
sudo: ./hikey_idt: command not found
set a unique serial number

currently i have a problem with flashing and it hangs on my hikey 960. It does not see the hikey_idk executable in the same directory.

#2

This repository appears to contain hikey_idt: https://github.com/96boards-hikey/tools-images-hikey960

#3

what do you mean by this?

#4

You just said that you were missing hikey_idt.

#5

it’s in my directory. it hangs at the serial number part.

#6

Your log shows “command not found” on hikey_idt.

#7 
boot.img   config  fip.bin       hikey_idt      hisi-fastboot.img  hisi-nvme.img    hisi-sec_fastboot.img  hisi-sec_usb_xloader.img  l-loader.bin  prm_ptable.img  README        system.img         userdata.img
cache.img  dt.img  flash-all.sh  hisi-bl31.bin  hisi-lpm3.img      hisi-ptable.img  hisi-sec_uce_boot.img  hisi-sec_xloader.img      mkdtimg       ramdisk.img     recovery.bin  uefi-flash-all.sh  vendor.img

ls of directory

#8

Do an ls -l
And cat the sh.
And i’d suggest UEFI as preferable.

#9

uefi just waits for the device. yet flash all detects the usb device

#10

From what I understand, the hikey_idt works with some kind of recovery mode, which is different than fastboot that normally should be used for writing images to the device. Are you sure that you have the board in the correct mode?

When I sent you the board, it had the UEFI bootloader already installed, so all you should have needed to do was fastboot the particular images to the appropriate location.

So like I said, I need to see the ls -l and the contents of the sh so that I can see what the script is trying to do and whether the directory is prepared correctly for it to happen.

#11

thanks for the tech support! I have to rewrite the bootloader though hence why i’m flashing it in recovery mode. the .sh file merely tries to execute it.

#12

The bootloader can be written from fastboot, as long as the existing bootloader is intact.

#13

@Zacchaeus_Liang It looks a bit ugly and counter intuitive, and obviously improvement is possible, but the bootloader flash script is currently written to run from the root/top of your AOSP source tree, due to the fact that the bootloader images are in device/linaro/hikey/.. and the AOSP images are in out/.., so don’t cd to device/linaro/hikey/.. but just do sudo ./device/linaro/hikey/installer/hikey/flash-all.sh /dev/ttyUSBn. Also, the script always starts from ‘recovery’ mode (jumpers/switches 1-2 3-4 set, 5-6 not set), not ‘fastboot’ mode (jumpers/switches 1-2 5-6 set, 3-4 not set), because we don’t know if users have rewritten parts of the code that make up the recovery images or not.

At this point in time, chances of users making changes to the recovery images are probably not high. The same is true if you’re just doing TA development. This means you can start from ‘fastboot’ mode, and just flash the required images, as mentioned above. You can do this manually without using the script, i.e. just run from the command prompt any of the commands below with the image files in your current dir. sudo might be required.

# bootloader images
fastboot flash ptable prm_ptable.img
fastboot flash xloader hisi-sec_xloader.img
fastboot flash fastboot l-loader.bin
fastboot flash fip fip.bin
fastboot flash nvme hisi-nvme.img

# AOSP images
fastboot flash boot boot.img
fastboot flash cache cache.img
fastboot flash system system.img
fastboot flash userdata userdata.img
fastboot flash vendor vendor.img

Just to make the list complete, below are recovery images which you probably don’t need to update.

hisi-sec_usb_xloader.img
hisi-sec_uce_boot.img
recovery.bin
#15

Yes. EVERYTHING can be written using fastboot, as long as your bootloader is intact. That includes the system/vendor/boot images, as well as the bootloader and partition table, etc.

The only thing you need “recovery” mode for (which should not be confused with a typical Android recovery partition and UI), is if you break the bootloader.

#16

seems to be working thanks again!
do i unplug and switch the dip switches after it’s done or should i wait a bit?

#17

As soon as the fastboot command returns, its ready.

Now a little hint that could be useful to you for dev purposes… if you keep the switches in fastboot mode, it will always stop at fastboot. From fastboot, you can run “fastboot boot boot.img” to cause it to boot when you issue the command rather than having it auto-boot.