Boot Flow for RD-Fremont-Cfg2 platform

Introduction

This page describes the overview of the software boot process on RD-Fremont-Cfg2 platform variant.

Overview

A simplified boot flow diagram is shown below.

../../../_images/boot-flow-multichip.png

RSS

On platform reset, RSS on each chip are released out of reset and SCP and MCP are held in reset state. RSS on each chip begin executing the TF-M’s BL1_1 from RSS ROM and provision the BL1_2 image into the One Time Programmable flash (OTP) of the respective chip and transfers the execution to the BL1_2 stage. More details on the provisioning can be found in the TF-M’s RSS provisioning page. BL1_2 authenticates and loads the TF-M’s BL2 (MCUBoot) stage which is responsible for authenticated loading of the next stage images as well as images of the other components in the respective chip. More details on BL2 can be found in Image Loading Using MCUBoot page. BL2 stage is also responsible for setting up the SCP’s ATU, NI-Tower instances and releasing SCP and MCP out of reset.

SCP

SCP is responsible for managing the per chip system power, setting up of the interconnect and configuring the interconnect for cross chip communication. More details on the interconnect setup can be found in CMN-Cyprus Driver Module and in CMN-Cyprus Multichip Configuration page. SCP is also responsible for releasing the LCPs out of reset after RSS loads the LCP firmware into ITCMs. RSS has to wait for the SCP to turn on the SYSTOP power domain before loading the LCP images. To maintain this synchronization, SCP and RSS communicates messages through MHUv3. More details on this can be found in SCP - RSS Communication page. Only the SCP on the primary chip releases the primary core out of reset. At this point, SCP on the secondary chips will wait for the SCMI messages.

LCP

LCP is responsible for managing per Application Processor’s power. The boot sequence of LCP is summarized in Local Control Processor page.