What is Hikey960 mechanism of booting?

I found a lot of manuals of how to recover and write ready-made .img or .bin files into the Hikey960 board,
but haven’t found no information about how the Hikey960 is booted.

I would like to know the boot process, for example, for recovery process,
./hikey_idt -c ./config -p /dev/ttyUSB0
where the content of the ./config file is:
./sec_usb_xloader.img 0x00020000
./sec_uce_boot.img 0x6A908000
./sec_fastboot.img 0x1AC00000

I’m wondering what are hikey_idt, sec_usb_xloader.img, sec_uce_boot.img and sec_fastboot.img.
Is it possible to get some information about these files?
Are there any publicly-available source codes for each of them?

Hisilicon has not released the source code for them. I personally think the main concern is related security (like secure booting and secure setting)…

But I think this should not block the development for open source solutions. Below are some thoughts:

  • Hikey_idt is tool to communicate from PC to bootROM, so can download images into SoC;

  • sec_usb_xloader.img/sec_uce_boot.img are Hisilicon propertied booting images, I don’t know the detailed info about them, but many stuffs are related with booting and initialization; For easier understanding, I’d like to understand these two images as bootROM’s enhancement images; so there have many stuffs are platform specific and it’s transparent for software;

  • sec_fastboot.img: we can take this image as the coordinate thing with ARM-TF BL1/BL2/BL31/BL33(UEFI); we have implemented full open source codes to replace it to use ARM-TF/UEFI. Please note, Hikey960 has enabled BL1/BL2 on it, so this can provide complete booting sequence and provide flexibility if you want do some prototyping in BL1/BL2; And @vchong has integrated OPTEE as well. So suggest you could dig into this part for booting sequence/image loading/ELx/GIC initialization.

@leo-yan Thank you for your comment! Anyway it was better than nothing~

IMHO, It is not secure to use binaries without having source codes or at list documentation for them.

If developers of the mentioned binaries/images are reading this than I would like to ask them for the publicly available documentation. I think for a community and public usage it is very important!

In any case, for the secure chain of trust development it is obvious to understand the process of booting. If process of booting is hidden than where is a guarantee that the system couldn’t be compromised?

By the way, @vchong doesn’t finished OPTEE build process porting yet. He said it may be finished until the end of this week.

Hi @P1119r1m , you are right and this is the first time I see the requirement for 96boards for secure booting.

From my understanding, Hikey/Hikey960 are used for AOSP reference board and development board, but for a complete production solution, I agree the secure boot is quite important. Here has two main aspects, one is mainly related with root of trust/secure booting/key management, another part is the provision tool so can use it to flash trusted images (flashing/downloading operations also need to be verified).

I could inquiry a bit for this with landing team/Hisilicon, but be honest from previous experience, the secure booting usually is sensitive so it’s hard to get support for this.

@leo-yan I got your point. Thanks!

About “requirement for 96boards for secure booting”. It is not a secret, that Hikey960 is used in OPTEE project, which is, in turn, uses ARM-TF, which is a part of a chain of trusted boot mechanism.

And by the way, using this topic I’m not asking to develop secure booting, I’m just wondering how board is booting now~

Hi leo-yan , is the provision tool available in the source package for Hikey 960?
If yes, can you please let me know the tool name. If no, how can I access the provision tool.

The provisioning tool permits the reinstall of the base firmware for hikey960 (step 3 of the install documentation). See https://github.com/96boards-hikey/tools-images-hikey960 .