ARMV7 MMU : support of the NORMAL and memory-ordered memory type

[arnopo]

This PR fixes an Alignment fault issue encountered when running the /sample/net/zperf example
on an STM32MP135F-DK board that embeds a Cortex-A7.

uart:~$ 
*** Booting Zephyr OS build v4.2.0-4059-g7a2552dfaa6b ***
[00:00:02.335,000] <inf> net_config: Initializing network
[00:00:02.335,000] <inf> net_config: Waiting interface 1 (0xd00017e0) to be up...
[00:00:02.381,000] <inf> microchip_lan8742: PHY (0) Link speed 100 Mb, full duplex
[00:00:02.381,000] <inf> net_config: Interface 1 (0xd00017e0) coming up
[00:00:02.381,000] <inf> net_config: IPv4 address: 192.0.2.1
[00:00:02.381,000] <err> os: ***** DATA ABORT *****
[00:00:02.381,000] <err> os: Alignment Fault @ 0x2ffe000e
[00:00:02.381,000] <err> os: r0/a1:  0x2ffe000e  r1/a2:  0xd00658a0  r2/a3:  0x00000030
[00:00:02.381,000] <err> os: r3/a4:  0x00000060 r12/ip:  0x2ffe003e r14/lr:  0xc002b374
[00:00:02.381,000] <err> os:  xpsr:  0x8000011f
[00:00:02.381,000] <err> os: Faulting instruction address (r15/pc): 0xc000103c
[00:00:02.381,000] <err> os: >>> ZEPHYR FATAL ERROR 46: Unknown error on CPU 0
[00:00:02.381,000] <err> os: Current thread: 0xd00195d8 (tx_q[0])
[00:00:02.517,000] <err> os: Halting system
uart:~$ 

On this board, a memory region is defined and mapped in the MMU to store Ethernet descriptors and buffers. This memory must be non-cacheable because it is accessed by both the network library and the Ethernet peripheral DMA.

eth_ram: sram@30000000 {
    compatible = "zephyr,memory-region", "mmio-sram";
    reg = <0x2FFE0000 DT_SIZE_K(16)>;
    #memory-region-cells = <0>;
    zephyr,memory-region = "ETH_SRAM";
};

The issue occurs in net_pkt_cursor_operate(), where pkt_cursor_advance() returns 0xE,
resulting in a memcpy to address 0xd800000e, which is not aligned on a 32-bit word boundary.

The root cause is that the MMU sets the memory type to device if K_MEM_CACHE_NONE is set.
In this use case, I would need to register a normal, non-cacheable memory region since this region corresponds to RAM.

This pull request introduces the ability to select the memory type for MMU attributes.

Memory can then be registered using syntax like this:

/* Map memory region for DMA descriptor and buffer as non-cacheable */
k_mem_map_phys_bare(&desc_uncached_addr,
                    DT_REG_ADDR(ETH_DMA_REGION),
                    DT_REG_SIZE(ETH_DMA_REGION),
                    K_MEM_PERM_RW | K_MEM_DIRECT_MAP | K_MEM_CACHE_NONE |
                    K_MEM_CACHE_NONE_NORMAL);

[JarmouniA]

FYI, k_mem_map_phys_bare is not meant to be used outside the kernel.

zephyr/include/zephyr/kernel/internal/mm.h

Line 14 in 376ca57

* @defgroup kernel_mm_internal_apis Kernel Memory Management Internal APIs

[arnopo]

FYI, k_mem_map_phys_bare is not meant to be used outside the kernel.

zephyr/include/zephyr/kernel/internal/mm.h

Line 14 in 376ca57

* @defgroup kernel_mm_internal_apis Kernel Memory Management Internal APIs

I plan to use it in a driver (code not yet updated to add the new attribute):
https://github.com/zephyrproject-rtos/zephyr/pull/96134/files#diff-78c5174e6fbf6d69cc1adf736b37a209d4cdfba375e2fecd6bb96356c1914cb7R752-R759

[andyross]

Isn't there already a facility for per-platform mmu flag bits somewhere? Plumbing arch-specific details all the way out to the generic API usually causes headaches. If not, a quick change to add a facility (e.g. reserve the top N bits for the arch, etc...) might be a cleaner way to do this.

Also, pedantry: these really aren't "cache" related, they're alignment and ordering rules. It's surely true that they only makes sense for uncacheable regions, but introducing symbols named things like "CACHE_NONE_STRONGLY_ORDERED" seems needlessly confusing.

[arnopo]

Isn't there already a facility for per-platform mmu flag bits somewhere? Plumbing arch-specific details all the way out to the generic API usually causes headaches. If not, a quick change to add a facility (e.g. reserve the top N bits for the arch, etc...) might be a cleaner way to do this.

Also, pedantry: these really aren't "cache" related, they're alignment and ordering rules. It's surely true that they only makes sense for uncacheable regions, but introducing symbols named things like "CACHE_NONE_STRONGLY_ORDERED" seems needlessly confusing.

Reanalyzing the arm64 architecture, I should create a zephyr/arch/arm/arm_mem.h file instead of modifying the mm.h file. I will revisit the implementation with this approach.

[arnopo]

Also, pedantry: these really aren't "cache" related, they're alignment and ordering rules. It's surely true that they only makes sense for uncacheable regions, but introducing symbols named things like "CACHE_NONE_STRONGLY_ORDERED" seems needlessly confusing.

@andyross
Since K_MEM_ARM_NORMAL_NC is defined for arm64, I kept similar definitions for the ARM architecture, preserving the "non-cacheable" notion. Please let me know if you prefer that I remove NC from the definition names.

[arnopo]

Any advice, comments or reviews on this new version would be greatly appreciated.
This PR is currently blocking progress on #96134.
Thanks in advance for your time and support

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud