UG0881: PolarFire SoC FPGA Booting and Configuration User Guide

Brand: Microsemi

Introduction

This document, UG0881, serves as a user guide for the booting and configuration of PolarFire SoC FPGAs. It details the boot-up sequence, various boot modes, and essential configurations for developers. PolarFire SoC FPGAs utilize advanced power-up circuitry for reliable power-on and reset operations. The boot-up sequence follows a defined path: Power-on Reset (POR), Device boot, Design initialization, Microcontroller Subsystem (MSS) pre-boot, and MSS user boot. This guide specifically covers the MSS pre-boot and MSS User Boot phases. For information on POR, Device Boot, and Design initialization, refer to UG0890: PolarFire SoC FPGA Power-Up and Resets User Guide. For details on MSS features, consult UG0880: PolarFire SoC MSS User Guide.

1 Booting And Configuration

PolarFire SoC FPGAs are designed with advanced power-up circuitry to ensure reliable operation upon power-up and reset. The boot-up sequence for the PolarFire SoC FPGA adheres to the following stages: Power-on Reset (POR), Device Boot, Design Initialization, Microcontroller Subsystem (MSS) Pre-Boot, and MSS User Boot. This user guide focuses on the MSS Pre-Boot and MSS User Boot phases. For comprehensive details on POR, Device Boot, and Design Initialization, please consult the UG0890: PolarFire SoC FPGA Power-Up and Resets User Guide. For further information regarding MSS features, refer to the UG0880: PolarFire SoC MSS User Guide.

1.1 Boot-up Sequence

The boot-up sequence commences when the PolarFire SoC FPGA is powered up or reset. It concludes when the processor is prepared to execute an application program. This sequence progresses through several stages before program execution begins. The boot-up process involves a series of operations, including power-on reset of the hardware, peripheral initialization, memory initialization, and loading the user-defined application from non-volatile memory into volatile memory for execution.

Figure 1: Boot-up Sequence Description

The boot-up sequence involves the following phases:

Phase 1: Power-on Reset (POR) - Initiated by device power-on or reset.
Phase 2: Device Boot - The device begins its boot process.
Phase 3: Design Initialization - Includes FPGA IO Auto-Calibration.
Phase 4: MSS Pre-Boot - The Microcontroller Subsystem undergoes its pre-boot process.
Phase 5: MSS User Boot - The Microcontroller Subsystem proceeds to user boot.

Following these phases, the system is ready to Execute Application.

1.1.1 MSS Pre-Boot

Upon successful completion of Design Initialization, the MSS Pre-boot process begins. The MSS is released from reset after all standard startup procedures are completed. The system controller manages the programming, initialization, and configuration of the devices. MSS Pre-boot is bypassed if the programmed device is configured for system controller suspend mode.

The MSS pre-boot initialization phase is coordinated by the system controller firmware, which may utilize the E51 core within the MSS Core Complex for specific pre-boot tasks. Key events during the MSS pre-boot stage include:

Power-up of the MSS embedded Non-Volatile Memory (eNVM).
Initialization of redundancy repair for the MSS Core Complex L2 cache.
Authentication of User boot code, if the User Secure boot option is enabled.
Handover of operational control from MSS to the User Boot code.

The MSS Core Complex supports four boot modes, configurable and programmable into the sNVM. The boot mode is determined by the user parameter U_MSS_BOOTMODE[1:0]. Additional boot configuration data is mode-specific and defined by the U_MSS_BOOTCFG parameter (refer to Table 3 on page 4 and Table 5 on page 6).

Table 1: MSS Core Complex Boot Modes

U_MSS_BOOTMODE[1:0]	Mode	Description
0	Idle boot	MSS Core Complex boots from boot ROM if MSS is not configured.
1	Non-secure boot	MSS Core Complex boots directly from an address defined by the U_MSS_BOOTADDR.
2	User secure boot	MSS Core Complex boots from sNVM.
3	Factory secure boot	MSS Core Complex boots using the factory secure boot protocol.

The boot option is selected during the Libero design flow. Changing the boot mode requires generating a new FPGA programming file.

Figure 2: MSS Pre-boot Flow Description

The MSS pre-boot flow begins with Power-on Reset, followed by IO Initialization and RAM Redundancy. Then, the eNVM is powered up and configured. Based on the U_MSS_BOOTMODE setting (0, 1, 2, or 3), the flow proceeds to Idle Boot, Non-Secure Boot, User Secure Boot, or Factory Secure Boot, respectively.

1.1.1.1 Idle Boot

If the MSS is not configured (e.g., a blank device), the MSS Core Complex executes a boot ROM program that places all processors in an infinite loop until a debugger connects. The boot vector registers retain their values until the device is reset or a new boot mode configuration is programmed. For configured devices, this mode is selected via the U_MSS_BOOTMODE=0 option in the Libero configurator. Note: U_MSS_BOOTCFG is not used in this mode.

Figure 3: Idle Boot Flow Description

The Idle Boot flow starts in Idle Mode (U_MSS_BOOTMODE=0). The system sets BOOTVEC to BOOTROM. All processors then execute an infinite loop until a debugger is launched, placing them in Debug Mode. Finally, the application execution begins.

1.1.1.2 Non-secure Boot

In Non-secure Boot mode (U_MSS_BOOTMODE=1), the MSS Core Complex executes from a specified eNVM address without authentication. This offers the fastest boot option but lacks code image authentication. The boot address is set using U_MSS_BOOTADDR in the Libero Configurator. This mode can also boot from any FPGA Fabric memory resource via FIC. The MSS Core Complex is released from reset with boot vectors defined by U_MSS_BOOTCFG.

Table 2: U_MSS_BOOTCFG Usage in Non-Secure Boot Mode 1

Offset (bytes)	Size (bytes)	Name	Description
0	4	BOOTVECO	Boot vector for E51
4	4	BOOTVEC1	Boot vector for U540
8	4	BOOTVEC2	Boot vector for U541
16	4	BOOTVEC3	Boot vector for U542
20	4	BOOTVEC4	Boot vector for U543

Figure 4: Non-secure Boot Flow Description

The Non-secure Boot flow (U_MSS_BOOTMODE=1) involves setting BOOTVEC to eNVM or Fabric, after which all processors execute the application.

1.1.1.3 User Secure Boot

This mode enables users to implement their own custom secure boot process. The user secure boot code resides in the sNVM, a 56 KB non-volatile memory protected by the built-in Physically Unclonable Function (PUF). This method is secure because sNVM pages marked as ROM are immutable. Upon power-up, the system controller copies the user secure boot code from sNVM to the E51 Monitor core's Data Tightly Integrated Memory (DTIM), where the E51 begins execution. If the user secure boot code exceeds DTIM capacity, it must be split into stages. The sNVM can store subsequent stages, which may include user authentication/decryption algorithms. For authenticated or encrypted pages, the same USK key (U_MSS_BOOT_SNVM_USK) must be used. If authentication fails, the MSS Core Complex can be reset, and the BOOT_FAIL tamper flag can be raised. This mode is activated using the U_MSS_BOOTMODE=2 option.

Table 3: U_MSS_BOOTCFG Usage in User Secure Boot

Offset (bytes)	Size (bytes)	Name	Description
0	1	U_MSS_BOOT_SNVM_PAGE	Start page in SNVM
1	3	RESERVED	For alignment
4	12	U_MSS_BOOT_SNVM_USK	For authenticated/encrypted pages

Figure 5: User Secure Boot Flow Description

The User Secure Boot flow (U_MSS_BOOTMODE=2) starts with setting BOOTVEC to BOOTROM. The System Controller copies the User Secure Boot code from sNVM to the E51 DTIM. The E51 then executes the User Secure Boot code. An authentication step for the next stage boot code follows. If there is no error, the reset is released to the MSS Core Complex, and all processors execute the application. If an error occurs during authentication, the MSS Core Complex is placed in reset, the BOOT_FAIL tamper flag is raised, and a signal is sent to the FPGA fabric.

1.1.1.4 Factory Secure Boot

In Factory Secure Boot mode (U_MSS_BOOTMODE=3), the system controller reads and validates the Secure Boot Image Certificate (SBIC) from eNVM. Upon successful validation, the system controller copies the factory secure boot code from its private secure memory area into the E51 Monitor core's DTIM. The default secure boot process includes a signature check on the eNVM image using the SBIC stored in eNVM. If no errors are detected, the reset is released to the MSS Core Complex. If errors are found, the MSS Core Complex is reset, the BOOT_FAIL tamper flag is raised, and a tamper flag is activated to signal the FPGA fabric for user action.

The SBIC contains the address, size, hash, and Elliptic Curve Digital Signature Algorithm (ECDSA) signature of the protected binary blob. ECDSA utilizes elliptic curve cryptography. The SBIC also includes the reset vector for each Hardware thread/core/processor core (Hart) in the system.

Table 4: Secure Boot Image Certificate (SBIC)

Offset	Size (bytes)	Value	Description
0	4	IMAGEADDR	Address of UBL in MSS memory map
4	4	IMAGELEN	Size of UBL in bytes
8	4	BOOTVECO	Boot vector in UBL for E51
12	4	BOOTVEC1	Boot vector in UBL for U540
16	4	BOOTVEC2	Boot vector for U541
20	4	BOOTVEC3	Boot vector in UBL for U542
24	4	BOOTVEC4	Boot vector in UBL for U543
28	1	OPTIONS[7:0]	SBIC options
28	3	RESERVED
32	8	VERSION	SBIC/Image version
40	16	DSN	Optional DSN binding
56	48	H	UBL image SHA-384 hash
104	104	CODESIG	DER-encoded ECDSA signature
Total	208	Bytes

DSN: If the DSN field is non-zero, it is compared against the device's serial number. A mismatch sets the boot_fail tamper flag and aborts authentication.

VERSION: If U_MSS_REVOCATION_ENABLE is active, the SBIC is rejected unless its VERSION is greater than or equal to the revocation threshold.

SBIC REVOCATION OPTION: If U_MSS_REVOCATION_ENABLE is active and OPTIONS[0] is '1', SBIC versions less than the current VERSION are revoked upon SBIC authentication. The revocation threshold updates dynamically and can only be incremented by future SBICs with OPTIONS[0] = '1' and a higher VERSION. It can only be reset via a bit-stream. Dynamic updates are stored using a redundant passcode scheme to prevent boot failure during power loss. If an update fails, the threshold remains at its previous or new value.

Table 5: U_MSS_BOOTCFG Usage in Factory Boot Loader Mode

Offset (bytes)	Size (bytes)	Name	Description
0	4	U_MSS_SBIC_ADDR	Address of SBIC in MSS address space
4	4	U_MSS_REVOCATION_ENABLE	Enable SBIC revocation if non-zero

Figure 6: Factory Secure Boot Flow Description

The Factory Secure Boot flow (U_MSS_BOOTMODE=3) begins with setting BOOTVEC to BOOTROM. The System Controller reads the SBIC from eNVM. If the Signature is Valid (Yes), the Factory Secure Boot Loader is copied from ROM to E51 DTIM, and BOOTVEC is set to the Factory Secure Boot Loader. The loader then calculates the hash 'H' of the eNVM image and checks if SBIC.H equals H. If Yes, BOOTVEC is set to SBIC.BOOTVEC, reset is released to the MSS Core Complex, and all processors execute the application. If the Signature is Invalid (No) or SBIC.H does not match H (No), the MSS Core Complex enters Reset, the BOOT_FAIL tamper flag is raised, and a signal is sent to the FPGA fabric.

1.1.2 MSS User Boot

MSS User Boot occurs when control is transferred from the System Controller to the MSS Core Complex. Following successful MSS pre-boot, the system controller releases the reset for the MSS Core Complex. MSS can be booted in one of the following ways:

Bare Metal Application
Linux Application
AMP Application

1.1.2.1 Bare Metal Application

Bare metal applications for the PolarFire SoC can be developed using the SoftConsole tool. This tool generates .hex output files, which are integrated into the Libero flow for the programming bitstream. The SoftConsole tool also supports debugging Bare Metal applications via the JTAG interface.

Figure 7: SoftConsole Project Description

The SoftConsole project view displays a typical Bare Metal application structure. It includes a project explorer with directories such as `Binaries`, `Includes`, `src` (containing `application`, `hart0` through `hart4`, `inc`, `modules`, `platform`), and configuration files like `mpfs-blinky_hw_Debug.launch`, `mpfs-blinky_Renode_Debug.launch`, and `mpfs-blinky_Renode_Start-platform-and-debug.launch`, along with `README.html` and `README.md` files. The structure highlights the presence of five cores (harts), including the E51 Monitor core.

1.1.2.2 Linux Application

This section details the boot sequence for Linux running on all U54 cores. A typical boot process involves three stages: The First Stage Boot Loader (FSBL) executes from the on-chip Boot flash (eNVM). The FSBL then loads the Second Stage Boot Loader (SSBL) from a boot device (eNVM, embedded memory microcontroller (eMMC), or external SPI Flash) into external RAM or Cache. Finally, the SSBL loads the Linux operating system from the boot device into external RAM, and Linux executes from there.

Figure 8: Typical Linux Boot Process Flow Description

The Linux boot process flow is sequential: Power-on/Reset initiates the process, followed by FSBL, then SSBL, and finally Linux execution.

Details regarding FSBL, device tree, Linux, and YOCTO build, along with instructions on building and configuring Linux, will be provided in a future release of this document.

1.1.2.3 AMP Application

A detailed description of the Libero MSS Configurator and debugging multi-processor applications using SoftConsole will be made available in a future release of this document.

1.2 Different Sources of Booting

Information on different sources of booting will be updated in future versions of this document.

1.3 Boot Configuration

Information on boot configuration will be updated in future versions of this document.

2 Acronyms

The following acronyms are used throughout this document:

Table 6: List of Acronyms

Acronym	Expanded
AMP	Asymmetric Multi-processing
DTIM	Data Tightly Integrated Memory (also called as SRAM)
ECDSA	Elliptic Curve Digital Signature Algorithm
eNVM	embedded Non-Volatile Memory
FSBL	First Stage Boot Loader
Hart	Hardware thread/core/processor core
MSS	Microprocessor Subsystem
POR	Power on Reset
PUF	Physically Unclonable Function
ROM	Read-only Memory
SCB	System Controller Bridge
sNVM	Secure Non-volatile Memory

3 Revision History

The revision history outlines the changes implemented in this document, listed by revision starting with the current publication.

3.1 Revision 2.0

Summary of changes in this revision:

Information regarding Factory Secure Boot was updated.
Information regarding Bare Metal Application was updated.

3.2 Revision 1.0

This was the first publication of this document.

	Microsemi SmartFusion2 Webserver Demo Guide: CoreTSE_AHB IP with lwIP and FreeRTOS This guide provides instructions on setting up and running a webserver demonstration using the Microsemi SmartFusion2 SoC FPGA, the CoreTSE_AHB IP, lwIP TCP/IP stack, and FreeRTOS.
	Microsemi FlashPro6 Device Programmer Quickstart Guide Concise guide for the Microsemi FlashPro6 Device Programmer, detailing kit contents, hardware installation, software licensing, documentation, and support. Includes JTAG pinout information and troubleshooting tips.
	SmartFusion2 SoC FPGA SRAM Initialization Guide: eNVM and Libero SoC v11.7 This application note from Microsemi details methods for initializing Static Random Access Memory (SRAM) in SmartFusion2 SoC FPGAs using embedded Non-Volatile Memory (eNVM). It covers initialization via Cortex-M3 processor or fabric master logic, providing design examples and implementation guidance for Libero SoC v11.7.
	Microsemi FPGA and SoC Product Catalog A comprehensive catalog of Microsemi's FPGA and SoC products, highlighting features, specifications, and applications for various industries including defense, automotive, industrial, and consumer markets.
	Accessing Serial Flash Memory with Microsemi SmartFusion2: Libero SoC & Keil uVision Tutorial Microsemi's TU0548 tutorial guides users through accessing serial flash memory using Libero SoC v11.7 and Keil uVision IDE with the SmartFusion2 Security Evaluation Kit, covering project setup, firmware, and debugging.
	Microsemi Libero SoC STA Coverage Issue for SmartFusion2, IGLOO2, RTG4, PolarFire Technical advisory CN20022 from Microsemi addresses a Static Timing Analysis (STA) coverage issue in Libero SoC software affecting SmartFusion2, IGLOO2, RTG4, and PolarFire product families. Details impact and required actions.
	Microsemi PolarFire FPGA Temperature and Voltage Sensor Demo Guide (DG0852) This guide details the Microsemi PolarFire FPGA Temperature and Voltage Sensor (TVS) demo. It covers design requirements, simulation, Libero SoC flow, programming with FlashPro Express, and running the demo application.
	Implementing JESD204B Interface Using SmartFusion2 Demo Guide This demo guide, DG0611, provides comprehensive instructions for implementing the JESD204B high-speed serial interface standard using Microsemi's SmartFusion2 SoC FPGA. It covers design requirements, simulation, hardware setup, GUI installation, and device programming, serving as a reference for high-speed serial interface applications.