1) Cortex-M4 is seen as a Linux Coprocessor, and it's code is loaded from Linux Filesystem, see https://wiki.st.com/stm32mpu/index.php/How_to_start_the_coprocessor_from_the_bootloader for details.
2) Cortex-M4 is not intended to access DDR content. Cortex-M4 has no cache and asynchronous path to AXI bus has not been optimized for that, so Cortex-M4 performance will be very largely impacted.
Furthermore, accessing small chunk of data to a DDR is never a good choice, as this will affect the DDRCTRL scheduling and so the performance of other AXI masters accessing the DDR SDRAM.
Although it is possible from HW point of view, in our Linux deliveries, Cortex-M4 access is forbidden inside TrustZone address space controller for DDR (TZC).
3) by internal SDRAM, I assume you talk about SYSRAM.
Cortex-M4 is not intended to access SYSRAM content. Cortex-M4 has no cache and asynchronous path to AXI bus has not been optimized for that, so Cortex-M4 performance will be very largely impacted.
Although it is possible from HW point of view, in our Linux deliveries, Cortex-M4 access is usually forbidden by system security settings.
4) Cortex-M4 Code/Data should fit within SRAM+RETRAM, i.e. 448KBytes.
Please note that although this could sound small Vs high-perf MCUs, the Cortex-M4 inside STM32MP1 is intended to act as a coprocessor, it will not have any User Interface nor FrameBuffer which are usually eating large porting of Flash/RAM on standalone MCU solutions. Futhermore, large protocol stack (Ethernet, WLAN, BT, USB, etc..) and Filesystem are also handled on Linux side.
Regards
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
