STM32MP2 Series support #90295
STM32MP2 Series support #90295
Conversation
github-actions
bot
added
area: Interrupt Controller
area: Clock Control
platform: STM32
|
Hello @youssefz24, and thank you very much for your first pull request to the Zephyr project! |
github-actions
bot
requested review from
djiatsaf-st,
erwango,
etienne-lms,
FRASTM,
gautierg-st,
GeorgeCGV,
marwaiehm-st,
mathieuchopstm and
nordic-krch
There was a problem hiding this comment.
Thanks @youssefz24 for this work!
Some initial comments, but looks globally fine!
This comment was marked as resolved.
This comment was marked as resolved.
youssefz24
force-pushed
the
topic/stm32mp2_support
branch
from
dc679f5 to
8a8a74f
Compare
|
The following west manifest projects have changed revision in this Pull Request:
✅ All manifest checks OK Note: This message is automatically posted and updated by the Manifest GitHub Action. |
github-actions
bot
added
manifest
manifest-hal_stm32
DNM (manifest)
boards/st/stm32mp257f_ev1/support/openocd_stm32mp257f_ev1_m33.cfg
Outdated
Show resolved
Hide resolved
boards/st/stm32mp257f_ev1/support/openocd_stm32mp257f_ev1_m33.cfg
Outdated
Show resolved
Hide resolved
|
@erwango It seems I keep failing the CI twister test 7, when tracing back the issue it seems that it is linked to |
That's SW backend stuff, so it should probably work.
Indeed, strange but given the variety of impacted tests, you probably need to do it indeed. That should probably be quick. |
| reg = <0x44200000 DT_SIZE_K(64)>; | ||
| }; | ||
|
|
||
| exti2: interrupt-controller@46230000 { |
There was a problem hiding this comment.
@mathieuchopstm FYI: I see second exti instance. In #85508 I assumed one instance only. Do you see the need in #85508 to support multiple exti instances?
There was a problem hiding this comment.
The STM32MP2 actually has 2 EXTI instances and the HAL/LL functions take the said instance as an argument (see intc_exti_stm32.c.
For now we only need the EXTI2, with the idea of adding EXTI1 when peripherals need it. (When I ll reach that step I'll update the driver again, hopefully your PR is merged before that :p )
There was a problem hiding this comment.
I have not checked the MP2 RefMan at all, but I have been told a few words about this dual-EXTI point, and from my understanding only a single instance is """visible"""[1] in a given context, i.e. the issue is not multi-instance but merely knowing which instance we're operating on. (Ignore my comment if my understanding is wrong)
[1] Not literally as in "not mapped in address space", but in the sense that only one instance is wired to a given CPU
There was a problem hiding this comment.
Thank you both for very fast feedback. Let's stick then with current implementations and see, if extension to multi exti nodes will be needed later.
From my side I am planning to integrate MP2 dk1 later based on this PR.
There was a problem hiding this comment.
@mathieuchopstm From what I got, the instances can actually be shared at runtime between the CPUs, with EXTI1 between CPU1 (CA35) and CPU2 (CM33), and EXTI2 betewen all three of them: CPU1 (CA35), CPU2 (CM33) and CPU3 (CM0+). It all comes down to access rights defined by the resource manager allowed by the RIF peripheral (Resource Isolation Framework).
For instance, in this context, GPIO interrupts are linked to EXTI2 while HPDMAx are linked to EXTI1. So to add HPDMA, I have to figure that out. Nevertheless, I agree that the tricky part will be knowing which instance we operating on for a given situation. We'll cross that bridge when we get there :D
@KozhinovAlexander yeah I agree. 🎩
youssefz24
force-pushed
the
topic/stm32mp2_support
branch
from
79059f4 to
6ddf450
Compare
|
So to correct the CI twister test, I added the board support in the hwinfo driver. This requires changing the hal file used in the HAL to get the generic header and not the conf one, I opened a pull request in the STM32_HAL repo for this fix. Since the MP2 doesn t have a utils.h and uses HAL functions. |
youssefz24
force-pushed
the
topic/stm32mp2_support
branch
from
6ddf450 to
d1e0db0
Compare
github-actions
bot
added
the
DNM (manifest)
Update west.yml to add the STM32MP2x SoC support in the STM32 HAL. This is done after the merge of the PRs: zephyrproject-rtos/hal_stm32#282 zephyrproject-rtos/hal_stm32#286 Signed-off-by: Youssef Zini <youssef.zini@savoirfairelinux.com>
Add the initial device tree source include (dtsi) files for the stm32mp25 series boards, covering non-secure configuration for zephyr on the Cortex-M33 core. These files provide the basic hardware description, including CPU (Cortex-M33), memory, RCC clock controller and NVIC interrupt controller. Key features: - Set flash and RAM addresses to DDR memory. - Adjust RCC peripheral address for non-secure context. Signed-off-by: Youssef Zini <youssef.zini@savoirfairelinux.com>
Add initial soc support for the stm32mp2x series, including initial Kconfig entries and default configuration files. This enables Zephyr to recognize and build for the stm32mp2x series, taking the stm32mp257f_ev1 as a baseline. Includes: - Kconfig and defconfig files for SoC selection and defaults - soc.h for hal headers - CMakeLists.txt for build system integration - soc.yml update to register the new SoC System Clock is configured statically from DTS. So no initialization hook or soc.c needed. Signed-off-by: Youssef Zini <youssef.zini@savoirfairelinux.com>
Add a linker script for the stm32mp2x soc series. It includes the standard arm cortex-m linker and adds standard zephyr relocation sections. Replace the rom_start section name with .isr_vectors in the linker script. This is necessary for the zephyr firmware to be started by the remote proc driver which expects the section containing the vector table to be named .isr_vectors. Signed-off-by: Youssef Zini <youssef.zini@savoirfairelinux.com>
Introduce initial board support for the STM32MP257F-EV1. This includes: - Board metadata (board.yml, stm32mp257f_ev1.yaml) - Base software configuration (Kconfig.stm32mp257f_ev1) - CMake build integration (board.cmake) - Default configuration (stm32mp257f_ev1_stm32mp257fxx_m33_defconfig) - Minimal device tree (stm32mp257f_ev1_stm32mp257fxx_m33.dts) - Initial documentation and image for the stm32mp257f_ev1 board. - OpenOCD configuration files for debugging support. This enables the STM32MP257F-EV1 board to build and debug a hello world sample. Note that other necessary openocd configuration files are added to the zephyr sdk directory and can be found in the stm-openocd repository[1]. [1]:https://github.com/STMicroelectronics/device-stm-openocd/tree/main Signed-off-by: Youssef Zini <youssef.zini@savoirfairelinux.com>
Replace the use of `DT_NODELABEL(exti)` which depends on the node label with the defined EXTI_NODE macro using the instance with the `st_stm32_exti` compatible. Since both macros point to the same node, this change doesn't affect the code logic, but makes it independent of the node label, in preparation for the addition of the STM32MP2 exti nodes. Signed-off-by: Youssef Zini <youssef.zini@savoirfairelinux.com>
Add the mp2 exti2 dts to the dtsi file. Add mp2 exti hal and ll function calls with EXTI2 instance. We use the EXTI2 instance because it contains the GPIO interrupts in the non-secure context. (We are trying to build the blinky sample as a first milestone) Signed-off-by: Youssef Zini <youssef.zini@savoirfairelinux.com>
Add support for STM32MP2 series in the hwinfo driver. The STM32MP2 series uses the HAL functions since it doesn't have a ll_utils. Signed-off-by: Youssef Zini <youssef.zini@savoirfairelinux.com>
Introduce DeviceTree binding for the STM32MP2 RCC clock controller, enabling support for STM32MP2-specific clock configuration in Zephyr. Update Kconfig.stm32 to add a dependency on STM32MP2 configuration, allowing the use of STM32 LL RCC features when targeting STM32MP2 devices. Add header for STM32MP2 per peripheral clock definitions. Signed-off-by: Youssef Zini <youssef.zini@savoirfairelinux.com>
Add the stm32mp2 clock driver to the clock_control subsystem. The driver is a reduced version of the generic stm32 clock driver. Signed-off-by: Youssef Zini <youssef.zini@savoirfairelinux.com>
Remove gpio clock management from the GPIO driver when running on the cortex-m33 on the mp2 and gpio clocks are managed by the cortex-A, being the resource manager, allowed by the Resource Isolation Framework (RIF). Also add a specific binding for the mp2 gpio to make clock property optional. Signed-off-by: Youssef Zini <youssef.zini@savoirfairelinux.com>
Add GPIO A-K nodes to the device tree for STM32MP2 SoC. Note that GPIOs are disabled by default in the STM32MP2 SoC. Signed-off-by: Youssef Zini <youssef.zini@savoirfairelinux.com>
Add gpio support for STM32MP257F-EV1 board. Add the orange (&led0) LED to the device tree and enable GPIOJ. Add the user button USER2 to the device tree and enable GPIOG. This step allows building and debugging the blinky and button sample applications. Signed-off-by: Youssef Zini <youssef.zini@savoirfairelinux.com>
youssefz24
force-pushed
the
topic/stm32mp2_support
branch
from
d1e0db0 to
d7785b1
Compare
github-actions
bot
removed
the
DNM (manifest)
|
Add basic support of the Cortex-M33 core for the STM32MP2 series.
Provide support for the STM32MP257F-EV1 evaluation board.
It depends on the following PR from the STM32-HAL:zephyrproject-rtos/hal_stm32#282
This first step allows to run and debug the samples:
Signed-off-by: Youssef Zini youssef.zini@savoirfairelinux.com