This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Issues in Cortex A9 bareboard code if L2 cache controller registers are not mapped

Hi

I have written a bareboard code for i.MX6 (Cortex A9 Quad core). I am activating and using only one core.  Once I enable the MMU, code throws random exceptions. Both L1 and L2 caches are disabled. The interesting part is that if I just map the memory mapped register space of L2 cache controller (L2C 310) in MMU (Cache is still disabled), exceptions do not come. Not able to figure out what L2 cache controller mapping do without enabling the cache.

Deepak

Parents
  • "code throws random exceptions" - did you check what exceptions were generated, what sources?

    "I just map the memory mapped register space of L2 cache controller (L2C 310) in MMU (Cache is still disabled), exceptions do not come" - memory mapping is a process of binding virtual to physical addresses, particularly you wrote memory mapping table for MMU and no exceptions were generated, that is because they could be generated only when actually accessing the memory-mapped region. Try to access memory-mapped region of memory, registers of L2-cache controller when the controller is not enabled.

Reply
  • "code throws random exceptions" - did you check what exceptions were generated, what sources?

    "I just map the memory mapped register space of L2 cache controller (L2C 310) in MMU (Cache is still disabled), exceptions do not come" - memory mapping is a process of binding virtual to physical addresses, particularly you wrote memory mapping table for MMU and no exceptions were generated, that is because they could be generated only when actually accessing the memory-mapped region. Try to access memory-mapped region of memory, registers of L2-cache controller when the controller is not enabled.

Children
  • "did you check what exceptions were generated, what sources?" - I had checked the exception sources, it was Data Abort most of the time. The exception addresses were not in the L2 memory mapped register region.

    The reason for data abort was that some register was getting corrupted (r3 mostly), and while loading/storing using address in those registers, exception occurred.

    My code runs in a while loop, so same code works for say 1000 cycles and then in one cycle throws the exception. I also checked the disassembly of code that threw exception, it looks correct.

  • This sounds like something else is going on. The simple mapping of the L2 cache registers shall not have any influence of your code. If so, the chip would have a major (yet undetected) bug.
    Try your loop w/ disabled interrupts.

    Does the value of the corrupted r3 look familiar? Like some magic pattern?

  • I have run the loop with interrupts disabled, still the exception comes. The value of r3 is mostly 0. For code to function correctly, there should be a valid address in r3.

  • Are you sure the other cores aren't running? Is it C code or assembly? Did you try to "move" your code, mean link it to a slightly different address, say +0x1004.

  • "Are you sure the other cores aren't running?" - I am reading MPIDR register for checking core ID before executing anything else. If MPIDR bits {0, 1} are 0, then only execution goes further. Otherwise an infinite loop is executed. What I can observe is that the control never reaches the infinite loop also.(I checked a memory location written by that loop). So I think no other core is running.

    "Is it C code or assembly?" - Basic core initialization, Disabling of MMU, and caches, initialization of stack pointers etc. is written in assembly. Then the actual loop where exception is observed is written in C.

    Yes, I had linked and run the code with different address also (old address + 512 MB). The observation was same.