hi lisa,
no, i don’t think there is any good documentation for that. It wouldn’t be a bad thing to make a wiki page with the boot information as the questions come up often… i will try to make one…
in the mean time, here are a few details…
The boot process is the following:
- The SoC ROM (aka Primary Boot Loader, PBL) code searches for the Secondary Boot Loader (SBL) on the boot device (eMMC or SD card). SBL includes 2 code segments.
- The first SBL segment is loaded (and authenticated) into internal memory, on the Cortex A53.
- The second SBL segment is loaded (and authenticated) into the RPM memory (RPM is a coprocessor on the SoC).
- SBL #1 initializes the DDR
- SBL #1 loads into DDR and authenticate the TZ and HYP images. then the RPM firmware is loaded into RPM RAM.
- SBL #1 then loads the Application boot loader (APPSBL, e.g. LK) into DDR
- SBL #1 job is finished, and the trusted firmware and hypervisor take over and initialize various things in the platform. and also the RPM is released from reset
- Eventually we end up in LK which is the first open source component in the boot stack, which everyone can rebuild/update from sources.
The firmware need to be placed on the boot device using a strict GPT. Each firmware is place on its own partition for example.
- gpt_both0.bin: this is the GPT that is flashed on the eMMC (or SD card). We generate the GPT ourselves in our build scripts using this tool [1]. It is possible for anyone to generate their own GPT, of course the basic structure should be kept but new partitions can be added/tweaked.
- sbl1.mbn: this is the SBL firmware , containing the initial bootloader code for A53 and RPM.
- rpm.mbn: RPM firmware.
- hyp.mbn: Hypervisor (called QHEE in QCOM vocabulary)
- tz.mbn: trusted firmware (called QSEE in QCOM vocabulary)
- tz-psci.mbn : same as above. in the past we had 2 variants of the TZ firmware, the initial release did not have support for PSCI, and that was added later. We have kept both variants for some time (I believe that we only have one version in the latest bootloader release), and we recommend to use the PSCI version.
- emmc_appsboot.mbn: this is the LK ELF image. This file is built by Linaro, from sources.
- NON-HLOS.bin: it contains some firmware (DSP, WLAN, …). we don’t really use this file, it’s mostly an artifact from the downstream android where these firmware are on a separate partitions. on Linux we put all firmware in /lib/firmware instead.
And now about sbc_1.0_8016.bin, this is a new file that we added in the most recent release. It is called 'CDT" data in QCOM jargon. It contains platform information that allow the SBL to identify the board it is running on (e.g. CPU, RAM, board name/type, …). Up until last release these information was hardcoded in the SBL image we got from QCOM, but that was a hack that was done at launch, which we finally had to get rid off. Since the last QCOM firmware release, the information is no longer hardcoded into SBL, so CDT data is needed so that SBL can detect the board properly. This information is later on used by the bootloader to load the appropriate DTB file. This is a fairly complex and legacy process… but basically without CDT data the wrong DTB file could be loaded and passed to the kernel.
hope it helps…
[1] https://git.linaro.org/landing-teams/working/qualcomm/db-boot-tools.git/ 96
Jun '17
