Skip to content

Supporting User Mode on ARM Cortex-M Baseline #19689

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

Merged
merged 6 commits into from
Oct 18, 2019

Conversation

ioannisg
Copy link
Member

@ioannisg ioannisg commented Oct 8, 2019

Fixes #12961.

  • support for user mode on Cortex-M0+ (ARMv6-M)
  • adding MPU support on Nucleo G071RB SoC/Board
  • no HW stack protection (yet) on ARMv6-M! (we need serious changes to the fault handling for that)

The work has been tested (manually) on nucleo_g071rb board. Flashing this board with west/pyocd is currently broken (at least for me), so I have tested manually all the -t userspace tests; they are passing on the board.

There is no QEMU for Cortex-M0+ - nucleo_g071rb is the only CM0+ board with user mode support.

The added patches are completely isolated from Cortex-M0 port (i.e. simple ARMv6 without MPU) and Cortex-M Mainline port (v7m, v8m), i.e. there should be no impact on the other aRM ARCHes.

@ioannisg ioannisg requested a review from erwango October 8, 2019 13:06
@ioannisg ioannisg added the In progress For PRs: is work in progress and should not be merged yet. For issues: Is being worked on label Oct 8, 2019
@ioannisg ioannisg added this to the v2.1.0 milestone Oct 8, 2019
@ioannisg ioannisg force-pushed the nucleo_cortex_m0plus_mpu branch from 34da53a to cd35177 Compare October 8, 2019 15:19
@zephyrbot zephyrbot added the area: ARM ARM (32-bit) Architecture label Oct 8, 2019
@zephyrbot
Copy link
Collaborator

zephyrbot commented Oct 8, 2019

All checks are passing now.

Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages.

@ioannisg ioannisg force-pushed the nucleo_cortex_m0plus_mpu branch 11 times, most recently from 7dc3a2f to e31138e Compare October 14, 2019 08:24
@ioannisg ioannisg force-pushed the nucleo_cortex_m0plus_mpu branch 2 times, most recently from 03ff9e6 to acd3131 Compare October 14, 2019 12:02
@zephyrbot zephyrbot added area: Test Framework Issues related not to a particular test, but to the framework instead area: Kernel labels Oct 14, 2019
@ioannisg ioannisg force-pushed the nucleo_cortex_m0plus_mpu branch 3 times, most recently from 2577fe3 to a549446 Compare October 15, 2019 08:32
@ioannisg ioannisg force-pushed the nucleo_cortex_m0plus_mpu branch from a549446 to 4762c04 Compare October 15, 2019 13:38
@zephyrbot zephyrbot added the area: API Changes to public APIs label Oct 15, 2019
@ioannisg ioannisg added area: Userspace Userspace Feature A planned feature with a milestone and removed In progress For PRs: is work in progress and should not be merged yet. For issues: Is being worked on labels Oct 16, 2019
@ioannisg ioannisg force-pushed the nucleo_cortex_m0plus_mpu branch from 5fb8333 to e0abf95 Compare October 16, 2019 09:41
@ioannisg ioannisg marked this pull request as ready for review October 16, 2019 09:41
@ioannisg
Copy link
Member Author

@erwango I would appreciate if you could do some testing. Pls, run user mode tests on this board, and report your findings.

@ioannisg ioannisg requested a review from nashif October 16, 2019 09:48
@ioannisg ioannisg changed the title Nucleo cortex m0plus mpu Supporting User Mode on ARM Cortex-M Baseline Oct 16, 2019
@@ -52,6 +48,9 @@
#include <stm32g0xx_ll_usart.h>
#endif

/* Add include for DTS generated information */
#include <generated_dts_board.h>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we include this at the end of the file here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is standard for ARM SoCs. We first include vendor headers, followed by including DTS generated headers.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this way we prevent from having inclusion cycles.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this seems broken by design TBH
What does generated_dts_board.h pull in which requires it at the end of file and not the beginning?
And since nothing in the header uses the definitions, why is it pulled in here at all? Pulling in headers from other headers which aren't actually needed by the including header is what causes inclusion cycle problems

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I was not clear sorry. It can be anywhere in the file. The inclusions were caused by including kernel headers here. That's what I removed.
Just for consistency with other SOCs, I prefer to pull in the dts generated headers after the vendor headers but this should not matter.

We enable Memory Protection on stm32 nucleo_g071rb board,
since the respective SoC series implements the ARM MPU.

Signed-off-by: Ioannis Glaropoulos <[email protected]>
Remove the inclusion of kernel_includes.h from soc.h and replace
it with including the board-specific auto-generated headers. This
aligns the soc.h header with the current policy not to include
kernel headers in soc.h.

Signed-off-by: Ioannis Glaropoulos <[email protected]>
ARMv6-M architecture has an MPU that requires minimum region
size of 256 bytes.

Signed-off-by: Ioannis Glaropoulos <[email protected]>
We do not support HW Stack protection capabilities in
Cortex-M Baseline CPUs (unless they have built-in stack
overflow detection capability). We adapt the Kconfig
option to reflect this.

Signed-off-by: Ioannis Glaropoulos <[email protected]>
In this commit we implement the assembly functions in
swap_helper.S, namely
  - z_arm_pendsv()
  - z_arm_svc()
for ARMv6-M and ARMv8-M Baseline architecture. We "inline" the
implementation for Baseline, along with the Mainline (ARMv7-M)
implementation, i.e. we rework only what is required to build
for Baseline Cortex-M.

Signed-off-by: Ioannis Glaropoulos <[email protected]>
In this commit we implement the assembly functions in userspace.S
- z_arm_userspace_enter()
- z_arm_do_syscall()
- z_arch_user_string_nlen()
for ARMv6-M and ARMv8-M Baseline architecture. We "inline" the
implementation for Baseline, along with the Mainline (ARMv7-M)
implementation, i.e. we rework only what is required to build
for Baseline Cortex-M.

Signed-off-by: Ioannis Glaropoulos <[email protected]>
@ioannisg ioannisg force-pushed the nucleo_cortex_m0plus_mpu branch from e0abf95 to 0ef7752 Compare October 18, 2019 08:42
@galak galak merged commit cfe1b1d into zephyrproject-rtos:master Oct 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: API Changes to public APIs area: ARM ARM (32-bit) Architecture area: Boards area: Kernel area: Memory Protection area: Test Framework Issues related not to a particular test, but to the framework instead area: Tests Issues related to a particular existing or missing test area: Userspace Userspace Feature A planned feature with a milestone
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ARM Memory Protection functions not invoked in SWAP for ARMv6/ARMv8-M Baseline
6 participants