Move hal_nxp glue code to zephyr repo

[ZhaoxiangJin]

This PR has been implemented:

1. Move the hal_nxp glue code from the external module repo to the Zephyr repo.
   Moving the glue layer to the Zephyr repo can reduce the number of repositories that need to be touched when supporting new devices/drives, making it easier for the development process.
2. Adopt the MCUXSDK NG (next generation) to hal_nxp.
   The MCUXSDK NG introduced CMake to organize files and Kconfig to resolve dependencies. Adopting MCUXSDK NG to hal_nxp will reduce the effort of introducing new drivers and devices to Zephyr, as it can directly leverage the CMake infrastructure in SDK NG.

Two integration method compare

Original integration method:
The original integration method uses CMake to add SDK code to Zephyr, it is based on modified SDK 2.0 driver CMake. When developers need a driver, they first need to add this CMake file first. Take adc16 driver as an example, the adc16 cmake content is like below.

#Description: ADC16 Driver; user_visible: True
include_guard(GLOBAL)
message("driver_adc16 component is included.")

target_sources(${MCUX_SDK_PROJECT_NAME} PRIVATE
    ${CMAKE_CURRENT_LIST_DIR}/fsl_adc16.c
)

target_include_directories(${MCUX_SDK_PROJECT_NAME} PUBLIC
    ${CMAKE_CURRENT_LIST_DIR}/.
)

include(driver_common)

When Zephyr needs adc16 driver, a Kconfig configuration ADC_MCUX_ADC16 is enabled, then add the following code to the glue code to include the adc16 driver.
include_driver_ifdef(CONFIG_ADC_MCUX_ADC16 adc16 driver_adc16)

New integration method:
SDK NG uses Kconfig and CMake to add driver in project, which is similar with Zephyr. The architecture is:
Device’s Kconfig defines IP Kconfig options, which indicates the device supported features. For example, define MCUX_HW_IP_DriverType_ADC16 if the device has ADC16.
Driver’s Kconfig defines two Kconfig options MCUX_HAS_COMPONENT_driver.xxx and MCUX_COMPONENT_driver.xxx. The driver dependency is handled in this layer. For example, fsl_adc16.c needs fsl_common.c, so MCUX_COMPONENT_driver.adc16 selects MCUX_COMPONENT_driver.common.

   config MCUX_HAS_COMPONENT_driver.adc16
       bool
       default y if MCUX_HW_IP_DriverType_ADC16
   
   config MCUX_COMPONENT_driver.adc16
       bool "Use driver adc16"
       select MCUX_COMPONENT_driver.common
       depends on MCUX_HAS_COMPONENT_driver.adc16

Driver’s CMakeLists.txt adds source code and include path, based on Kconfig selection.

   if(CONFIG_MCUX_COMPONENT_driver.adc16)
       mcux_component_version(2.3.0)

       mcux_add_source(SOURCES fsl_adc16.c fsl_adc16.h)

       mcux_add_include(INCLUDES .)

   endif()

More details see CMakeLists.txt and Kconfig.

The new integration method will only use the SDK NG CMake files. If the Zephyr side needs the adc16 driver, just add the following code to glue. Developers do not need to add the driver side CMake.

if (CONFIG_ADC_MCUX_ADC16)
  set(CONFIG_MCUX_COMPONENT_driver.adc16 ON)
endif()

Device enablement

Based on the new integration method, the device enablement in zephyr becomes easier.
Enabling a device requires the device header, device feature header, peripheral header and so on. All of these have been processed in the device CMakeLists,txt of SDK NG (see https://github.com/nxp-mcuxpresso/mcuxsdk-core/blob/release/24.12.00/devices/arm/device_header.cmake). We no longer need to add various device related cmakes to hal_nxp like the old integration method, we only need to add the following code in glue code (all devices are the same, so it only needs to be done once):

set(CONFIG_MCUX_COMPONENT_device.system ON)
set(CONFIG_MCUX_COMPONENT_device.CMSIS ON)

The glue code folder structure

modules/hal_nxp/
├── Kconfig          # Kconfig entry
├── CMakeLists.txt
├── imx
│   ├── CMakeLists.txt         # From original <hal_nxp_repo>/imx/CMakeLists.txt
│   └── Kconfig.imx             # From original <zephyr_repo>/moduels/Kconfig.imx
├── mcux
│   ├── Kconfig.mcux           # From original <zephyr_repo>/moduels/Kconfig.mcux
│   ├── CMakeLists.txt         # From original <hal_nxp_repo>/mcux/CMakeLists.txt
│   ├── hwmv1.cmake         # From original <hal_nxp_repo>/mcux/hwmv1.cmake
│   ├── mcux-sdk
│   │   └── CMakeLists.txt   # From original <hal_nxp_repo>/mcux/hal_nxp.cmake
│   └── mcux-sdk-ng
│       ├── CMakeLists.txt  #sdk_ng cmake entry
│       ├── components
│       │   └── CMakeLists.txt #sdk_ng component cmake file. Pull SDK component based on requirements and configuration.
│       ├── device
│       │   └── CMakeLists.txt #sdk_ng device cmake file. Pull SDK device based on requirements and configuration.
│       ├── drivers
│       │   └── CMakeLists.txt #sdk_ng driver cmake file. Pull SDK driver based on requirements and configuration.
│       └── middleware
│           ├── bt_controller.cmake   #From original <zephyr_repo>/moduels/hal_nxp/bt_controller/CMakeLists.txt
│           ├── CMakeLists.txt #sdk_ng middleware cmake file. Pull SDK middleware based on requirements and configuration.
│           └── usb_device_config.h  #From original <zephyr_repo>/modules/hal_nxp/usb/usb_device_config.h
└── s32
    ├── CMakeLists.txt       # From original <hal_nxp_repo>/s32/CMakeLists.txt
    └── Kconfig.nxp_s32    # From original <zephyr_repo>/moduels/Kconfig.nxp_s32

The hal_nxp code folder structure

The legacy sdk folder mcux-sdk is not changed, some files in this folder can be removed, such as cmsis_driver, and the devices which are supported by SDK NG.
The mcu-sdk-ng is copied from mcu-sdk, unused files are removed, such as documents, linker script and so on.
The mcux/middleware are improved so that they can be used by both legacy platforms and SDK NG platforms. If it is not necessary to support the legacy platforms, then SDK NG middleware in mcux/mcux-sdk-ng/middleware can be used.
Note: Devices supported in SDK NG may also use files in mcux-sdk/components, as these components have files that are not supported in SDK NG, such as rpmsg/fsl_adapter_rfimu.c.

mcux/
├── mcux-sdk     # For legacy platforms
│   ├── components
│   ├── devices
│   ├── drivers
│   ├── middleware
│   └── platform
├── mcux-sdk-ng  # For SDK NG platforms
│   ├── arch
│   ├── cmake
│   ├── components
│   ├── devices
│   ├── drivers
│   ├── middleware # SDK NG middleware
│   └── README
├── middleware # Middlewares support both legacy and NG platforms
│   ├── mcux-sdk-middleware-connectivity-framework
│   ├── mcux-sdk-middleware-multicore
│   ├── mcux-sdk-middleware-usb
│   ├── wifi_nxp
│   └── wireless

Why we still need the original hal_nxp.cmake (now is <zephyr_repo>/modules/hal_nxp/mcux/mcux-sdk/CMakeLists.txt)?

The SDK NG does not support legacy devices like MK64F12, MKE16F16 and some APs like MIMX9352_A55 and MIMX8UD7_ADSP. So, these devices still need to be run through hal_nxp.cmake.
A simple load structure diagram is shown below:

[zephyrbot]

The following west manifest projects have changed revision in this Pull Request:

Name	Old Revision	New Revision	Diff
hal_nxp	zephyrproject-rtos/hal_nxp@605560a	zephyrproject-rtos/hal_nxp#501	zephyrproject-rtos/hal_nxp#501/files

⛔ DNM label due to: 1 project with PR revision

Note: This message is automatically posted and updated by the Manifest GitHub Action.