[PATCH v3] ARM: stm32: Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx
Patrice CHOTARD
patrice.chotard at foss.st.com
Fri Apr 19 11:36:39 CEST 2024
On 4/19/24 05:59, Marek Vasut wrote:
> In case of an OTP-CLOSED STM32MP15xx system, the CPU core 1 cannot be
> released from endless loop in BootROM only by populating TAMP BKPxR 4
> and 5 with magic and branch address and sending SGI0 interrupt from
> core 0 to core 1 twice. TAMP_SMCR BKP..PROT fields must be initialized
> as well to release the core 1 from endless loop during the second SGI0
> handling on core 1. Initialize TAMP_SMCR to protect the first 32 backup
> registers, the ones which contain the core 1 magic, branch address and
> boot information.
>
> This requirement seems to be undocumented, therefore it was necessary
> to trace and analyze the STM32MP15xx BootROM using OpenOCD and objdump.
> Ultimately, it turns out that a certain BootROM function reads out the
> TAMP_SMCR register and tests whether the BKP..PROT fields are non-zero.
> If they are zero, the BootROM code again waits for SGI0 using WFI, else
> the execution moves forward until it reaches handoff to the TAMP BKPxR 5
> branch address.
>
> This fixes CPU core 1 release using U-Boot PSCI implementation on an
> OTP-CLOSED system, i.e. system with fuse 0 bit 6 set.
>
> Reviewed-by: Patrick Delaunay <patrick.delaunay at foss.st.com>
> Signed-off-by: Marek Vasut <marex at denx.de>
> ---
> Cc: Igor Opaniuk <igor.opaniuk at foundries.io>
> Cc: Patrice Chotard <patrice.chotard at foss.st.com>
> Cc: Patrick Delaunay <patrick.delaunay at foss.st.com>
> Cc: Simon Glass <sjg at chromium.org
> Cc: Simon Glass <sjg at chromium.org>
> Cc: Tom Rini <trini at konsulko.com>
> Cc: u-boot at dh-electronics.com
> Cc: uboot-stm32 at st-md-mailman.stormreply.com
> ---
> V2: Fix up the BKPRWD/BKPWD mask typo
> V3: - Update the allocation to 0x20/0x20
> - Update commit message
> - Add RB from Patrick
> ---
> arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
> index dd99150fbc2..d75ec99d6a1 100644
> --- a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
> +++ b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
> @@ -14,6 +14,7 @@
> #include <asm/arch/sys_proto.h>
> #include <dm/device.h>
> #include <dm/uclass.h>
> +#include <linux/bitfield.h>
>
> /* RCC register */
> #define RCC_TZCR (STM32_RCC_BASE + 0x00)
> @@ -41,6 +42,9 @@
> #define TZC_REGION_ID_ACCESS0 (STM32_TZC_BASE + 0x114)
>
> #define TAMP_CR1 (STM32_TAMP_BASE + 0x00)
> +#define TAMP_SMCR (STM32_TAMP_BASE + 0x20)
> +#define TAMP_SMCR_BKPRWDPROT GENMASK(7, 0)
> +#define TAMP_SMCR_BKPWDPROT GENMASK(23, 16)
>
> #define PWR_CR1 (STM32_PWR_BASE + 0x00)
> #define PWR_MCUCR (STM32_PWR_BASE + 0x14)
> @@ -136,6 +140,18 @@ static void security_init(void)
> */
> writel(0x0, TAMP_CR1);
>
> + /*
> + * TAMP: Configure non-zero secure protection settings. This is
> + * checked by BootROM function 35ac on OTP-CLOSED device during
> + * CPU core 1 release from endless loop. If secure protection
> + * fields are zero, the core 1 is not released from endless
> + * loop on second SGI0.
> + */
> + clrsetbits_le32(TAMP_SMCR,
> + TAMP_SMCR_BKPRWDPROT | TAMP_SMCR_BKPWDPROT,
> + FIELD_PREP(TAMP_SMCR_BKPRWDPROT, 0x20) |
> + FIELD_PREP(TAMP_SMCR_BKPWDPROT, 0x20));
> +
> /* GPIOZ: deactivate the security */
> writel(BIT(0), RCC_MP_AHB5ENSETR);
> writel(0x0, GPIOZ_SECCFGR);
Hi Marek
Reviewed-by: Patrice Chotard <patrice.chotard at foss.st.com>
Thanks
Patrice
More information about the U-Boot
mailing list