MCXW71 base enablement #77434
MCXW71 base enablement #77434
Conversation
|
The following west manifest projects have been modified in this Pull Request:
Note: This message is automatically posted and updated by the Manifest GitHub Action. |
zephyrbot
added
manifest
manifest-hal_nxp
DNM
| # SPDX-License-Identifier: Apache-2.0 | ||
| # | ||
|
|
||
| zephyr_library() |
decsny
force-pushed
the
feature/mcxw_base_enable
branch
3 times, most recently
from
2683b5f
to
cf82d04
Compare
zephyrbot
added
platform: NXP
zephyrbot
requested review from
butok,
danieldegrasse,
dbaluta,
DerekSnell,
EmilioCBen,
gmarull,
manuargue,
MarkWangChinese,
nordic-krch and
yvanderv
dts/arm/nxp/nxp_mcxw71.dtsi
Outdated
| }; | ||
| }; | ||
|
|
||
| fast_peripheral: peripheral@58000000 { |
There was a problem hiding this comment.
I'm confused here- why define fast_peripheral and peripheral? Are there peripherals that can be declared under fast_peripheral and peripheral? If not, why not just define all the peripherals under peripheral- it seems like we only need the ranges property for secure vs nonsecure mode.
There was a problem hiding this comment.
right now there isn't a practical reason, the purpose had nothing to do with the ranges property, it's just because according to the RM these are different peripheral buses with different sets of masters who can access them so I just felt it might be useful for something down the line to capture this aspect of the hardware in DT
There was a problem hiding this comment.
I'd prefer we group these, unless there's a strong reason not to. That will make the nonsecure definition of this part a little simpler, and is consistent with our other M33 SOCs.
There was a problem hiding this comment.
ok, I was thinking the cortex-m3 DTS would then be able to delete the &fast_peripheral bus node to have an accurate DT since it can't access that bridge but it looks like in the public RM it says even though the radio subsystem is documented pretty well and is very flexible, that the firmware programmed to the radio NBU is intended to be developed by NXP ? so maybe we don't want to support the M3 target for this chip on zephyr anyways, so we can pretend that there is not two peripheral bridges for the DT if it's that important
There was a problem hiding this comment.
Ah, that is quite a good reason. I'm fine to keep it as is then
There was a problem hiding this comment.
i'll just change it for now because I don't think we will have the m3 target any time soon, if ever
There was a problem hiding this comment.
FYI, On W71, the m3 target is not supposed to be open, so we shouldn't consider it as a target for zephyr.
It will be different on W72, where the NBU will run on a CM33+nodsp+nofpu and will be open.
decsny
force-pushed
the
feature/mcxw_base_enable
branch
2 times, most recently
from
627b09d
to
c87d238
Compare
decsny
force-pushed
the
feature/mcxw_base_enable
branch
from
a3178ef
to
505e6f4
Compare
Add driver for newer SCG clock control peripheral. Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Add support for SCG K4 clock control in kinetis pinctrl. Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Add SOC DTS for MCXW71. Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Add MCXW71 SOC, which inherits some qualitiies of kinetis heritage platforms. Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Add FRDM-MCXW71 initial board. Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Add support for flash_k4 api from the mcux SDK. Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Enable flash controller driver for main FMU on MCXW71 Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
decsny
dismissed stale reviews from dleach02, EmilioCBen, and danieldegrasse
via
89a6518
decsny
force-pushed
the
feature/mcxw_base_enable
branch
from
505e6f4
to
89a6518
Compare
decsny
requested review from
dleach02,
danieldegrasse,
EmilioCBen and
axelnxp
MCXW71 SOC base enablement