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
Hello Gopu,
I'm sorry but I had misunderstood.
Although you had made all areas of memory space cacheable, it had been erroneous.
You should better make only ROM and RAM areas cacheable.
The below is revised your code.
The opinion which peripheral areas should be the device type may exist, but I don't recommend it because such areas become buffer-able.
write_pte: MOV r0, r2, LSR #4 CMP r0, #0x40 ;@ Internal ROM/RAM areas MOV r0, r2, LSR #8 CMPNE r0, #0x8 ;@ SDRAM area CMPNE r0, #0x9 ;@ SDRAM area CMPNE r0, #0xA ;@ SDRAM area CMPNE r0, #0xB ;@ SDRAM area MOVEQ r0, #0x0E ;@ if ROM or RAM, cacheable MOVNE r0, #0x02 ;@ if others, uncacheable (strongly ordered) ORR r0, r0, r4, LSL #0xA ORR r0, r0, r4, LSL #0xB ORR r0, r0, r2, LSL #20 STR r0, [r1] ADD r1, r1, #4 ADD r2, r2, #1 SUBS r3, r2, #4096 BNE write_pte
With this modification I anticipate your code will work successfully.
Best regards,
Yasuhiko Koumoto.
yasuhikokoumoto wrote: Although you had made all areas of memory space cacheable, it had been erroneous.
yasuhikokoumoto wrote:
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).
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.)
Hi,
Thanks alot for your updated code. I have checked with this code, the problem still exist.
As you have mentioned in your earlier post, the issue should be in SDRC, I will check it once I get DDR.
Thanks again,
have there been any progress?
Form the phenomena, it would be clear that SDRAM could not accept the burst accesses from the SDRC.
You should better check again the setup parameters of SDRC.
That is, what are the contesnts of the follwoing registers.
SDRC_MCFG_p 0x6D00 0080 + (0x0000 0030 * p) ( p=0 or 1)
SDRC_MR_p 0x6D00 0084 + (0x0000 0030 * p)
SDRC_EMR2_p 0x6D00 008C + (0x0000 0030 * p)
SDRC_DLLA_CTRL 0x6D00 0060
SDRC_ACTIM_CTRLA_p 0x6D00 009C + (0x0000 0028 * p)
SDRC_ACTIM_CTRLB_p 0x6D00 00A0 + (0x0000 0028 * p)
SDRC_RFR_CTRL_p 0x6D00 00A4 + (0x0000 0030 * p)
I hope this will help you.
hi,
I will check this and let you know.