STM32 MPU ROM code overview

Applicable for

STM32MP13x lines, STM32MP15x lines

---

1. ROM code overview

The ROM code is the first code executed by the Arm^® Cortex^®-A7 core(s) after reset.
The main features of the ROM code are listed in the table below for each STM32MP1 Series processor:

ROM code features		STM32MP13x lines	STM32MP15x lines
STM32 header for FSBL loading		v2	v1
Boot mode selection	Serial boot
	Flash memory boot
	Developer (also known as "engineering") mode
	SSP (secure secrets provisioning)
	RMA (return material analysis)
Image loading binary size (without STM32 header)		128 KB	247 KB
Secure boot	FSBL authentication (ECDSA)
	FSBL authentication key revocation	(x8)
	FSBL anti-rollback mechanism
	FSBL decryption (AES)
	Cryptographic accelerators (ECDSA, AES)
Secondary core boot		(N.A.)
Wake up from low power modes
Secure services export

The diagram below puts these features in sequence. It illustrates the ROM code execution flow, and each step is further described in the following sections.

2. STM32 header

To be properly recognized by the ROM code, the binary file loaded from the boot device must comply with a proprietary format, starting with a STM32 header.
The STM32MP15x lines  complie with STM32 header v1, whereas the STM32MP13x lines  uses the v2. The difference between these versions is mainly due to the introduction of the new secure boot features, listed in the previous section and described in the following ones.

3. Boot mode selection

3.1. Boot device selection

As shown in the figure and table below, the boot mode is determined by the boot pin states, OTP words and one TAMP register.

ROM code - boot source selection

BOOT pins	STM32MP13 TAMP_REG[30] STM32MP15 TAMP_REG[20] (Force Serial)	Primary boot source	Secondary boot source	Boot source #1	Boot source #2 if #1 fails	Boot source if #2 fails
b000 (Force Serial)	x (don't care)	x (don't care)	x (don't care)	Serial	-	-
b001	!= 0xFF	0 (virgin)	0 (virgin)	QSPI NOR	Serial	-
b010	!= 0xFF	0 (virgin)	0 (virgin)	e•MMC™	Serial	-
b011	!= 0xFF	0 (virgin)	0 (virgin)	FMC NAND	Serial	-
b100 (DEV Boot)	x (don't care)	x (don't care)	x (don't care)	NoBoot	-	-
b101	!= 0xFF	0 (virgin)	0 (virgin)	SD-Card	Serial	-
b110	!= 0xFF	0 (virgin)	0 (virgin)	Serial	-	-
b111	!= 0xFF	0 (virgin)	0 (virgin)	QSPI NAND	Serial	-
!= b100	!= 0xFF	Primary1	0 (virgin)	Primary1	Serial	-
!= b100	!= 0xFF	0 (virgin)	Secondary1	Secondary1	Serial	-
!= b100	!= 0xFF	Primary1	Secondary1	Primary1	Secondary1	Serial
!= b100	0xFF	x (don't care)	x (don't care)	Serial	-	-

¹Primary and Secondary are fields stored in OTP. When the selected boot mode is Serial boot or Flash memory boot, the ROM code configures the interface as specified in the following sub-sections. It loads the FSBL image into internal memory and runs Secure boot.

3.2. Serial boot

The ROM code supports UART and USB serial interfaces.

When serial boot is selected, the ROM code scans, in parallel, all bootable UART instances and the USB OTG. When activity is detected on an interface, the boot process proceeds with this interface and the others are ignored.

Note that it is possible to disable the USB or some UART instance by blowing relevant fuses of the boot source disable field in OTP. In all cases, whether the USB is disabled or not, HSE is mandatory.

3.2.1. USB boot

The ROM code supports boot on the USB OTG interface with HS PHY.

The ROM code uses OTG_HS_DP/DM signals available as additional functions on the USB_DP2/DM2 pins.

The USB OTG_HS is clocked by a 48 MHz and a 60 MHz clock, generated by using the HSE clock (from RCC).

The ROM code supports the following HSE values: 8, 10, 12, 14, 16, 20, 24, 25, 26, 28, 32, 36, 40, 48 MHz

The ROM code selects which HSE must used by following these steps:

• if the disable HSE frequency autodetection OTP bit is set to 1, the ROM code considers HSE = 24 MHz.
• If the HSE value OTP field is 0b00 (default behavior), then the ROM code autodetects the HSE by using the HSI clock (from RCC).
  • Recognized values are: 8, 10, 12, 14, 16, 20, 24, 32, 36, 28, 40, or 48 MHz.
    
  • If none of these values are recognized, the ROM code considers that HSE = 24 MHz.
    
• If HSE value OTP field is 0b01, then it considers that HSE=24 MHz
  
• If HSE value OTP field is 0b10, then it considers that HSE=25 MHz
  
• If HSE value OTP field is 0b11, then it considers that HSE=26 MHz
  

Warning

On STM32MP15x lines , in the case of USB boot, the application has to unmux the UART Rx GPIO pins, especially if it wants to use a given UART Rx signal on a different pin

3.2.2. UART Boot

The ROM code supports the following UART interfaces:

• USART/UART instances:
  • USART2, USART3, UART4, UART5, USART6, UART7, UART8

(one start bit, 8 data bits, even parity bit and one stop bit).

Configuration:

By default the ROM code scans all UARTs listed above. This list may be reduced by blowing OTP fuses in UART instances disabling field.

In the case of serial boot, the ROM code applies the following AFmuxes.
The ROM code first muxes only the Rx pins of bootable UART instances, and scans all these Rx lines in parallel. When activity is detected on a UART interface, the ROM code muxes the related TX, all others Rx are unmuxed, and the boot process proceeds with this interface.

Warning

On STM32MP15x lines , in the case of USB boot, the application has to unmux the UART Rx GPIO pins, especially if it wants to use a given UART Rx signal on a different pin

Signal	GPIO pin and alternate function (AF) for
	USART2	USART3	UART4	UART5	USART6	UART7	UART8
Rx	STM32MP15x lines  only : PA3 (AF07)	PB12 (AF08)	STM32MP13x lines  : PD8 (AF08) STM32MP15x lines  : PB2 (AF08)	PB5 (AF12)	PC7 (AF07)	PF6 (AF07)	PE0 (AF08)
TX	STM32MP15x lines  only : PA2 (AF07)	PB10 (AF07)	STM32MP13x lines  : PD6 (AF06) STM32MP15x lines  : PG11 (AF06)	PB13 (AF14)	PC6 (AF07)	PF7 (AF07)	PE1 (AF08)

3.3. Flash memory boot

The ROM code supports the following flash interfaces:

• serial NOR flash via QUADSPI internal peripheral
• serial NAND flash via QUADSPI internal peripheral
• parallel NAND flash via FMC internal peripheral
• SD card via SDMMC internal peripheral
• e•MMC™ via SDMMC internal peripheral

For more details on the mapping of each memory, refer to the STM32 MPU Flash mapping article.

Warning

BootROM searches the FSBL partitions only in the first 4Gbytes.

3.3.1. Boot from parallel / serial NAND

The NAND contains n copies of the FSBL in the first valid blocks. If the FSBL uses N blocks in the memory (N is usually 2 for a maximum 247 Kbyte FSBL with a memory having a 128 Kbyte block size), the ROM code scans blocks from the first and looks for the FSBL in the first N consecutive valid blocks found.

The ROM code supports parallel (via FMC) NAND and serial (via QSPI) NAND.

Supported parallel NAND:

The ROM code supports parallel NAND with the following parameters.

Block size (KBytes )	Page size (KBytes)	Data width	ECC1(bits and code)
128	2	8, 16	4 (bch), 8 (bch), 1 (hamming)
256	4	8, 16	4 (bch), 8 (bch), 1 (hamming)
512	4	8, 16	4 (bch), 8 (bch), 1 (hamming)
512	8	8, 16	4 (bch), 8 (bch), 1 (hamming)

¹: The ROM code supports both parallel NAND with or without on-die ECC. The ECC given here is for NAND without on-die ECC.

Supported serial NAND:

The ROM code supports serial NAND with the following parameters.

Block size (KBytes)	Page size (KBytes)
128	2
256	4
512	4
512	8

The ROM code only supports serial NAND with embedded ECC.
Some serial NANDs are multi-plane. The ROM code supports such multi-plane features when the OTP bit spinand needs plane select is set to 1.

Configuration:

In order to read a NAND flash memory, the ROM code needs to know the page size, the block size and the number of blocks. For parallel NAND, it also needs to know the width and the number of ECC bits.

The ROM code detects the NAND-parameter storage location by checking nand param stored in otp OTP bit value.

If the nand param stored in otp OTP bit value is equal to 0 (which is the default), the NAND must provide an ONFI compatible parameter table in which the ROM code looks for NAND parameters. “ONFI compatible ” means that the NAND provides a get parameter feature that returns a table where parameters needed by ROM code are located at standard ONFI offsets.

If the nand param stored in otp OTP bit value is equal to 1, the ROM code looks for the NAND parameter in OTP.

The number of ECC bits is a particular case, as it can be set by OTP even if the nand param stored in otp is equal to 0. This is to allow the user to override the recommended number of ECC bits given by the parameter table of an ONFI NAND.

Note that serial NANDs are neither ONFI compliant nor ONFI compatible :

• on STM32MP13x lines , this OTP bit value is not used for serial NAND, and the ROM code always looks for serial NAND parameters in OTP.
• on STM32MP15x lines , this OTP bit value must be set to 1 for serial NAND to force the ROM code to look for serial NAND parameters in OTP.

Warning

ECC parameters configured in ROM code above (ONFI or OTP) need to be aligned with upper components (boot stages or operating systems). This is done through the devicetree configuration, see FMC_device_tree_configuration.

The following table shows which ONFI parameters may be used by the ROM code:

Parameter Table Offset	Description	Needed for parallel NAND	Needed for serial NAND
6	Supported features (used to determine data width)
80-83	Number of data bytes per page
84-85	Number of spare bytes per page
92-95	Number of pages per block
96-99	Number of blocks per unit
112	Number of ECC bits correctability

The following table lists the NAND parameters that may be stored in fuses:

Parameter	STM32MP13x lines		STM32MP15x lines
	bank1	bank2
Page size	nand page size	nand page size	nand page size
Block size	nand block size	nand block size	nand block size
Number of blocks	nand block nb	nand block nb	nand block nb
Parallel NAND width	fmc nand width	fmc nand width	fmc nand width
Parallel NAND ECC bits	fmc ecc bit nb	fmc ecc bit nb	fmc ecc bit nb
Serial NAND needs plane select	spinand needs plane select	spinand needs plane select	spinand needs plane select

On STM32MP13x lines  there are two banks of parameters. By default the ROM code looks for a serial NAND configuration in bank1, and a parallel NAND configuration in bank2. This setting can be reversed by blowing fuse NAND configuration distribution.

On STM32MP15x lines  there is only one bank (bank1). Therefore only one non ONFI NAND can be used at a time.

In the case of serial NAND boot, the ROM code applies the same AFmuxes as those for serial NOR.

In the case of parallel NAND boot, the ROM code applies the following AFmuxes:

Signal	GPIO pin and alternate function (AF) for
	8 bits parallel NAND	16 bits parallel NAND
FMC_NOE	PD4 (AF12)
FMC_NWAIT	STM32MP13x lines  : PA9 (AF10) STM32MP15x lines  : PD6 (AF12)
FMC_NWE	PD5 (AF12)
FMC_NCE	PG9 (AF12)
FMC_ALE	PD12 (AF12)
FMC_CLE	PD11 (AF12)
FMC_D0	PD14 (AF12)
FMC_D1	PD15 (AF12)
FMC_D2	PD0 (AF12)
FMC_D3	PD1 (AF12)
FMC_D4	PE7 (AF12)
FMC_D5	PE8 (AF12)
FMC_D6	PE9 (AF12)
FMC_D7	PE10 (AF12)
FMC_D8	NA	PE11 (AF12)
FMC_D9	NA	PE12 (AF12)
FMC_D10	NA	PE13 (AF12)
FMC_D11	NA	PE14 (AF12)
FMC_D12	NA	PE15 (AF12)
FMC_D13	NA	STM32MP13x lines  : PB8 (AF12) STM32MP15x lines  : PD8 (AF12)
FMC_D14	NA	PD9 (AF12)
FMC_D15	NA	PD10 (AF12)

3.3.2. Boot from serial NOR

The NOR flash memory contains two copies of the FSBL. The ROM code tries to load and launch the first copy. In the case of failure, it then tries to load the second copy.

The ROM code looks for FSBL1 at offset LBA0, and FSBL2 at offset LBA512.

It is possible to use NOR flash memory either in single or in dual mode. In dual mode two NOR flashes are connected to the two ports of the NOR interface, and the two memories are used in interlaced mode.

Configuration:

The ROM code uses SPI legacy mode MOSI/MISO only (it uses only two pins IO0 and IO1 to transfer data).

The ROM code automatically detects single and dual modes.

In dual mode, BK1_nCS shall drive the two chip selects on board and BK2_nCS can remain unused or be used for other functions.

By default the ROM code applies the following AFmuxes:

Signal	GPIO pin and alternate function (AF) for
	serial NOR (single NOR)	serial NOR (dual NOR)
QUADSPI_CLK	PF10 (AF9)
QUADSPI_BK1_NCS	STM32MP13x lines  : PB2 (AF9) STM32MP15x lines  : PB6 (AF10)
QUADSPI_BK1_IO0	PF8 (AF10)
QUADSPI_BK1_IO1	PF9 (AF10)
QUADSPI_BK2_IO0	NA	PH2 (AF9)
QUADSPI_BK2_IO1	NA	STM32MP13x lines  : PG10 (AF10) STM32MP15x lines  : PH3 (AF9)

These default AFmux can be overwritten by values defined in the AFmux configuration OTP words.

Quad SPI CLK is set to HSI / 2 = 32 MHz

Note that on STM32MP15x lines , PH2 and PH3 pins are available only on some specific packages : TFBGA361 and LFBGA448.

3.3.3. Boot from SD card

SD cards contain two versions of the FSBL. The ROM code tries to load and launch the first copy. In the case of failure, it then tries to load the second copy.

The ROM code first looks for a GPT. If it finds it, it locates two FSBLs by looking for the two first GPT entries of which the name begins with "fsbl". If it cannot find a GPT, the ROM code looks for FSBL1 at offset LBA128, and FSBL2 at offset LBA640.

Configuration:

The ROM code uses only one data bit.

By default, the ROM code uses an SDMMC1 instance.

If the SD card memory interface OTP field value is not equal to 0, the ROM code uses the value of this field (1 or 2) to determine which SDMMC interface to use.

By default the ROM code applies the following AFmuxes:

Signal	GPIO pin and alternate function (AF) for
	SD card
SDMMC1_CK	PC12 (AF12)
SDMMC1_CMD	PD2 (AF12)
SDMMC1_D0	PC8 (AF12)
SDMMC1_CDIR	PB9 (AF11)
SDMMC1_D0DIR	AFMUX OTP needed

SDMMC CK is set to HSI / 4 = 16 MHz

If the SD card memory interface OTP field value is not equal to 0, the ROM code does not apply these settings, and instead uses the non-default AFmux values defined by the AFmux configuration OTP words.

Note that AFmux for SDMMC1_D0DIR has no default value and, if needed, it must be applied via the AFmux configuration OTP words.

3.3.4. Boot from e•MMC™

An e•MMC™ contains two copies of the FSBL in its two boot regions, but only one boot region is active at a time. The ROM code tries to load and launch the FSBL copy contained in the active boot region.

Configuration:

The ROM code uses only one data bit.

By default the ROM code uses an SDMMC2 instance.

If the e•MMC™ memory interface OTP field value is not equal to 0, the ROM code uses the value of this field (1 or 2) to determine which SDMMC interface to use.

By default, the ROM code applies following AFmuxes:

Signal	GPIO pin and alternate function (AF) for
	e•MMC™
SDMMC2_CK	PE3 (AF09)
SDMMC2_CMD	PG6 (AF10)
SDMMC2_D0	PB14 (AF09)

SDMMC CK is set to HSI / 4 = 16 MHz

If the e•MMC™ memory interface OTP field value is not equal to 0, the ROM code does not apply these settings, and instead uses the non-default AFmux values defined by AFmux configuration OTP words.

3.4. Developer (also known as "engineering") mode

Developer boot allows the user to connect a debugger on an opened device. This allows any software to be loaded and run on either the CA7 or the CM4.

The ROM code detects developer boot when the boot pins value is 0b100. The ROM code then simply enters an infinite loop after having:

• re-opened CA7 secure debug,
• started running an infinite loop CM4

Engineering boot is not available on closed devices (cf Closing the device).

3.5. Life cycle

The ROM code behavior is strongly linked to the device state in the product life cycle.

Device states

• OPEN state: By default the device is in open state. Authentication is not mandatory. An authentication error does not prevent the FSBL from being started.
• CLOSED state: Once product secrets have been provisioned into the device, it can be closed by blowing closing bit fuses (see is closed on STM32MP13x lines  and is closed on STM32MP15x lines ). On closed devices, authentication is mandatory. An authentication error prevents the FSBL from being started.
• RMA state: A closed device can be put once into RMA state, and then back to CLOSED state. When the device is in RMA state, all ROM code features, except those used to go back into closed state are disabled.

Note that the secrets provisioning can be done by direct writing into the OTP registers, or relying on the SSP (secure secrets provisioning) process, explained just below.

3.5.1. SSP (secure secrets provisioning)

The ROM code provides specific boot services allowing the user to store their own secrets in BSEC fuses in a secure way that guarantees the confidentiality and integrity of secrets.

For details about the full secure secrets provisioning (SSP) process, refer to AN5510: Overview of the secure secret provisioning (SSP) on STM32MP1 Series.

The ROM code uses the two following fuses to distinguish SSP boots:

• SSP request (STM32MP13x lines ) or SSP request (STM32MP15x lines ): when set to 1 it tells the ROM that SSP process is requested.
• SSP success (STM32MP13x lines ) or SSP success (STM32MP15x lines ) : when set to 1 it tells the ROM that SSP process is finished. Once this bit is set to 1, it is no longer possible to request SSP boots.

3.5.2. RMA (return material analysis)

RMA boot allows the user to prepare the device for return material analysis (RMA).

• RMA unlock

The user can request to put a closed device in RMA state by configuring via JTAG the RMA unlock password in BSEC JTAG_IN register, which the ROM code compares after reset to the password stored in rma unlock passwd fuses.

• RMA boot

When the device is in unlocked for RMA : DFT tests (tests of the silicon done during production) are possible again, but without the possibility of access to any sensitive data stored in fuses by the user. For a full list of locked fuses, refer to the STM32MP15 Reference manuals, "OTP mapping (OTP)" section, swprlock3 column.

• RMA Relock (STM32MP15x lines  only)

The user can request to put an RMA device back in the closed state by configuring, via JTAG, the RMA relock password in BSEC JTAG_IN register, which the ROM code compares after reset to the password stored in rma relock passwd fuses.

Information

The RMA Unlock and RMA Relock sequences execution set two constraints on the platform: The 5-pin standard JTAG interface must be used (2-pin SWD is not possible) The VDDCORE supply must not be power cycled during the reset that allows to come back in the ROM code, to keep BSEC JTAG_IN register content

4. Image loading

• In Serial boot and Flash memory boot, the first stage boot loader (FSBL) binary is loaded from the selected boot device into the internal SRAM, following the memory mapping illustrated below:

• In Developer (also known as "engineering") mode, the JTAG link is used to load the binary to execute.

5. Secure boot

The ROM code implements the authentication process as described in STM32 MPU ROM code secure boot ("image authentication" chapter).

ROM code - secure boot

If the #Secure boot authentication is successful, then the ROM code stores the address of the boot context in r0 register and jumps to the FSBL entry point defined in image header.

5.1. FSBL authentication (ECDSA)

FSBL authentication relies on an ECDSA verification algorithm, as described in the Image signing and Image authentication chapters.

5.2. FSBL authentication key revocation

On STM32MP13x lines , the ROM code allows the use of up to eight signing keys and provides a mechanism to revoke leaked keys. Details are described in the Image signing and Image authentication chapters.

5.3. FSBL anti-rollback mechanism

The ROM code provides an FSBL version anti-rollback mechanism to prevent launching of older versions of the FSBL. See details in Image authentication chapters.

5.4. FSBL decryption (AES)

On STM32MP13x lines , the ROM code provide an FSBL decryption feature. Details are described in the Image encryption and Image decryption chapters.

5.5. Cryptographic accelerators (ECDSA, AES)

On the STM32MP13x lines , the ROM code uses HASH, PKA, CRYP, and SAES cryptographic accelerators.

• HASH to perform SHA256 hashes.
• PKA to perform ECDSA signature verification
• CRYP or SAES to perform AES decryption of the FSBL

On STM32MP15x lines , the ROM code uses HASH cryptographic accelerators, to perform SHA256 hashes.

6. Secondary core boot

6.1. On STM32MP13x lines 

The chip embeds only one Cortex-A7 core.

6.2. On STM32MP15x lines 

The chip embeds two Cortex-A7 cores. At reset, both cores of the Cortex-A7 start and run the same instructions. The ROM code splits the execution flow so that only core0 runs the boot process. The secondary core of the Cortex-A7 is parked in an infinite loop, waiting for a signal from the application to proceed further. The signal mechanism is based on a secure SGI and the two backup registers MAGIC_NUMBER and BRANCH_ADDRESS.

To unpark core1, the application running on core0 must:

• write jump address into BRANCH_ADDRESS backup register.
• write 0xCA7FACE1 value into MAGIC_NUMBER backup register.
• generate an SGI interrupt to core1.

7. Wake up from low power modes

The ROM code manages exit from "wake up from low power modes" resulting in a reset.

7.1. On STM32MP13x lines 

Standby exit

The ROM code makes no distinction between Standby exit reset and Power On reset.

LPLV-Stop2 exit

The ROM code reads an address from BSEC SCRATCH register. This address may be any address except a ROM address. If the address is not in ROM range it jumps to it.

7.2. On STM32MP15x lines 

In the case of Standby exit reset, the ROM code proceeds as shown on following figure:

ROM code - wake up from low power modes

In such resets, the Cortex^®-M4 is always held on reset, and only the ROM code on Cortex^®-A7 runs. The behavior of the ROM code depends on value of bits MCU_BEN, MPU_BEN of RCC_MP_BOOTCR register.

Cortex^®-M4 wake up

If bit MCU_BEN of RCC_MP_BOOTCR register is set to 1, the ROM proceeds to Cortex^®-M4 software wake up.

The ROM code wakes up Cortex^®-M4 by releasing it from its "hold on reset" state.

• Cortex^®-M4 software integrity check

Before releasing Cortex^®-M4 the ROM code can use the backup registers to recover the Cortex^®-M4 software integrity check value and compare it to the one computed on RETRAM.

Note: if the device is closed, this check is mandatory.

Cortex^®-A7 wake up

The Cortex^®-A7 software wake up consists in processing Secure boot. The ROM proceeds to Cortex^®-A7 software wake up in three cases:

• If M4 software wake up is not required (that is, MCU_BEN=0)
• If M4 software wake up is required (that is, MCU_BEN=1) but fails,
• If M4 software wake up is required (that is, MCU_BEN=1), is processed successfully and MPU_BEN is also set to 1

Cortex^®-A7 returns to CStandby low power mode

If Cortex^®-M4 software wake up is required (that is, MCU_BEN=1), is processed successfully and MPU_BEN is set to 0, the ROM enters the Cortex^®-A7 in CStandby low power modes.

8. Secure services export

8.1. On STM32MP13x lines 

The ROM code does not export any service for the application.

8.2. On STM32MP15x lines 

The ROM code exports authentication services to the following stages of the STM32MP15 secure boot, starting with the FSBL.

9. Memory mapping

The ROM code memory mapping is illustrated in the Image loading section.

9.1. On STM32MP13x lines 

The boot context (see boot_api_context_t structure in plat/st/stm32mp1/include/boot_api.h with STM32MP13 compilation flag) is in the first 512 bytes of SRAM2. It contains information on the boot process (such as the selected boot device), and pointers to the ROM code services (used for secure boot authentication).

9.2. On STM32MP15x lines 

The boot context (see boot_api_context_t structure in plat/st/stm32mp1/include/boot_api.h with STM32MP15 compilation flag) is in the first 512 bytes of SYSRAM. It contains information on the boot process (such as the selected boot device) and pointers to the ROM code services (used for secure boot authentication).

10. System and peripheral registers state after boot sequence

10.1. On STM32MP13x lines 

10.1.1. RCC registers

10.1.1.1. All cases except Engineering boot

Except when boot pins values are equal to 0b100 (Engineering boot), the following clocks are used:

• PLL1 setting changed from reset values:
  • PLL1 clock source is kept as default: HSI (64 MHz)
  • DIVM+1 = 5, DIVN+1 = 32
  • VCO @819.2 MHz
  • PLL1_p @409.6MHz (DIVP+1 = 1)

• Cortex-A7 clocked at 409.6 MHz, using PLL1_p source

• PLL2 setting changed from reset values:
  • PLL2 clock source is kept as default: HSI (64 MHz)
  • DIVM+1 = 5, DIVN+1 = 35
  • VCO @896MHz
  • PLL2_p @448MHz (DIVP+1 = 1)

• AXI (aclk), AHB5 (hclk5) and AHB6 (hclk6) clocked at 112 MHz, using PLL2_p source.
  • AXIDIV+1 = 4

• APB4 (pclk4) clocked at 56 MHz
  • APB4DIV = 1 -> pclk4 = aclk/2

• APB5 (pclk5) clocked at 28 MHz
  • APB5DIV = 2 -> pclk5 = aclk/4

10.1.1.2. All cases

In all cases, the following clocks are also enabled in RCC

• DDRPHYC pclk4 (DDRPHYCAPBEN = 1), together with DDRPHYC APB reset released (DPHYAPBRST = 0)
• STGEN pclk5 and kernel clock (STGENEN = 1)
• ETZPC pclk5 (TZPCEN = 1)
• SYSCFG pclk3 (SYSCFGEN)

In each boot mode, the relevant GPIOA to GPIOZ clocks are enabled depending on interface needed and OTP settings.

10.1.1.3. Engineering boot

When boot pins value are equal to 0b100 (Engineering boot), the following settings are done:

• GPIOA hclk4 (GPIOAEN) clock enabled
• TZEN = 0 (RCC TrustZone security is disabled)
• Secure and non-secure debug opened (BSEC_DENABLE = 0x47F)

10.1.1.4. Serial boot

When serial boot (USB/UART) is used:

• GPIOA hclk4 (GPIOAEN) clock enabled
• USBPHYC pclk4 and PLL_USB input clock (USBPHYEN = 1)
• The HSE is enabled in crystal, analog bypass or digital bypass according to OSC_OUT setting (refer to the STM32MP13 Reference manuals). When disable HSE bypass detection is set to 1, ROM considers HSE is in oscillator mode.
  • HSEON = 1
  • HSEBYP = 0 or 1
  • DIGBYP = 0 or 1
• The HSE is enabled only in case of USB/UART boot. ROM waits for HSERDY with a timeout of 20ms.
• USB enumeration not maintained after USB boot, USB detach process done.

When HSE detected value is either 8, 10, 12, 14, 16 or 25 MHz, the bootrom uses PLL4_R as an intermediate PLL to set 24 MHz in USBPHY PLL entry.

10.1.2. STGEN registers

• STGENC_CNTCR.HLTDBG and EN =1
• STGENC_CNTFID0 = 64000000 (Bootrom uses HSI 64 MHz for STGEN kernel clock)

10.1.2.1. GPIO

Depending on Boot interface, GPIOx_MODER, GPIOx_OSPEEDR, GPIOx_PUPDR and GPIOx_AFRH/AFRL are set according to relevant 'Configuration' described above.

After boot on serial boot (USB/UART) or after engi-boot, or if boot error occurs PA13 is set in GPIO mode, Open-Drain, but in High-Z as ODR13=1 :

IP	Register	Field	Value at reset (hex)	Value after boot (hex)
PA13 GPIO registers modifications
GPIOA	GPIO_MODER	MODER13	3	1
	GPIO_OTYPER	OT13	0	1
	GPIO_OSPEEDR	OSPEEDR13	0	3
	GPIO_ODR	ODR13	0	1

10.2. On STM32MP15x lines 

10.2.1. RCC

10.2.1.1. All cases except Engineering boot

Except when boot pins value are equal to 0b100 (Engineering boot), the following clocks are used:

• PLL1 setting changed from reset values:
  • PLL1 clock source is kept as default: HSI (64 MHz)
  • DIVM+1 = 5, DIVN+1 = 32
  • VCO @819.2 MHz
  • PLL1_p @409.6MHz (DIVP+1 = 1)

• Cortex-A7 clocked at 409.6 MHz, using PLL1_p source

• PLL2 setting changed from reset values:
  • PLL2 clock source is kept as default: HSI (64 MHz)
  • DIVM+1 = 5, DIVN+1 = 35
  • VCO @448 MHz
  • PLL2_p @448MHz (DIVP+1 = 1)

• AXI (aclk), AHB5 (hclk5) and AHB6 (hclk6) clocked at 149.33 MHz, using PLL2_p source.
  • AXIDIV+1 = 3

• APB4 (pclk4) clocked at 74.66 MHz
  • APB4DIV = 1 -> pclk4 = aclk/2

• APB5 (pclk5) clocked at 37.33 MHz
  • APB5DIV = 2 -> pclk5 = aclk/4

10.2.1.2. All cases

In all cases, the following clocks are also enabled in RCC

• DDRPHYC pclk4 (DDRPHYCAPBEN = 1), together with DDRPHYC APB reset released (DPHYAPBRST = 0)
• USBPHYC pclk4 and PLL_USB input clock (USBPHYEN = 1)
• STGEN pclk5 and kernel clock (STGENEN = 1)
• ETZPC pclk5 (TZPCEN = 1)
• RTC/TAMP/BackupReg pclk5 (RTCAPBEN = 1)
• HASH1 hclk5 (HASH1EN = 1)
• SYSCFG pclk3 (SYSCFGEN)
• GPIOA hclk4 (GPIOAEN)

In each boot mode, the relevant GPIOA to GPIOZ clocks are enabled depending on interface needed and OTP settings

10.2.1.3. Engineering boot

When boot pins value are equal to 0b100 (Engineering boot), the following settings are done:

• TZEN = 0 (RCC TrustZone security is disabled)
• BOOT_MCU = 1 (MCU is running an infinite loop from RETRAM)

10.2.1.4. Serial boot

When serial boot (USB/UART) is used:

• The HSE is enabled in crystal, analog bypass or digital bypass according to OSC_OUT setting (refer to the STM32MP15 Reference manuals). When OTP WORD9.disable_bypass_detection_disable is set to 1, ROM considers HSE is in oscillator mode.
  • HSEON = 1
  • HSEBYP = 0 or 1
  • DIGBYP = 0 or 1
• The HSE is enabled only in case of USB boot. ROM waits for HSERDY with a timeout of 20ms.
• Relevant UART clocks are enabled on HSI

When HSE detected value is either 8, 10, 12, 14, 16 or 25 MHz, the bootrom uses PLL4_R as an intermediate PLL to set 24 MHz in USBPHY PLL entry.

10.2.2. STGEN

• STGENC_CNTCR.HLTDBG and EN =1
• STGENC_CNTFID0 = 64000000 (Bootrom uses HSI 64 MHz for STGEN kernel clock)

10.2.3. GPIO

Depending on Boot interface, GPIOx_MODER, GPIOx_OSPEEDR, GPIOx_PUPDR and GPIOx_AFRH/AFRL are set according to relevant 'Configuration' described above.

After boot on any interfaces (following system reset or standby wake-up) or after engi-boot, PA13 is set in GPIO mode, Open-Drain, but in High-Z as ODR13=1 :

IP	Register	Field	Value at reset (hex)	Value after boot (hex)
PA13 GPIO registers modifications
GPIOA	GPIO_MODER	MODER13	3	1
	GPIO_OTYPER	OT13	0	1
	GPIO_OSPEEDR	OSPEEDR13	0	3
	GPIO_ODR	ODR13	0	1

11. Debug and error cases

11.1. Debug and error messages

• PA13 management

The ROM code uses the PA13 pin to communicate some statuses. On STMicroelectronics boards, PA13 is connected to the red LED, as explained in the LEDs and buttons on STM32 MPU boards article.

• In the case of boot failure, the PA13 pin is set to low open-drain (that is, the red LED lights brightly).

• During UART/USB boot, the PA13 pin toggles open-drain at a rate of about 5 Hz until a connection is started (that is, red the LED blinks fast).

• With BOOT[2:0] = 0b100 (engineering boot, used for specific debug), PA13 toggles opendrain at a rate of about 5 kHz (that is, the red LED light is dim).

• In all other cases, the PA13 is kept in it’s reset value, that is, high-Z until software setting.

• Traces

• During its execution, the ROM writes binary traces into memory.

Traces can be downloaded and analyzed with the ROM trace analyzer tool.

• In the case of an internal blocking error, the ROM code writes a UART log error at 9600 bauds to the PA13 pin.

11.2. Common debug and error cases

• Memory boot failure

Secure boot flow always enters the serial boot loop during which the Error LED blinks. Therefore, observing such blinking when Memory boot is required indicates that Memory boot failed.

• Security issue

If the boot ROM encounters a security issue, it stops the secure boot immediately, and sets the Error LED to light brightly.

Read only memory

First stage boot loader

One time programmed

Tamper

Multimedia card

Secure digital

Universal asynchronous receiver/transmitter

USB on-the-go (Capability/type of USB port, acting primarily as USB device, to also act as USB host. Also known as USB OTG.)

High speed external oscillator (STM32 clock source)

High speed (MIPI^® alliance DSI standard)

High speed internal oscillator (STM32 clock source) or High speed synchronous serial interface (MIPI^® Alliance standard)

General-purpose input/output (A realization of open ended transmission between devices on an embedded level. These pins available on a processor can be programmed to be used to either accept input or provide output to external devices depending on user desires and applications requirements.)

Transmit

GPIO alternate function

Flash memories combine high density and cost effectiveness of EPROMs with the electrical erasability of EEPROMs. For this reason, the Flash memory market is one of the most exciting areas of the semiconductor industry today and new applications requiring in system reprogramming, such as cellular telephones, automotive engine management systems, hard disk drives, PC BIOS software for Plug & Play, digital TV, set top boxes, fax and other modems, PC cards and multimedia CD-ROMs, offer the prospect of very high volume demand.

SD memory card (https://www.sdcard.org)

Elliptic curve cryptography

Error correction capability

Open NAND flash interface (The ONFI working group, acronym for Open NAND flash interface, was founded in 2005. The group’s mission consists in creating a common industry standard for NAND Flash interfaces, to simplify integration of NAND Flash memory into consumer electronics (CE) devices and computing platforms. ST is one of the co-founder companies together with Hynix, Intel, Micron, Phison and Sony.)

Non applicable

Serial peripheral interface

GUID partition table

Return material analysis

Secure secret provisioning

debug and test protocol, named from the Joint Test Action Group that developed it

Boot and Security and OTP control

Techniques implemented during semiconductor development to improve device testability (Scan, BIST…).

Serial wire debug

Elliptic curve digital signature algorithm

Advanced encryption standard

Cryptographic processor

Cortex^®

Software generated interrupt

Microcontroller unit (MCUs have internal flash memory and are intended to operate with a minimum amount of external support ICs. They commonly are a self-contained, system-on-chip (SoC) designs.)

Microprocessor unit

Reset and clock control

Advanced peripheral bus

System time generator

Extended trustzone protection controller

System configuration

TrustZone^®
Arm^® and TrustZone^® are registered trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

Real time clock

Light-emitting diode

Read only memory

First stage boot loader

One time programmed

Tamper

Multimedia card

Secure digital

Universal asynchronous receiver/transmitter

USB on-the-go (Capability/type of USB port, acting primarily as USB device, to also act as USB host. Also known as USB OTG.)

High speed external oscillator (STM32 clock source)

High speed (MIPI^® alliance DSI standard)

High speed internal oscillator (STM32 clock source) or High speed synchronous serial interface (MIPI^® Alliance standard)

General-purpose input/output (A realization of open ended transmission between devices on an embedded level. These pins available on a processor can be programmed to be used to either accept input or provide output to external devices depending on user desires and applications requirements.)

Transmit

GPIO alternate function

Flash memories combine high density and cost effectiveness of EPROMs with the electrical erasability of EEPROMs. For this reason, the Flash memory market is one of the most exciting areas of the semiconductor industry today and new applications requiring in system reprogramming, such as cellular telephones, automotive engine management systems, hard disk drives, PC BIOS software for Plug & Play, digital TV, set top boxes, fax and other modems, PC cards and multimedia CD-ROMs, offer the prospect of very high volume demand.

SD memory card (https://www.sdcard.org)

Elliptic curve cryptography

Error correction capability

Open NAND flash interface (The ONFI working group, acronym for Open NAND flash interface, was founded in 2005. The group’s mission consists in creating a common industry standard for NAND Flash interfaces, to simplify integration of NAND Flash memory into consumer electronics (CE) devices and computing platforms. ST is one of the co-founder companies together with Hynix, Intel, Micron, Phison and Sony.)

Non applicable

Serial peripheral interface

GUID partition table

Return material analysis

Secure secret provisioning

debug and test protocol, named from the Joint Test Action Group that developed it

Boot and Security and OTP control

Techniques implemented during semiconductor development to improve device testability (Scan, BIST…).

Serial wire debug

Elliptic curve digital signature algorithm

Advanced encryption standard

Cryptographic processor

Cortex^®

Software generated interrupt

Microcontroller unit (MCUs have internal flash memory and are intended to operate with a minimum amount of external support ICs. They commonly are a self-contained, system-on-chip (SoC) designs.)

Microprocessor unit

Reset and clock control

Advanced peripheral bus

System time generator

Extended trustzone protection controller

System configuration

TrustZone^®
Arm^® and TrustZone^® are registered trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

Real time clock

Light-emitting diode

Mobile Industry Processor Interface, open membership organization that includes leading companies in the mobile industry that share the objective of defining and promoting open specifications for interfaces inside mobile terminals, see MIPI^® Alliance standard web site https://www.mipi.org

Display serial interface (MIPI^® Alliance standard)

Flash memory shortened to gain space in titles, tables and block diagrams

Arm^® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.