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
Hi matthijs,
I cannot agree with you.
Note that device and strongly-ordered regions (TEX=0,C=0) should only be used for peripherals, and incur a serious performance penalty. They should never be used for code execution.
How come are you so sure?
Hadn't you made any application programs?
How should we configure to set a normal memory uncached?
Best regadrs,
Yasuhiko Koumoto.
Strongly-ordered and device memory impose additional constraints compared to normal uncacheable memory, which adversely impact performance without any benefit when targeting memory. In essence, accesses to device memory behave more like remote procedure calls. For example, performing 8 sequential byte-stores to normal uncacheable memory can be (and often is) merged to become a single dword-store. To device memory, they will always remain 8 individual byte-stores on the AXI bus. If strongly-ordered, then moreover the CPU will wait for each store to complete.
Normal uncacheable memory is configured by setting TEX=100 (binary), C=0, B=0. Or, in my example C code, type_normal( nc, nc ). It should obviously also not be used for code execution, as the performance impact of running without instruction caching is really severe.
If at all practical, the use of explicit cache maintenance should be considered preferable for performance reasons. On the Cortex-A8, you can moreover use the Preload Engine to fetch data to and/or evict data from L2 cache in the background while software is performing other tasks (this is especially useful when processing data in a streaming fashion).
are there any problems other than performance issue?
If there would be no problem, the memory attribute should be left to the developer.
The SDRC should work correctly under any memory attributes.
I think that this post is not aimed how we should configure memory attribute but aimed how we could solve the Gopu's problem.
I wonder why you did mention another MMU setting example.
Most likely the only reason why cache settings have an effect on whether or not the error occurs is because they affect the type (e.g. burst or not) and rate of requests to the SDRC.
The above your comment would be possible because the SDRC had worked well under uncache attribute.
However, I think the problem has nothing with the memory type (or attribute).
Anyway, the SDRAM mode regsiter setting might be revised.
Best regards,
yasuhikokoumoto wrote: are there any problems other than performance issue? If there would be no problem, the memory attribute should be left to the developer.
yasuhikokoumoto wrote:
Performance timings were being discussed. I raised the issue of memory attributes in that context.
But yes, there are more restrictions w.r.t. device and strongly-ordered memory. For example, unaligned access is forbidden (regardless of the strict alignment checking flag). More restrictions can be found by browsing the ARM architecture reference manual, for example I just found "in a VMSA implementation when any associated MMU is enabled, any multi-access instruction that loads or stores the PC must access only Normal memory. If the instruction accesses Device or Strongly-ordered memory the result is UNPREDICTABLE." Such a load is common for returning from a function, which means that putting your stack in device or strongly-ordered memory is a bad idea.
I agree, which I why I said the main issue lies there, but since I have no experience with the omap3 sdrc (only with the substantially different emif4d found in later devices) I don't immediately have any suggestions what might be the cause. Gopu said he will investigate it once his DDR memory arrives, so I will await that.
Misconfiguration of the memory typically causes data corruption rather than bus errors, since the memory controller has no way to verify the integrity of the response.