The asker wants to validate DDR by writing a value then reading it back, mapping the page as Normal Non-Cacheable (Normal_NC) — a "write-combining" attribute commonly used for framebuffers and device memory. Their test code issues a store, a dsb sy, then a load, and they're trying to reason about whether the load is guaranteed to see DRAM (not a merge buffer) and whether the barrier is sufficient.

This question is interesting because Normal_NC sits in a confusing middle ground of the ARM memory model. Unlike Device memory, Normal_NC accesses can be gathered, merged, reordered, and speculatively prefetched — but they are not cached in L1/L2. So intuition from x86 WC memory only partially carries over.

Key technical points:

• Write merging buffers are not caches. A pending store in the CPU's write-combine buffer hasn't reached DRAM yet, even though there's no cache line. A subsequent load to the same address may be satisfied from the merge buffer (store-to-load forwarding), which defeats the purpose of "did it actually land in DDR?"
• dsb sy drains the write buffer to the point of coherency/serialization, but the architectural guarantee is that prior memory accesses are complete with respect to the shareability domain — not that they've physically reached the DRAM cell. For most SoCs the memory controller acknowledges the write before the DRAM array commits.
• Speculative reads on Normal memory are permitted, which means the read could be issued before the architectural sequence point unless ordered.

Direction for an answer:

• For DDR integrity testing (stuck bits, weak cells), you cannot rely on the CPU's load returning what hit DRAM. You need either (a) a cache/buffer-flush instruction sequence with sufficient delay or temperature stress, or (b) a memory controller scrubber / built-in self-test, or (c) accesses through a path that bypasses CPU buffering entirely (e.g., DMA engine reads).
• For ordering-only purposes, dsb sy between the store and load is the correct barrier; adding isb doesn't help (ISB is for context-synchronization, not data ordering).
• Mapping the region as Device-nGnRnE instead of Normal_NC would prevent gathering and merging, giving a much stronger "this store left the CPU" guarantee — at significant performance cost.

Gotchas: write-combining behavior is implementation-defined within architectural limits, so two different SoCs (even both ARMv8.2) can give different observable results for the same code. And on real hardware, the DDR controller's own write buffer and refresh cycles further blur "did it reach the cell."