Add support for S32K148 SoC

[marcin-wierzbicki]

Add support for S32K148 SoC.

Drivers enabled: SYSMPU, GPIO, PORT, LPUART, ADC, FlexCAN, FTM, RTC, LMEM, WDOG, ENET.

[mmahadevan108]

Have the changes to the SDK drivers sent to the SDK team? Here is the repo incase this has not been submitted to the SDK driver.
https://github.com/nxp-mcuxpresso/mcux-sdk

[marcin-wierzbicki]

Have the changes to the SDK drivers sent to the SDK team? Here is the repo incase this has not been submitted to the SDK driver. https://github.com/nxp-mcuxpresso/mcux-sdk

Thanks. We will take care of that (@KevShaju)

[marcin-wierzbicki]

@manuargue I managed to generate OsIf, clocks, and SoC related code using S32DS IDE with support for S32K1 + RTD for S32K1. Please, check.

@manuargue BTW If someone needed to adjust the configuration in the future, would they follow the same steps, or is there a recommended approach to ensure consistency? I’m wondering if there’s a way to make future modifications smoother, perhaps by retaining certain files as input or documenting key aspects of the process. I’d appreciate any thoughts you might have on this.

[manuargue]

@manuargue I managed to generate OsIf, clocks, and SoC related code using S32DS IDE with support for S32K1 + RTD for S32K1. Please, check.

please split the changes into separate commits, e.g.:

• adaptions to ADC headers
• adaptions to ENET headers
• adaptions to FlexCAN headers
• generated SoC HAL code
• patches over generated SoC HAL code
• MCUX device glue code

Kindly write a small mention in https://github.com/zephyrproject-rtos/hal_nxp/blob/master/s32/README#L40-L44 of all patches applied to the original HAL headers/sources, in each respective commit. Some of them, like FTM and FlexCAN patches, were already mentioned.

@manuargue BTW If someone needed to adjust the configuration in the future, would they follow the same steps, or is there a recommended approach to ensure consistency? I’m wondering if there’s a way to make future modifications smoother, perhaps by retaining certain files as input or documenting key aspects of the process. I’d appreciate any thoughts you might have on this.

Great question. Above approach of splitting commits and documenting patches will ease keeping track of changes over time and roll back if needed, and should help at some extent to understand how the sources were added. Using both the RTD and MCUX drivers for the S32 devices is quite challenging and so far NXP have been taking care of doing the bring up of new boards. We are looking for ways to streamline the process and eventually document it.

[marcin-wierzbicki]

@manuargue : please check

[manuargue]

Changes LGTM. NXP is discussing internally these changes. I'll get back to you as soon as there is a resolution.

[manuargue]

Merge branch 'zephyrproject-rtos:master' into s32k148_support_pr

Pls do not add merge commits (9ce54c0). Use rebase instead.
https://docs.zephyrproject.org/latest/contribute/contributor_expectations.html#pr-requirements