Add RT700 basic environment support #79376
Conversation
zephyrbot
added
area: Clock Control
area: GPIO
platform: NXP
zephyrbot
requested review from
butok,
danieldegrasse,
dbaluta,
decsny,
DerekSnell,
EmilioCBen,
gmarull,
henrikbrixandersen,
manuargue,
MarkWangChinese,
mnkp,
nordic-krch and
yvanderv
|
The following west manifest projects have changed revision in this Pull Request:
⛔ DNM label due to: 1 project with PR revision Note: This message is automatically posted and updated by the Manifest GitHub Action. |
zephyrbot
added
manifest
manifest-hal_nxp
DNM
lucien-nxp
force-pushed
the
add_rt700_baseline_support
branch
from
aebb39a to
a8fc58d
Compare
boards/nxp/mimxrt700_evk/mimxrt700_evk_mimxrt798s_cpu1_defconfig
Outdated
Show resolved
Hide resolved
boards/nxp/mimxrt700_evk/mimxrt700_evk_mimxrt798s_cpu1_defconfig
Outdated
Show resolved
Hide resolved
boards/nxp/mimxrt700_evk/mimxrt700_evk_mimxrt798s_cpu0_defconfig
Outdated
Show resolved
Hide resolved
| config XSPI_CONFIG_BLOCK_OFFSET | ||
| hex "XSPI config block offset" | ||
| default 0x0 | ||
| help | ||
| XSPI configuration block consists of parameters regarding specific | ||
| flash devices including read command sequence, quad mode enablement | ||
| sequence (optional), etc. The boot ROM expects XSPI configuration | ||
| parameter to be presented in serial nor flash. |
There was a problem hiding this comment.
Does this make sense for DTS? It is a software setting for the offset of the XSPI configuration block, which will then be used by the bootrom to configure the XSPI to interface with an external flash device and execute from it
There was a problem hiding this comment.
There is no sense for dts. However, we need to use this kconfig to control config block offset in linker files to ensure the offset of the original block. https://github.com/zephyrproject-rtos/zephyr/pull/79376/files#diff-cbd91422112af1d51aabad377aa1a1a360111671c45cca2a795ea0c220e08cdb:~:text=.%20%3D%20CONFIG_XSPI_CONFIG_BLOCK_OFFSET%3B
There was a problem hiding this comment.
@nordicjm Devicetree, as per spec, is meant to be consumed by client program. In this case you can think of the zephyr OS as client program. No software in the Zephyr OS will interact with or consume this config block. It is used by the chip boot ROM, and we only need this offset so we can link it to the proper place in the image in order for the chip to boot. I.e., this config block will be consumed even before the zephyr reset handler like z_arm_reset runs. I don't think it needs to be in DTS.
There was a problem hiding this comment.
I guess it falls between the cracks. Will ask for @gmarull's opinion
|
@lucien-nxp , board testing on RT700 works fine now. and RTxxx hello_world works as well.. |
lucien-nxp
force-pushed
the
add_rt700_baseline_support
branch
from
c7552d8 to
bdda482
Compare
|
Only rebase to the newest node to resolve the west.yml conflict. |
1 similar comment
|
Only rebase to the newest node to resolve the west.yml conflict. |
lucien-nxp
force-pushed
the
add_rt700_baseline_support
branch
from
bdda482 to
91730dd
Compare
|
Only rebase to the newest node to resolve the west.yml conflict. |
There was a problem hiding this comment.
You may preview your board documentation in CI
https://builds.zephyrproject.io/zephyr/pr/79376/docs/boards/index.html#name=700
https://builds.zephyrproject.io/zephyr/pr/79376/docs/boards/nxp/mimxrt700_evk/doc/index.html
lucien-nxp
force-pushed
the
add_rt700_baseline_support
branch
from
91730dd to
a4c09d5
Compare
lucien-nxp
force-pushed
the
add_rt700_baseline_support
branch
from
a4c09d5 to
f6e2758
Compare
track rt700 sdk files update PR branch Signed-off-by: Lucien Zhao <[email protected]>
add rt7xx files related to soc support basic clock enablement add common/Kconfig.xspi_xip file Signed-off-by: Lucien Zhao <[email protected]>
add RT7xx dts files add iocon/gpio/flexcomm/clock instances in dts Signed-off-by: Lucien Zhao <[email protected]>
add nxp,xspi-device.yaml add nxp,xspi-mx25um51345g.yaml add nxp,xspi.yaml Signed-off-by: Lucien Zhao <[email protected]>
add more flexcomm instances clock support to adapt rt700 instances number add xspi clock support Signed-off-by: Lucien Zhao <[email protected]>
Define iocon array to store iocon base address add index parameter support to support multi iocon instances Signed-off-by: Lucien Zhao <[email protected]>
use clang-format to format gpio_mcux file Signed-off-by: Lucien Zhao <[email protected]>
update gpio driver to adapt rt7xx gpio model: 1. There is no PORT_Type on RT7xx,so set PORT_Type as void 2. Add port_no parameter in gpio_mcux_config to adapt IOPCTL driver 3. Add gpio-port-offest parameter in blinding, it will help map the relation between index n and gpio port when some soc have domain access attribution. 3. Splite gpio_mcux_configure function into two functions( gpio_mcux_iopctl_configure and gpio_mcux_port_configure) according to CONFIG_PINCTRL_NXP_IOCON macro 4. Add code to adapt RT700 GPIO attribute configuration Signed-off-by: Lucien Zhao <[email protected]>
add files related to mimxrt700_evk board add gpio/uart function support on board Signed-off-by: Lucien Zhao <[email protected]>
The number of mpu regions that can be configured is less than four cases. Therefore, only remove this case on cm33 cores, failed log show below: "num_parts of 4 exceeds maximum allowable partitions (3)" Signed-off-by: Lucien Zhao <[email protected]>
lucien-nxp
force-pushed
the
add_rt700_baseline_support
branch
from
f6e2758 to
be5c1bb
Compare
|
Only rebase to the newest commit on main branch and resolve the west.yml conflicts. |
There was a problem hiding this comment.
This file is basically the same as the flexspi xip kconfig file except that the compatible we are working with is just different. I wonder if there could be a common file instead like Kconfig.spi_xip, which can just use the same code but set the relevant compatible differently ? then we don't need to make similar changes in two places. If you think this would be too complex and don't want to attempt this then it's fine but I think there might be a missed opportunity here
There was a problem hiding this comment.
Yes, I agree your point. However, I think I should do this later than this PR merged, and then inform hake to test all the platforms affected by this change.
There was a problem hiding this comment.
I agree with Declan. This extra file does not seem needed and we should be able to add the required changes to the current Kconfig file. We need to add a tracking JIRA issue so we don't miss deleting this file if this is not being addressed as part of this PR.
| config XSPI_CONFIG_BLOCK_OFFSET | ||
| hex "XSPI config block offset" | ||
| default 0x0 | ||
| help | ||
| XSPI configuration block consists of parameters regarding specific | ||
| flash devices including read command sequence, quad mode enablement | ||
| sequence (optional), etc. The boot ROM expects XSPI configuration | ||
| parameter to be presented in serial nor flash. |
There was a problem hiding this comment.
@nordicjm Devicetree, as per spec, is meant to be consumed by client program. In this case you can think of the zephyr OS as client program. No software in the Zephyr OS will interact with or consume this config block. It is used by the chip boot ROM, and we only need this offset so we can link it to the proper place in the image in order for the chip to boot. I.e., this config block will be consumed even before the zephyr reset handler like z_arm_reset runs. I don't think it needs to be in DTS.
| - name: cm33_cpu1 | ||
| - name: hifi1 | ||
| - name: hifi4 |
There was a problem hiding this comment.
Would make sense to add them when support is added to keep things properly bisectable and minimal.
There was a problem hiding this comment.
So I need to remove hifi1 and hifi4 core provisionally, right? and add back once hifi core supported?
There was a problem hiding this comment.
Yes, doesn't make sense to be able to select a core in the build system that is impossible to use but will be listed as supported for a given board
There was a problem hiding this comment.
@lucien-nxp, please remove the cores that are not enabled yet on this platform.
|
@nordicjm can you summarize what is needed to clear your change request? I'm having a hard time going through the comments in this PR to identify what @lucien-nxp needs to do to wrap this up. |
This outstanding part here has been waiting for an update: #79376 (comment) |
support gpio/uart function