How the Hikey960 is starting up?

96boards

#1

I’ve checked all the information in this site but haven’t found the answer on my question.
How this board is booted?
From which address CPU starts to execute the code? I cannot find Kirin960 datasheet with boot process.
Could someone describe the boot flow in details?
I’m not asking for source code of mysterious sec_usb_xloader.img, sec_uce_boot.img, sec_fastboot.img.
I’m just asking why do we need them and how they are used?

Just to start I’ll start from the recovery process of a Hikey960.
As I currently understand, the boot process flows like that:

  • When we call “./hikey_idt -c ./config -p /dev/ttyUSB0” executable file “./hikey_idt” opens “/dev/ttyUSB0” and sends binaries from “./config” file into specified addressed, described inside of this file. Now we’re working with some USB/UART native bootloader (which is located NOT in UFS), which is inside of the silicon.
  • The content of the “./config” file:
    ./sec_usb_xloader.img 0x00020000
    ./sec_uce_boot.img 0x6A908000
    ./sec_fastboot.img 0x1AC00000
  • As I understand, recovery inbuilt USB/TTY bootloader places “./sec_usb_xloader.img” starting from “0x00020000” address (UFS or/and RAM?) and starts it from this address. This is the 2nd bootloader.
  • 2nd bootloader loads “./sec_uce_boot.img” starting from “0x6A908000” address (UFS or/and RAM?) which is 3rd bootloader.
  • 3rd bootloader loads “./sec_fastboot.img” starting from “0x1AC00000” address (UFS or/and RAM?) which is 4th bootloader. Now we’re doing what we want with fastboot.

P.S. Also I understand, that at some stages we need to set up operations with SRAM/DRAM/UFS and this is done during described boot flow. Without source codes or documentation it is really difficult to understand. Could someone extend this hypothetical boot scenarios?

I will appreciate any answers!
Thanks!


#2

These addresses are either physical RAM addresses or some virtual RAM mapping set by the initial ROM code. The UFS is used as a SCSI disk split into 4 blocks: sda for the xloader, sdb is empty, sdc is reserved for some weird android anti-recovery stuff, and sdd is the “real” hard disk, where you flash the partition table and use other partitions. This UFS structure is inherited from/by other modern huawei phones like Mate9, and is probably completely redundant if you just want to run debian
on this board without any androidisms.