Let's look at an example of the ordering of device accesses. Our sequence of instructions goes like this. We have five load instructions, all loading 32 bits. First, we're loading from region A and then from region B, and then from A plus A. This is also from region A and then from region C, and then from region B again. On the right side of the memory map we see region A being nGnRnE the most restrictive type of device region, then we have region B as GRE, which is the least restrictive type, and we have C which is also nGnRnE, same as region A. The questions to think about is what the access is if happening in program order can be ordered or have to be ordered in respect to each of the other accesses. The first question we must ask is the first instruction, LDR r0, A, and the second instruction, LDR r1, B, are they ordered in respect to each other? Can the second instruction happen before the first instruction? The answer is actually yes. The CPU is able to see that these are two separate device regions indicated because they have two different device memory types. Obviously, the CPU is able to see that these are two separate regions, and then ordering between two different device regions don't have to be guaranteed. Think of it as this way. If I have UART, I must send out hello world, for this UART to work correctly, I have to ensure that the letter H is said before the letter E is sent before the letter L and L and O, etc. Otherwise, if no ordering is guaranteed to this device region, then our message will be jumbled. Let's consider device region B to be just a blinky light. We just want to toggle that on and off every once in a while. In respect to each other, it doesn't really matter would the blinky light turns on in respect to what I'm printing out to the UART. They're unrelated to each other. They are two different device regions, so ordering doesn't have to be guaranteed. What about the first instruction to the third instruction, LDR r2, A plus 8. Ordering has to be guaranteed between the first instruction and the third instruction, in that it has to happen in program order because this is to device region A, which is marked as no reordering allowed. What about the second instruction to the last instruction? LDR r1, B, and then LDR r4, B plus 8. Ordering does not have to be guaranteed because this is to a region that's allowing for reordering. The trickiest situation is to discuss whether the first instruction, LDR r0, A, accesses to device region A has to be in program order to device region C, the second to last instruction, LDR r3, C. This is implementation to find whether the accesses to region A will occur in program order with respect to access to region C. In some implementations, if the device regions have hardware support in that the CPU is able to tell that these are two different peripheral ports, then yes, A will not need to be ordered with respect to each other. However, in other implementations where it cannot distinguish between one and the other because they have the same exact attribute, then they will all fortunately have to be ordered in respect to each other, even though they're technically different device regions. To summarize this section, device nGnRnE is the strongest memory type, and device GRE is the weakest of the device memory types. Access rules for stronger memory are still legal for the weaker memory types. In other words, if a device GRE memory is treated with non-gathering, non-reordering none early right now often, technically, this is still correct, although it may not be as efficient as you wanted it to be. It is possible for a V8M implementation to treat or to use the same behavior for different memory types. For example, to treat all four device memory types as always, nGnRnE regardless of how you mark them. However, as long as your software can specify the weakest type necessary for the correct operation, if the implementation allows for it, it will treat it however it's marked. Otherwise, it's technically correct to treat everything as nGnRnE and still have the actual correct behavior.
