Microchip UG0881 PolarFire SoC FPGA Booting And Configuration User Guide
- June 9, 2024
- MICROCHIP
Table of Contents
Microchip UG0881 PolarFire SoC FPGA Booting And Configuration
Warranty
Microsemi makes no warranty, representation, or guarantee regarding the information contained herein or the suitability of its products and services for any particular purpose, nor does Microsemi assume any liability whatsoever arising out of theapplication or use of any product or circuit. The products sold hereunder and any other products sold by Microsemi have been subject to limited testing and should not be used in conjunction with mission-critical equipment or applications. Any performance specifications are believed to be reliable but are not verified, and Buyer must conduct and complete all performance and other testing of the products, alone and together with, or installed in, any end-products. Buyer shall notrely on any data and performance specifications or parameters provided by Microsemi. It is the Buyer’s responsibility to independently determine suitability of any products and to test and verify the same. The information provided by Microsemi hereunder is provided “as is, where is” and with all faults, and the entire risk associated with such information is entirely with the Buyer. Microsemi does not grant, explicitly or implicitly, to any party any patent rights, licenses, or any other IP rights, whether with regard to such information itself or anything described by such information. Information provided in this document is proprietary to Microsemi, and Microsemi reserves the right to make any changes to the information in this document or to any products and services at any time without notice.
About Microsemi
Microsemi, a wholly owned subsidiary of Microchip Technology Inc. (Nasdaq: MCHP), offers a comprehensive portfolio of semiconductor and system solutions for aerospace & defense, communications, data center and industrial markets. Products include high-performance and radiation-hardened analog mixed-signal integrated circuits, FPGAs, SoCs and ASICs; power management products; timing and synchronization devices and precise time solutions, setting the world’s standard for time; voice processing devices; RF solutions; discrete components; enterprise storage and communication solutions, security technologies and scalable anti-tamper products; Ethernet solutions; Power- over-Ethernet ICs and midspans; as well as custom design capabilities and services. Learn more at www.microsemi.com.
Booting And Configuration
PolarFire SoC FPGAs use advanced power-up circuitry to ensure reliable power
on at power-up and reset. At power-up and reset, PolarFire SoC FPGA boot-up
sequence follows Power-on reset (POR), Device boot, Design initialization,
Microcontroller Subsystem (MSS) pre-boot, and MSS user boot. This document
describes MSS pre-boot and MSS User Boot. For information about POR, Device
Boot and Design initialization, see UG0890: PolarFire SoC FPGA Power-Up and
Resets User Guide.
For more information about MSS features, see UG0880: PolarFire SoC MSS User
Guide.
Boot-up Sequence
The boot-up sequence starts when the PolarFire SoC FPGA is powered-up or
reset. It ends when the processor is ready to execute an application program.
This booting sequence runs through several stages before it begins the
execution of programs.
A set of operations are performed during the Boot-up process that includes
power-on reset of the hardware, peripheral initialization, memory
initialization, and loading the user-defined application from non-volatile
memory to the volatile memory for execution.
The following figure shows different phases of the Boot-up sequence.
Figure 1 Boot-up Sequence
MSS Pre-Boot
Upon successful completion of Design Initialization, MSS Pre-boot starts its
execution. The MSS is released from a reset after completion of all normal
startup procedures. The system controller manages the programming,
initialization, and configuration of the devices. MSS Pre-boot does not occur
if the programmed device is configured for system controller suspend mode.
The MSS pre-boot phase of initialization is coordinated by system controller
firmware, although it may make use of the E51 in the MSS Core Complex to
perform certain parts of the pre-boot sequence.
The following events occur during the MSS pre-boot stage:
- Power-up of the MSS embedded Non-Volatile Memory (eNVM)
- Initialization of the redundancy repair associated with the MSS Core Complex L2 cache
- Authentication of User boot code (if User Secure boot option is enabled)
- Handover operational MSS to User Boot code
The MSS Core Complex can be booted in one of four modes. The following table lists the MSS pre-boot options, which can be configured and programmed into the sNVM. The boot mode is defined by the user parameter U_MSS_BOOTMODE[1:0]. Additional boot configuration data is mode-dependent and is defined by the user parameter U_MSS_BOOTCFG (see Table 3, page 4 and Table 5, 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 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 as part of the Libero design flow. Changing the mode can only be achieved through the generation of a new FPGA programming file.
Figure 2 • MSS Pre-boot Flow
Idle Boot
If the MSS is not configured (for example, blank device), then the MSS Core
Complex executes a boot ROM program which holds all the processors in an
infinite loop until a debugger connects to the target. The boot vector
registers maintains their value until the device is reset or a new boot mode
configuration is programmed. For configured devices, this mode can be
implemented using the
U_MSS_BOOTMODE=0 boot option in the Libero configurator.
Note: In this mode, U_MSS_BOOTCFG is not used.
The following figure shows the Idle boot flow.
Figure 3 • Idle Boot Flow
Non-secure Boot
In this mode, the MSS Core Complex executes from a specified eNVM address
without authentication. It provides the fastest boot option, but there is no
authentication of the code image. The address can be specified by setting
U_MSS_BOOTADDR in the Libero Configurator. This mode can also be used to boot
from any FPGA Fabric memory resource through FIC. This mode is implemented
using the
U_MSS_BOOTMODE=1 boot option.
The MSS Core Complex is released from reset with boot vectors defined by
U_MSS_BOOTCFG (as listed in the following table).
Table 2 • U_MSS_BOOTCFG Usage in Non-Secure Boot Mode 1
Offset (bytes)| ****
Size (bytes)
| ****
Name
| ****
Description
---|---|---|---
0| 4| BOOTVEC0| 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
The following figure shows the Non-secure boot flow.
Figure 4 • Non-secure Boot Flow
User Secure Boot
This mode allows user to implement their own custom secure boot and the
user secure boot code is placed in the sNVM. The sNVM is a 56 KB non-volatile
memory that can be protected by the built-in Physically Unclonable Function
(PUF). This boot method is considered secured because sNVM pages marked as ROM
are immutable. On power up, the system controller copies the user secure boot
code from sNVM to Data Tightly Integrated Memory (DTIM) of the E51 Monitor
core. E51 starts executing the user secure boot code.
If the size of the user secure boot code is more than the size of the DTIM
then user needs to split the boot code into two stages. The sNVM may contain
the next stage of the user boot sequence, which may perform authentication of
the next boot stage using the user authentication/decryption algorithm.
If authenticated or encrypted pages are used then the same USK key (that is,
U_MSS_BOOT_SNVM_USK) must be used for all authenticated/encrypted pages.
If authentication fails, the MSS Core Complex can be placed in reset and the
BOOT_FAIL tamper flag can be raised. This mode is implemented using the
U_MSS_BOOTMODE=2 boot 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 |
The following figure shows the user secure boot flow.
Figure 5 • User Secure Boot Flow
Factory Secure Boot
In this mode, the system controller reads the Secure Boot Image Certificate
(SBIC) from eNVM and validates the SBIC. On successful validation, System
Controller copies the factory secure boot code from its private, secure memory
area and loads it into the DTIM of the E51 Monitor core. The default secure
boot performs a signature check on the eNVM image using SBIC which is stored
in eNVM. If no errors are reported, reset is released to the MSS Core Complex.
If errors are reported, the MSS Core Complex is placed in reset and the
BOOT_FAIL tamper flag is raised. Then, the system controller activates a
tamper flag which asserts a signal to the FPGA fabric for user action. This
mode is implemented using the U_MSS_BOOTMODE=3 boot option.
The SBIC contains the address, size, hash, and Elliptic Curve Digital
Signature Algorithm (ECDSA) signature of the protected binary blob. ECDSA
offers a variant of the Digital Signature Algorithm which uses elliptic curve
cryptography. It also contains 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 | BOOTVEC0 | Boot vector in UBL for E51 |
12 | 4 | BOOTVEC1 | Boot vector in UBL for U540 |
16 | 4 | BOOTVEC2 | Boot vector in UBL 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 own serial
number. If the comparison fails, then the boot_fail tamper flag is set and
authentication is aborted.
VERSION
If SBIC revocation is enabled by U_MSS_REVOCATION_ENABLE, the SBIC is rejected
unless the value of VERSION is greater than or equal to the revocation
threshold.
SBIC REVOCATION OPTION
If SBIC revocation is enabled by U_MSS_REVOCATION_ENABLE and OPTIONS[0] is
‘1’, all the SBIC versions less than VERSION are revoked upon complete
authentication of the SBIC. The revocation threshold remains at the new value
until it increments again by a future SBIC with OPTIONS[0] = ‘1’ and a higher
VERSION field. The revocation threshold may only be incremented using this
mechanism and can only be reset by a bit-stream.
When the revocation threshold is updated dynamically, the threshold is stored
using the redundant storage scheme used for passcodes such that a power
failure during device boot does not cause a subsequent device boot to fail. If
the update of revocation threshold fails, it is guaranteed that the threshold
value is either the new value or the previous one.
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
The following figure shows the factory secure boot flow.
Figure 6 • Factory Secure Boot Flow
MSS User Boot
MSS user boot takes place when the control is given from System Controller to MSS Core Complex. Upon successful MSS pre-boot, system controller releases the reset to the MSS Core Complex. MSS can be booted up in one of the following ways:
- Bare Metal Application
- Linux Application
- AMP Application
Bare Metal Application
The bare metal applications for the PolarFire SoC can be developed using
SoftConsole tool. This tool provides the output files in the form of .hex
which can be used in the Libero flow to include into the programming bitstream
file. The same tool can be used to debug the Bare Metal applications using
JTAG
interface.
Th following figure shows the SoftConsole Bare Metal application which has
five harts (Cores) including E51 Monitor core.
Figure 7 • SoftConsole Project
Linux Application
This section describes the boot sequence for Linux running on all U54 cores.
A typical boot process consists of three stages. The first stage boot loader
(FSBL) gets executed from the on-chip Boot flash (eNVM). The FSBL loads the
second stage boot loader (SSBL) from a boot device to external RAM or Cache.
The boot device can be eNVM or embedded memory microcontroller (eMMC) or
external SPI Flash. The SSBL loads the Linux operating system from boot device
to external RAM. In the third stage, Linux is executed from the external RAM.
The following figure shows the Linux Boot Process flow.
Figure 8 • Typical Linux Boot Process Flow
Details of FSBL, Device tree, Linux, and YOCTO build, how to build and configure Linux will be provided in the future release of this document.
AMP Application
Detailed description of Libero MSS Configurator and how to debug multi-
processor applications using SoftConsole will be provided in the future
release of this document.
Different Sources of Booting
To be updated in future versions of this document.
Boot Configuration
To be updated in future versions of this document.
Acronyms
The following acronyms are used in this document.
Table 1 • 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
Revision History
The revision history describes the changes that were implemented in the document. The changes are listed by revision, starting with the current publication.
Revision 2.0
The following is a summary of the changes made in this revision.
- Information about Factory Secure Boot was updated.
- Information about Bare Metal Application was updated.
Revision 1.0
The first publication of this document.
Microsemi Headquarters
One Enterprise, Aliso Viejo,
CA 92656 USA
Within the USA: +1 800-713-4113
Outside the USA: +1 949-380-6100
Sales: +1 949-380-6136
Fax: +1 949-215-4996
Email: sales.support@microsemi.com
www.microsemi.com
©2020 Microsemi, a wholly owned subsidiary of Microchip Technology Inc. All rights reserved. Microsemi and the Microsemi logo are registered trademarks of Microsemi Corporation. All other trademarks and service marks are the property of their respective owners.
References
- Microsemi | Semiconductor & System Solutions | Power Matters
- microsemi.com/index.php?option=com_docman&task=doc_download&gid=1244570
- microsemi.com/index.php?option=com_docman&task=doc_download&gid=1244574
Read User Manual Online (PDF format)
Read User Manual Online (PDF format) >>