STM32MP157xx DDR accessing for the for the core 1

[srikanth]

Hi ,

We are using the STM32MP157-dk1 board. We are able to boot the both cores (cortex A7) bare metal code from the SRAM but where as loading to the DDR that time only core 0 is booting properly and core 1 not booting. Is their any way to enable the DDR accessing to core1(second A7).

[PatrickF]

Hi,

As far as I know, there is no specific setting related to core1. Maybe the default MMU setting avoid it (for security purposes, BootROM likely strongly limit Cortex-A access regions during boot).

I will check with expert.

Did you start second core as listed in https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_overview#Secondary_core_boot ?

I think you should try starting second core with BRANCH_ADDRESS pointing internal SYSRAM code (e.g. to check if core#1 really start but also to allows, if needed, to setup correctly the second core MMU before accessing DDR).

Regards.

[srikanth]

Thank you for the reply. I am following the below procedure, by this second core is running properly .

• write jump address into BRANCH_ADDRESS backup register.
• write 0xCA7FACE1 value into MAGIC_NUMBER backup register.
• generate an SGI interrupt to core1
• I am printing string in the core 1 its working fine.
• I didn't enabled the MMU in the core 0 also.

[srikanth]

Thank you for the reply. I am following the below procedure, by this second core is running properly .

• write jump address into BRANCH_ADDRESS backup register.
• write 0xCA7FACE1 value into MAGIC_NUMBER backup register.
• generate an SGI interrupt to core1
• I am printing string in the core 1 its working fine.
• I didn't enabled the MMU in the core 0 also.

[PatrickF]

Hi,

I got confirmation from expert that the BootROM allows BRANCH_ADDRESS to DDR range.

Maybe some clues

• If your code is compiled in Thumb, ensure you provided an odd address for the branch
• Try to put a core#1 test code in SYSRAM instead of DDR
• Try to make a more basic stuff than printing string on UART, e.g. check if a simple shared memory write occurs or a GPIO toggling
• Try setting a breakpoint on you own code in core#1 with your debugger (don't know if it is possible due to security concerns)

Regards.

[srikanth]

Hi,

I had tried in SRAM both the cores are working fine . When i am placing the code in DDR , when i am trying to run the code in situation core 1 is working fine but core 2 is not triggering. for this what may be the region.

[PatrickF]

Hi, I see no specific HW settings which should avoid 2nd core to access DDR.

Maybe have a look on how uBoot is starting 2nd core, e.g. https://github.com/ni/u-boot/blob/master/arch/arm/mach-stm32mp/psci.c#L119

You might need to debug/trace the 2nd core.

If the start or 2nd core in SYSRAM is ok, maybe check from this point if access/jump from SYSRAM to DDR is possible.

Regards.