STM32: Add support for STM32L5 series and nucleo_l552ze_q board

[erwango]

This work add support for first STM32 Cortex-M33 based Series.
Support for board nucleo_l552_q is also added with minimum peripheral support for now.

[zephyrbot]

All checks are passing now.

checkpatch (informational only, not a failure)

-:431: WARNING:UNDOCUMENTED_DT_STRING: DT compatible string "st,stm32l552ze-nucleo-q" appears un-documented -- check ./dts/bindings/
#431: FILE: boards/arm/nucleo_l552ze_q/nucleo_l552ze_q.dts:13:
+	compatible = "st,stm32l552ze-nucleo-q", "st,stm32l552";

-:431: WARNING:UNDOCUMENTED_DT_STRING: DT compatible string "st,stm32l552" appears un-documented -- check ./dts/bindings/
#431: FILE: boards/arm/nucleo_l552ze_q/nucleo_l552ze_q.dts:13:
+	compatible = "st,stm32l552ze-nucleo-q", "st,stm32l552";

-:1053: WARNING:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses
#1053: FILE: drivers/pinmux/stm32/pinmux_stm32l5x.h:101:
+#define STM32L5X_PINMUX_FUNC_PC7_USART6_RX  \
+	(STM32_PINMUX_ALT_FUNC_8 | STM32_PUPDR_NO_PUL

- total: 0 errors, 3 warnings, 1363 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

Your patch has style problems, please review.

NOTE: Ignored message types: AVOID_EXTERNS BRACES CONFIG_EXPERIMENTAL CONST_STRUCT DATE_TIME FILE_PATH_CHANGES MINMAX NETWORKING_BLOCK_COMMENT_STYLE PRINTK_WITHOUT_KERN_LEVEL SPDX_LICENSE_TAG SPLIT_STRING VOLATILE

NOTE: If any of the errors are false positives, please report
      them to the maintainers.

Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages.

[ioannisg]

What is the security domain of the added board definition? Looks like the SoC has TrustZone-M so the options are

• default (implying Secure domain)
• non-secure (in that case you need to set CONFIG_TRUSTED_EXECUTION_NONSECURE)

[erwango]

@ioannisg , @MaureenHelm, thanks for the reviews and guidance. I've updated the changes.

[MaureenHelm]

Looks fine except for the west.yml update

[FRASTM]

commit msg
Add support for stm32l5 socs on stm32 external interrupts driver

[erwango]

commit msg
Add support for stm32l5 socs on stm32 external interrupts driver

@FRASTM Fixed, txs

[FRASTM]

could have a line in the file header too (MP1 seems not here though)
STM32F0/STM32L0/STM32L4/STM32L5/STM32G0/STM32G4: Lines 0 to 15. Lines > 15 are not mapped on an IRQ

[erwango]

could have a line in the file header too (MP1 seems not here though)
STM32F0/STM32L0/STM32L4/STM32L5/STM32G0/STM32G4: Lines 0 to 15. Lines > 15 are not mapped on an IRQ

Done

[ioannisg]

Together with ARM_MPU, I believe you would need to enable ARM_TRUSTZONE_M option, if you ever would like to run a Zephyr firmware explicitly "secure-aware", i.e. with TRUSTED_EXECUTION_SECURE=y. If you don't wish that, then it's ok to not enable ARM_TRUSTZONE_M

[ioannisg]

This is not a SoC-capability option and needs to be enabled in the Board defconfig (if required)

removing -1

[ioannisg]

@erwango I had a look, and removed my -1 on this, to make it go in for v2.3, but, I am confused regarding the objectives here: I see a single board target, now (a single defconfig). This target does not enable any of TRUSTED_EXECUTION_SECURE or _NONSECURE, so when building Zephyr , is this desirable?

I was more thinking you would like to have 2 board targets, here, one "default" to be used for zephyr test suites, and one strictly "non-secure", to build Zephyr as a Non-Secure RTOS (i assumed the latter would need TRUSTED_EXECUTION_NONSECURE=y, but if you managed to set the whole thing up without this need, then I 've got no objections. BTW, the "double board target" is used, now, for nRF, Musca, and MPS2 platforms, see respective board definitions ).