hal_nxp: move multicore middleware to mcux-sdk-ng integration#102186
Conversation
|
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_nxp
DNM (manifest)
zephyrbot
requested review from
Holt-Sun,
JiafeiPan,
MaochenWang1,
PetervdPerk-NXP,
ZhaoxiangJin,
bperseghetti,
manuargue,
mmahadevan108 and
zejiang0jason
|
Depends on #102016, so the failures are expected for now. |
axelnxp
force-pushed
the
upstream/integrate_mcuxsdk_multicore_ng
branch
from
3138f1b to
5d4c219
Compare
axelnxp
force-pushed
the
upstream/integrate_mcuxsdk_multicore_ng
branch
from
5d4c219 to
5b57eff
Compare
It has been merged. |
axelnxp
force-pushed
the
upstream/integrate_mcuxsdk_multicore_ng
branch
from
5b57eff to
217c1c6
Compare
github-actions
bot
removed
the
DNM (manifest)
|
Move the multicore middleware to the new mcux-sdk-ng integration from hal_nxp, instead of using the legacy integration method. This will allow for easier integration of future releases. Signed-off-by: Axel Le Bourhis <axel.lebourhis@nxp.com>
|
@ZhaoxiangJin , can you take a look at this PR. |
| MAC interface. | ||
|
|
||
| config NXP_MULTICORE | ||
| bool "NXP Multicore Manager support" |
There was a problem hiding this comment.
Should we have two separate configuration parameters, one for mcmgr and another one for rpmsg-lite?
There was a problem hiding this comment.
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.
| If enabled, the NBU firmware used by the device will be use the 802.15.4 | ||
| MAC interface. | ||
|
|
||
| config NXP_MULTICORE |
There was a problem hiding this comment.
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.
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).
8 participants
Move the multicore middleware to the new mcux-sdk-ng integration from hal_nxp, instead of using the legacy integration method. This will allow for easier integration of future releases.