Skip to content

Conversation

@MaureenHelm
Copy link
Member

Clearing fields in the region descriptor attributes doesn't always have
the expected effect of revoking permissions. In the case of bus master
supervisor mode fields (MxSM), setting to zero actually enables read,
write, and execute access.

When we reworked handling of region descriptor 0, we inadvertently
enabled execution from RAM by clearing the MxSM fields and enabling the
descriptor. This caused samples/mpu_test run to throw a usage fault
instead of an MPU-triggered bus fault.

Fix this by setting all the MxSM fields to 2'b11, which gives supervisor
mode the same access as user mode.

Signed-off-by: Maureen Helm [email protected]

Clearing fields in the region descriptor attributes doesn't always have
the expected effect of revoking permissions. In the case of bus master
supervisor mode fields (MxSM), setting to zero actually enables read,
write, and execute access.

When we reworked handling of region descriptor 0, we inadvertently
enabled execution from RAM by clearing the MxSM fields and enabling the
descriptor. This caused samples/mpu_test run to throw a usage fault
instead of an MPU-triggered bus fault.

Fix this by setting all the MxSM fields to 2'b11, which gives supervisor
mode the same access as user mode.

Signed-off-by: Maureen Helm <[email protected]>
@stephensmalley
Copy link
Contributor

+1 My tests pass with this change applied.

Copy link
Contributor

@mbolivar mbolivar left a comment

Choose a reason for hiding this comment

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

A-ha, thanks for the nice commit explanation! I was confused about why I was seeing usage faults on frdm_k64f when the errors looked related to memory access.

@galak
Copy link
Contributor

galak commented Jun 14, 2017

@mbolivar was in tree tests failing? Just curious if we need to expand or need a new test case.

@galak galak merged commit a8aa9d4 into zephyrproject-rtos:arm Jun 14, 2017
@mbolivar
Copy link
Contributor

@mbolivar was in tree tests failing? Just curious if we need to expand or need a new test case.
Revert

No, it happened while I was doing some mcuboot debugging while the MPU patches were going in. On frdm_k64f, the chain-loaded Zephyr image was usage faulting in the flash driver's system initialization routine at that time. IIRC, I was rebasing the out of tree flash write patches and hadn't gotten them right yet. Fixing those up let the system keep going.

I'll retest with MPU on, flash writes off, and this patch when I get around to pulling in upstream again and see if flash init MPU faults instead of usage faults.

@MaureenHelm MaureenHelm deleted the fix-mpu-ram-exe branch June 22, 2017 21:04
nagineni pushed a commit to nagineni/zephyr that referenced this pull request Nov 20, 2017
Stop using the event.value because it's unreliable because of button
bounce issues. Also, double edge interrupts are better used when the
same action will be triggered either way. Here a better approach to
make sure the lasers get turned off eventually is to check the button
status repeatedly in a timer. This makes it more like Spaceship1.js
but at least the lasers will turn on immediately, rather than syncing
to 250ms timer, which is important when you're leading a TIE fighter.

Signed-off-by: Geoff Gustafson <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants