Zephyr: tests/arch/arm/arm_thread_swap failed on frdm_k64f board.

[chen-png]

Describe the bug
arch.arm.swap.common.no_optimizations and arch.arm.swap.common.fp_sharing.no_optimizations test cases failed on frdm_k64f board, there is nothing output int the handler.log.

To Reproduce
Steps to reproduce the behavior:

1. sanitycheck -p frdm_k64f --device-testing --device-serial /dev/ttyACM0
   -T tests/arch/arm/arm_thread_swap
2. See error and the handler.log

Screenshots or console output
sanitycheck -p frdm_k64f --device-testing --device-serial /dev/ttyACM0
-T tests/arch/arm/arm_thread_swap
Renaming output directory to /home/ztest/work/zephyrproject/zephyr/sanity-out.2
JOBS: 40
Building initial testcase list...
4 test configurations selected, 0 configurations discarded due to filters.
Adding tasks to the queue...

frdm_k64f tests/arch/arm/arm_thread_swap/arch.arm.swap.common.no_optimizations FAILED: N/A

    see: sanity-out/frdm_k64f/tests/arch/arm/arm_thread_swap/arch.arm.swap.common.no_optimizations/handler.log

total complete: 2/ 4 50% skipped: 0, failed: 1
frdm_k64f tests/arch/arm/arm_thread_swap/arch.arm.swap.common.fp_sharing.no_optimizations FAILED: N/A

    see: sanity-out/frdm_k64f/tests/arch/arm/arm_thread_swap/arch.arm.swap.common.fp_sharing.no_optimizations/handler.log

total complete: 4/ 4 100% skipped: 0, failed: 2
2 of 4 tests passed (50.00%), 2 failed, 0 skipped with 0 warnings in 121.41 seconds
In total 4 test cases were executed on 1 out of total 212 platforms (0.47%)

Hardware distribution summary:

frdm_k64f (None): 4

Environment (please complete the following information):

• OS: Fedora28
• Toolchain: Zephyr-sdk-0.10.3
• Commit ID: 02977563

[ioannisg]

Need to investigate why the no-optimizations' test is failing, but I assume the regular test is still passing, @chen-png right?

[ioannisg]

Adding low as this is seems to be specific to FRDM-board. Test passes on nRF platforms, and QEMU

[chen-png]

Need to investigate why the no-optimizations' test is failing, but I assume the regular test is still passing, @chen-png right?

yes, the regular tests can pass, but if with the CONFIG_NO_OPTIMIZATIONS, it failed.

[pabigot]

FYI: hello_world fails on frdm_k64f when CONFIG_NO_OPTIMIZATIONS is enabled. There's a segfault in nxp_mpu.c at line 103 within region_init. AFAICT this also failed at v2.0.

[dleach02]

I'm not able to reproduce this. Both the hello world commented on by @pabigot and the actual test case. @chen-png can you confirm if this problem is still occurring for you?

(tagging @MaureenHelm )

[chen-png]

yes, it still failed with latest commit 5c603d9ed.

[ioannisg]

Yeap, still failing for me as well.

[dleach02]

Dang, I hate not being able to reproduce... 👎

[ioannisg]

Dang, I hate not being able to reproduce... 👎

@dleach02 are you using CONFIG_NO_OPTIMIZATIONS=y?

[dleach02]

yes I did... I'll go through it again to verify I didn't fat finger something.

[dleach02]

Okay. I see the failure on arm_thread_swap. Debugging now

[dleach02]

The bug is that when reprogramming an NXP MPU descriptor, the hardware clears the valid bit for that memory region when the code writes the start address, end address, and attribute descriptor registers. If this memory area is accessed during this time it is invalid a memory fault occurs.

In this particular bug, the code in arch/arm/core/aarch32/cortex_m/mpu/nxp_mpu.c:mpu_configure_dynamic_mpu_regions() attempts to do a temporary mapping of all of RAM before applying the new set of memory maps. The function region_init() does the actual programming of the MPU descriptor registers and when the CONFIG_NO_OPTIMIZATIONS is set, the compiler generated code for region_init() uses locations on the program stack to store the local variables used to write the MPU descriptor. If the stack memory is in the descriptor being updated, the first write to the descriptor will clear the valid bit and the next read of the stack stored variable to write the next descriptor register will result in a memory fault.

At initial startup of the system, the first dynamic MPU descriptor is the only descriptor set to all of RAM. The code attempts to "reset" this descriptor to all of memory again causing the fault. A PR is being prepared which changes the temporary remapping of RAM to use the last of the dynamic descriptors to avoid this sequence.

[ioannisg]

Great explanation @dleach02 and agree also with setting to Medium severity