I am using Omap3515 (Arm Cortex A8). Enabled I-Cache, D-Cache, Branch Prediction and MMU.
I am getting a data abort, if I try to copy a frame buffer of 600KB from an external memory region to another external memory region. After the data abort, I could notice that the SDR i.e SDRAM is not accessible.
I have enabled MMU in such a way that PA=VA.
There is no issue if I copy less amount data.
And also, If I disable D-Cache then there is no abort and it works fine. But I would like to enable D-Cache for faster access.
Thanks and regards,
Gopu
yasuhikokoumoto wrote: Although you had made all areas of memory space cacheable, it had been erroneous.
yasuhikokoumoto wrote:
Although you had made all areas of memory space cacheable, it had been erroneous.
Good catch! I hadn't brought myself to read through that long assembly listing yet. (The lack of comments in the original translation table setup code also doesn't help readability) Making peripherals cacheable is definitely a recipe for disaster.
To answer your earlier question of why I posted my mmu setup example: surely you must agree that doing this in C, and using reasonably descriptive constants, is much more readable and maintainable than doing the same in assembly?
Personally, the only initialization I perform in my assembly entrypoint is the processor mode, vector base, system control register, and stack pointer. At that point I jump to C code and perform the remaining initialization there (with the occasional inline assembly where needed e.g. for accessing coprocessor registers; regrettably GCC doesn't yet have intrinsics for that like Clang does).
The opinion which peripheral areas should be the device type may exist, but I don't recommend it because such areas become buffer-able.
Device and strongly-ordered are both valid choices in my opinion, depending on the relative value placed on performance versus less worry about memory ordering issues.
(A point maybe worth mentioning is that many TI SoCs (including the omap3) also have one or more DSP cores, which do not have the concept of strongly-ordered memory at all, so any code that relies on it will be more problematic to port to those, if that desire ever arises.)