I tried to map a SRAM area, I add that area (from 0x700000000 to 0x70FFFFFF) to page table and set Memory Attribute Indirection Register as normal memory and cacheable.
But when I try to read thar area(from 0x700000000 to 0x70FFFFFF) I found it could not be cached. I should flush data cache after adding that area to page table.
Then I tried a DDR area, I found it is no need to flush data cache and I wanna to know why?
I can't fully answer your question without knowing a lot more about you've set up the system and what MemSetAttr() does. But a few thoughts...
First, what attributes have you set for the processor to use for table walks? (https://developer.arm.com/documentation/ddi0601/2022-06/AArch64-Registers/TCR-EL1--Translation-Control-Register--EL1-) Importantly, do they match what you've set in the translation tables for the virtual address region holding the translation tables? If they don't match, it might well be that you need to do some cache maintenance to ensure the updates are visible.
Next, do you have any barriers in the code? Data writes and MMU table walks are classed as different observers, and you have to use barriers to ensure correct ordering in some cases. The Arm ARM (rev I.a, K13.5.3) gives some examples. It might be that the DCache flush isn't actually fixing the problem, just changing the timing sufficiently that the problem is masked.
And, what was at the VA before you added the SRAM mapping? If it was not region marked as causing translation faults, then you'll also need to do some TLB maintenance.