zephyr
zephyr copied to clipboard
zephyrproject-rtos
Introduce initial support for NXP S32Z27 SoC
This PR introduces initial support for NXP S32Z27 SoC (based on Cortex-R52), including:
- SoC and board support
- Shim drivers for UART (poll and interrupt-based APIs), GPIO (basic APIs), and Pinctrl
- Lauterbach TRACE32 West runner.
Currently is only possible to use Lauterbach TRACE32 West runner to load and execute a Zephyr application from internal SRAM. WIP to be addressed in future PR's: run from Flash, implement all GPIO APIs.
The updates for HAL NXP are in https://github.com/zephyrproject-rtos/hal_nxp/pull/182
The following west manifest projects have been modified in this Pull Request:
| Name | Old Revision | New Revision | Diff |
|---|---|---|---|
| hal_nxp | https://github.com/zephyrproject-rtos/hal_nxp/commit/708c95825b0d5279620935a1356299fff5dfbc6e | https://github.com/zephyrproject-rtos/hal_nxp/commit/3e3648526824cc5b52ab59d5dd308473e291b760 | zephyrproject-rtos/[email protected] |
Note: This message is automatically posted and updated by the Manifest GitHub Action.
Hello. I have tried to run the "hello_world" sample with the code from the PR and the associated code for hal_nxp. It compiles fine but while running the app I get the following behavior.
The program goes up to svc #_SVC_CALL_CONTEXT_SWITCH in swap_helper.S:916, which correctly leads to ldr pc, =z_arm_svc in vector_table.S:22, but instead of jumping to z_arm_svc it goes to ldr pc, =z_arm_undef_instruction in vector_table.S:21. And then instead of going to z_arm_undef_instruction it keeps executing that same line forever.
I am not using a Lauterbach debugger, but instead an NXP S32 Debug Probe with initialization scripts from S32 Design Studio. The PR states that only Lauterbach is usable, but I wanted to confirm if what I observed was expected.
Hi @ambroise-arm, thanks for the interest on this pr. The behavior you describe may be due to the Cortex-R52 cores on this SoC taking the exceptions to EL1 (SCTLR.TE bit) in T32 state, rather than in A32 state as Zephyr expects. We have changed the default value (CFGTHUMBEXCEPTIONS) in the Practice script (see https://github.com/zephyrproject-rtos/zephyr/pull/49161/files#diff-4da008b8b3f44849c808f4c4bdb4567dff5a5614f610b39bd0467adb247a53d4R130). You could try to do the same in your startup script by clearing CFG_CORE.THUMB bit and let me know the results. We are planning to add support for running in either T32 or A32 for Cortex-R52 after this pr gets merged.
I am not using a Lauterbach debugger, but instead an NXP S32 Debug Probe with initialization scripts from S32 Design Studio. The PR states that only Lauterbach is usable, but I wanted to confirm if what I observed was expected.
You are welcome to submit patches to support other debuggers after the initial support is merged. Adding support for NXP S32 Debug Probe support is in our plans as well.
I couldn't get the modification to work in my startup script, but I could modify SCTLR.TE at runtime with the debugger. That way the hello_world sample works for me. That's all I wanted to validate, thanks @manuargue!
I have rebased to fix the conflicts and updated the HAL on https://github.com/zephyrproject-rtos/hal_nxp/pull/182.
There seems to be unrelated failed builds for bl5340_dvk_cpuapp_ns. I'll wait for a fix in main to rebase again.
Btw, it would be great if this pr can make it before the code freeze next week :)
@galak, @mbolivar-nordic, can you two revisit your comments to determine if they have been addressed
@gmarull I've addressed your comments. Please resolve them if you consider them done.
@manuargue https://github.com/zephyrproject-rtos/hal_nxp/pull/182 HAL PR has been merged. Please update this PR to reflect the new SHA.
done @dleach02, unrelated failed tests should pass now
EDIT: well not yet, I've opened https://github.com/zephyrproject-rtos/zephyr/pull/51191 to fix the rest