cnnblike

正确的做法可能是用 memremap ，用 dts+memremap 这样的形式会比较好点：

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841683/Linux+Reserved+Memory

memremap(r.start, resource_size(&r), MEMREMAP_WT);

@villivateur https://docs.kernel.org/driver-api/device-io.html
看一下这个，你需要的可能是 ioremap 或者 ioremap_nc

我仔细分析了一下你遇到的问题，感觉像是这样：
1. rk3588 这个问题是应该是因为那个页面被设置成了 write-back 而不是 write-through ，由于是闲时写，所以在你系统的内存总线空闲的时候会写入，然后叠加 wb 会在写入的时候刷 L1 ，更新另一个 cluster 的 L2 ，所以显得触发概率低，所以我建议你跑一个高内存总线开销的用户态程序，应该能让任务出问题

2. rk3568 的场合，你的页表上对这个页面可能没设置 SH ，看这里 https://zhuanlan.zhihu.com/p/532838098

@villivateur 我最近也在研究这块，有兴趣的话，记得把结论也发我一下

@villivateur
内存段和 shareable 的设置和 tlb 有关系，在内核的 mm 那块的逻辑里，具体说是 The arch/arm64/mm/cache-*.S 和 arch/arm64/mm/proc-*.S
还有一个可能性，我不知道你是用 mem=xxx MB 设置的内存还是用 reversed_memory 设置的内存，所以可能行为会有不同。

如果你用的 jailhouse 的话，他那个实现对大小 cluster 的支持可能是不对的，看此处注释：
https://github.com/siemens/jailhouse/blob/master/hypervisor/arch/arm64/entry.S#L453-L458

如果是 rk3568 或者是 rk3566 上的核间通信，因为内存不一致触发问题说实话可能性很低，按 arm 的定义（和推荐实现），单一一个 cluster 的所有核都在同一个 innershareable 上，理论上 cluster 内所有核能看到的，都是一样的。
如果是 rk3588 ，那是有可能的，我猜你把一个小核分出来跑 amp ，或者干脆是在 cortex-m 核上跑 amp 通信，那就触发缓存不一致了

@villivateur 不在一个 cluster 的情况不大可能说实话，你直接说 rk 什么型号吧
https://linaro-dev.linaro.narkive.com/f2kFnMmW/why-is-the-the-smp-mb-in-arm64-s-barrier-h-dmb-ish
”In Arm V8 Architecture Reference Manual£¬there is an example (see beblow) to explain the shareability attribute of clusters. It is easy to know: each cluster is corresponding to a Inner shareable domain; the two cluster comprise a Outer shareable domain.“

memory barrier 的官方文档在这里 https://developer.arm.com/documentation/ddi0406/cb/Application-Level-Architecture/Application-Level-Memory-Model/Memory-access-order/Memory-barriers?lang=en#Chddbigg

内核态的内存栅栏看这个 https://www.kernel.org/doc/Documentation/memory-barriers.txt
用户态开发看 std::memory_order