-
Notifications
You must be signed in to change notification settings - Fork 9k
hal_nxp: move multicore middleware to mcux-sdk-ng integration #102186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -93,6 +93,11 @@ config NXP_IEEE802154_MAC | |
| If enabled, the NBU firmware used by the device will be use the 802.15.4 | ||
| MAC interface. | ||
|
|
||
| config NXP_MULTICORE | ||
| bool "NXP Multicore Manager support" | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we have two separate configuration parameters, one for mcmgr and another one for rpmsg-lite?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah I wasn't sure. I preferred going with the "reduced" approach since for now, the supported platforms will select both anyway (W71, W72). I would let @TomasGalbickaNXP split it if needed at some point. |
||
| help | ||
| Includes NXP Multicore Manager support. | ||
|
|
||
| endif # HAS_MCUX | ||
|
|
||
| config BT_NXP_PCM_PINS_DIR_REVERSE | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,14 @@ | ||
| if(CONFIG_NXP_MULTICORE) | ||
| set(CONFIG_MCUX_COMPONENT_middleware.multicore.mcmgr ON) | ||
| set_variable_ifdef(CONFIG_SOC_MCXW716C CONFIG_MCUX_COMPONENT_middleware.multicore.mcmgr.mcxw716) | ||
| set_variable_ifdef(CONFIG_SOC_MCXW727C_CPU0 CONFIG_MCUX_COMPONENT_middleware.multicore.mcmgr.mcxw727) | ||
|
|
||
| set(CONFIG_MCUX_COMPONENT_middleware.multicore.rpmsg-lite ON) | ||
| set(CONFIG_MCUX_COMPONENT_middleware.multicore.rpmsg-lite.zephyr ON) | ||
| set_variable_ifdef(CONFIG_SOC_MCXW716C CONFIG_MCUX_COMPONENT_middleware.multicore.rpmsg-lite.mcxw71x) | ||
| set_variable_ifdef(CONFIG_SOC_MCXW727C_CPU0 CONFIG_MCUX_COMPONENT_middleware.multicore.rpmsg-lite.mcxw72x) | ||
|
|
||
| add_subdirectory(${MCUX_SDK_NG_DIR}/middleware/mcuxsdk-middleware-multicore | ||
| ${CMAKE_CURRENT_BINARY_DIR}/mcuxsdk-middleware-multicore | ||
| ) | ||
| endif() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need a new kconfig? Can't we directly include the multicore manager in multicore.cmake based on the SoC/NBU kconfig?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I discussed this with @mmahadevan108, the idea is to avoid having to update multicore.cmake every time we add a new platform. Using a kconfig like this makes it transparent, the platform just has to select the kconfig.
I agree it's only half true, because we still have to select the multicore platform port depending on CONFIG_SOC_xxx, so still need to update multicore.cmake, but it's reduced maintenance (1 line to add).
Moreover, if we keep using the "based on SoC kconfig" approach, this file will just grow and duplicate the same logic for every platform (this applies to other middlewares too).