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.

[Aks]

Hello @PatrickF 

Thank you for the response.

As per the section 6.3 from the https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_code_overview#On_STM32MP2-lines_and_STM32MP2-lines

We understood that the secondary is parked into infinite loop by ROM Code. We would like to know how the secondary core is released from this loop. and it is also mentioned that it is "It is FSBL-A responsibility to implement "holding pen" mechanism for application."  So, this is the reason we are trying to wake up second core in our application according to Section 3.4 "Cortex-A35 boot mode" of the STM32MP257 Reference Manual.

However, we are able to run the second core in bare metal through the below startup code snippet.

.arch armv8-a

.global Debug_Start_Here
.global Reset_Handler
.global reset_handler
.type Reset_Handler, function
.equ reset_handler, Reset_Handler
.section .init, "ax"

Reset_Handler:

mrs x1, mpidr_el1
and x1, x1, #3
cbz x1, 1f // find core number and brach suitably
2: // core1 code
// wfi
// b 2b
b Reset2

But we are not able to wake up the secondary core when this application is loaded into sd-card. So kindly help us with the procedure to release the second core from infinte loop.

Thanks & Regards

Akshitha Pattem

[PatrickF]

Hi,
I confirm the following code is working on both core0 and core1 loaded from SD-Card.

On STM32MP257F-EV1, this light green led from core0 and blue led from core1.

No need of any 'wakeup' of core1.

 // Read MPIDR for extracting core index 
	MRS X0, MPIDR_EL1
	ANDS   X0, X0, #3         
	B.EQ core0
                               
// core1 code start here
core1:
	// Enable GPIOJ clock
	LDR w2,=RCC_GPIOJCFGR_add
	MOV w0,#0x6
	STR w0,[x2]		// Enable GPIO clock
	LDR w0,[x2]		// read back to be sure it is enabled
				
	// init GPIO MODER
	LDR w2,=GPIOJ_base_add
	MOV w0,#0x4000		// PJ7 output
	STR w0,[x2,#0]		// GPIO_MODER_add
	LDR w0,[x2,#0]		// read back to be sure it is done
		
	// blue LED on
	MOV w0,#0x80		// PJ7
	STR w0,[x2,#0x18]	// GPIO_BSRR_add

	B $	// STOP HERE

// core0 code start here
core0:
	// Enable full debug
	LDR w2,=BSEC_DENR_add
	LDR w0,=BSEC_DENR_val	// 0xDEB60FFE
	STR w0,[x2]
		
	// Enable VDDIO3 domain (as we use PD8)
	LDR w2,=PWR_base_add
	MOV w0,#0x100
	STR w0,[x2]		// VDDIO3SV=1
		
	// Enable GPIOD clock
	LDR w3,=RCC_GPIODCFGR_add
	MOV w1,#0x6
	STR w1,[x3]			// Enable GPIO clock
	LDR w1,[x3]			// read back to be sure it is enabled
			
	// init GPIO MODER
	LDR w3,=GPIOD_base_add
	MOV w0,#0x0000		
	movk w0,#0x0001, LSL #16 // PD8 output
	STR w0,[x3,#0]		// GPIO_MODER_add
	LDR w0,[x3,#0]		// read back to be sure it is done
		
	// Green LED on
	MOV w1,#0x100		// PD8
	STR w1,[x3,#0x18]	// GPIO_BSRR_add		
		
	B $	// STOP HERE 

Regards,

[Aks]

Hello @PatrickF 

As I have mentioned, we are using STM32MP257F-DK Board. We have followed same procedure mentioned above for our board but it doesn't work. Every time we boot we are able to see the code written for Core-0 works but not the core-1.

I'm attaching the my start-up code files below for your reference.

So based on our observations we assume that

• mpidr_el1 doesn't read the core-1  id during SD-card boot as it works fine in debug mode.
• We would like to know if the BOOT-ROM sets the cores in Secure or Non-Secure Mode.

Thanks & Regards

Akshitha Pattem

[PatrickF]

hi @Aks 

I cannot help more, the kind of board does not matter as here we talk only of STM32MP257F, BootROM and SD-Card, which is same between STM32MP257F-EV1 and STM32MP257F-DK board.
It is pure ARM Cortex-A35 SW issue on your side. ST does not provide specific support for bare-metal on STM32MP25.

On your core0 code, you could enable the debug (as it is disable during boot) and try to debug to see what is doig wrong. Maybe you access a disabled resource or else.

On my code, if after boot I connect a debugger (Lauterbach Trace32), I see both core stopped on their own infinite loop after the GPIO/LED set.

BootROM jump to the the loaded FSBL code in SYSRAM in aarch64 EL3h secure mode.

Regards.