2020-09-28 02:11 AM
Is there a way to directly start M4 and run M4 firmware from BootRom.
I am aware of the Engineering mode, however it requires the help of a debugger to copy the M4 firmware into the memory and run it. I like to do the same but in stand alone mode.
I am also aware that M4 can be started and run M4 firmware using SSBL, however we want the M4 firmware to configure clocks instead SSBL. Some could point out why not then use a M4 based microcontroller instead of the MPU, but we have a specific requirement to boot from BootRom to M4 on the MPU.
I am thinking about an idea to store M4 firmware as FSBL with the correct headers on one of the Flash devices (NOR/NAND Flash), once FSBL is stated by bootRom, copy M4 firmware and run it.
I have not come across such approach, that is why I like to ask if this is going to be even possible?
Solved! Go to Solution.
2020-09-28 03:04 AM
The bootrom is executed by Cortex-A7, so it's A7 that is in charge of loading and verifying the FSBL from external storage (e.g. SD card), put it in SYSRAM and jump to execute it.
During all these steps the M4 is kept in reset.
What you can do (please refer to the memory map in figure 4 "Memory Map" of RM0436):
A7 loads FSBL in SYSRAM (0x2ffc0000~0x2fffffff) and execute it.
The code in A7 should
The M4 will start the execution based on the reset vector.
The M4 code can be in the same SYSRAM. I mean, you do not need to copy the whole M4 code, the reset vector can point to code in SYSRAM. But the access to SYSRAM by M4 introduces some latency, so should be preferred to use RETRAM and/or SRAM1-4 for M4.
Please consider that I have not tested the process above. I hope I did not forgot some detail.
2020-09-28 02:40 AM
As you already pointed, BootROM could never starts M4 FW by itself, BootROM only load FSBL and start it on A7 core.
see https://wiki.st.com/stm32mpu/wiki/Boot_chain_overview#Overview
Nevertheless, if you are eager to develop your own solution, there in no objection to load and start M4 from FSBL.
Note also that RETRAM (64K) could be retained from VBAT, so an M4 could be started by FSBL even without any FW load.
I remind that this is not supported by our deliveries and deserve specific development on your side.
There is high risk of security issue or conflicts regarding system settings (e.g. RCC ) done by M4 FW, as TF-A and uBoot are expected to handled them before the M4 coprocessor is started.
2020-09-28 03:04 AM
The bootrom is executed by Cortex-A7, so it's A7 that is in charge of loading and verifying the FSBL from external storage (e.g. SD card), put it in SYSRAM and jump to execute it.
During all these steps the M4 is kept in reset.
What you can do (please refer to the memory map in figure 4 "Memory Map" of RM0436):
A7 loads FSBL in SYSRAM (0x2ffc0000~0x2fffffff) and execute it.
The code in A7 should
The M4 will start the execution based on the reset vector.
The M4 code can be in the same SYSRAM. I mean, you do not need to copy the whole M4 code, the reset vector can point to code in SYSRAM. But the access to SYSRAM by M4 introduces some latency, so should be preferred to use RETRAM and/or SRAM1-4 for M4.
Please consider that I have not tested the process above. I hope I did not forgot some detail.
2020-09-28 03:33 AM
Thanks @PatrickF and @AntonioST for the interesting suggestions I am going to give it a try.
2020-10-02 04:12 AM
I am thinking about another way to achieve the same, but I would like to know if it is going to be possible.
Instead of making the M4 firmware part of FSBL can we store it in same external NOR Flash separately and we load a small program in RETRAM and make the M4 reset vector to point to code in external NOR flash (supports XIP) ?
I have an external QSPI NOR flash connected to the MP1 which can be used to store FSBL and M4 firmware. If this is configured as memory mapped QSPI external flash by the A7 at FSBL boot stage, would it then allow us to access the external flash from M4 side?
or should the small program we load in RETRAM needs to configure QSPI NOR as memory mapped flash before executing code in it?
2020-10-02 08:02 AM
That's might be possible, but Cortex-M4 XIP from QUADSPI is very poor (maybe >90% slower than running from SRAM). Might be possible to copy code/data from QUADSPI to SRAMs. Up to you to prototype using EVAL board, which have a QUADSPI Serial-NOR Flash.
M4 startup time might be even worse that using TF-A or uBoot to copy M4 code, which might be also more flexible.
2020-10-02 09:02 AM
Thanks Patrick
I also like the idea of using existing remoteproc framework to load the firmware from SSBL, but SSBL configures the clocks based on clock configuration set in the Device Tree files this is a problem for us, we want the M4 code to configure all clocks for portability reasons. We like to use the same M4 code in a M4 only MCU in the future.
What if I use a minimal clock configuration in the Device Tree file, so that SSBL will only set the minimal clock configuration and when M4 is loaded M4 can do the rest of the clock configuration as needed?
If this is possible then I can make use of the remoteproc instead of going through the hassle of modifying the FSBL / SSBL.