Core1 Wake-up Issue During SD Card Boot on STM32MP257

[Aks]

Hello

We are currently attempting to boot both Cortex-A35 cores of the STM32MP257 processor using an SD card. While we have successfully verified that both cores function independently under bare-metal conditions, we are facing challenges in waking both cores during the SD card boot process.

Specifically, we are attempting to release Core 1 from reset by setting the C1P1RST bit in the RCC_C1P1RSTCSETR register. However, we observe that the reset does not get released as expected—the value of the register does not reflect the release of the reset.

We are following the sequence outlined in Section 3.4 "Cortex-A35 boot mode" of the STM32MP257 Reference Manual. In this context, we would appreciate further clarification on the following steps mentioned in the boot procedure:

2. The core requests a warm reset through its internal reset management register in secure mode.
3. Both cores enter in WFI state.

We request a detailed explanation of the above two steps, particularly with regard to:

• The mechanism by which a core requests a warm reset in secure mode.

• The significance and timing of both cores entering the WFI (Wait-For-Interrupt) state in relation to system boot and reset management.

Thanks & Regards

Akshitha Pattem

 

 

 

 

 

 

 

[PatrickF]

Hi,

I think you don't need to use C1P1RST as I understand from wiki that both CA35 cores are executing the same Flash code from FSBL (so both core are started at same time by the bootrom). You should manage the second core behavior by yourself (in our FSBL code, I think 2nd core is immediately parked in WFI, see here ). Maybe this will help you to implement your own FSBL (usually you need to use the core ID to branch different init for the two CA35 cores).

https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_code_overview#On_STM32MP2-lines_and_STM32MP2-lines

 

Regards,

[Aks]

Hi @PatrickF 

According to the link you have shared in Section 6.3 titled “On STM32MP25x lines and STM32MP23x lines” it is mentioned that:

"The secondary core of the Cortex-A35 is parked in an infinite loop."

It also states:

"Once Aarch64 FSBL-A has been authenticated and decrypted, the ROM code programs the Cortex-A35 reset vector base address in the CA35SS_SYSCFG_VBAR_CRregister. Then the ROM code starts the Aarch64 FSBL-A execution by generating a warm reset of the Cortex-A35 cluster. Both cores of the Cortex-A35 cluster start and run the FSBL-A instructions. It is the FSBL-A responsibility to implement a 'holding pen' mechanism for the application."

Based on this information, I have implemented the C1P1RST reset as described, assuming it is the FSBL-A's (our application) responsibility to release the secondary core. However, I have observed that the reset is not getting released as expected.

I would appreciate your guidance on the following points:

1. What is the correct procedure to release the secondary Cortex-A35 core?

2. Where can I find detailed information regarding the warm reset mechanism mentioned in the documentation?

3. While I am using Section 3.4 “Cortex-A35 boot mode” as a reference, is there any additional documentation or section I should consult to correctly implement the wake-up of the second core after the first core?

Thanks & Regards

Akshitha Pattem

 

 

[PatrickF]

Hi @Aks 

I think there is a misunderstanding.

As stated, the core1 is parked by BootROM first, but this is until the BootROM code executing on core0 load a valid FSBL from the boot Flash to the SYSRAM.

Then BOTH cores are starting to execute this FSBL in SYSRAM (jump address as specified in header, should be after 0x0E002600 as the header size on STM32MP25 is 0x200).
There is no specific behavior nor procedure for second core. Both Core0 and Core1 are starts running same aarch64 code (it is up to your own bare-metal FSBL code to branch to specific core0/core1 code depending on core ID).

Note that section 3.4 “Cortex-A35 boot mode” refer to HW behavior, and list how the BootROM is switching to aarch64, you don't need to do this on your side.

 

C1P1RST is only needed if you want to reset core1 when already executing your code (no specific process, I think the core1 is just booting in aarch64 using your own SYSRAM vectors pointed by CA35SS_SYSCFG_VBAR_CR). Maybe check ARM documentation on how Cortex-A35 is booting.
Don't know which process (if any) use C1P1RST that in our deliveries (OpTEE, uBoot or Linux kernel).

 

Regards.