• Locked Locked
  • Replies 7 replies
  • Subscribers 119 subscribers
  • Views 4966 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

Enabling I-cache resulting into an abort

Vaibhav Bedia
Note: This was originally posted on 17th November 2010 at http://forums.arm.com

Hi,

I am working on a bootloader for Cortex-A8 based on the open source bootloader U-Boot v2010.06. I have a 2 stage approach where the 1st stage boots up, loads the 2nd stage to DDR and then passes control to it.

Things work fine without cache enabled in the 1st stage. However when i enable the I-cache in the 1st stage and transfer control to the second stage, the 2nd stage runs for a few instructions and then goes into an abort in a perfectly valid instruction.

What is even more puzzling is that leaving the cache ON seems to affect only a particular boot mode. When the 2 stages are fetched from NAND or UART there is no problem. But when i use SD card for loading the 2 stages this problem crops up.

I even tried putting the Instruction Sync Barrier instruction before the jump to the code where the abort occurs... but no change.

Any pointers?

Thanks,
Vaibhav

P.S.: I could attach the code snippet for this if it helps
  • Arm Employee Badge
    Note: This was originally posted on 17th November 2010 at http://forums.arm.com

    You say you get an abort, what does the IFSR and IFAR say?
  • Note: This was originally posted on 17th November 2010 at http://forums.arm.com


    You say you get an abort, what does the IFSR and IFAR say?


    Sorry those are new terms to me. Can you be a bit more descriptive please?
  • Arm Employee Badge
    Note: This was originally posted on 17th November 2010 at http://forums.arm.com

    Did you invalidate the cache before enabling it?
  • Note: This was originally posted on 18th November 2010 at http://forums.arm.com

    Yes. The cache is invalidated before being enabled.


    /*
    273       * Invalidate L1 I/D
    274       */
    275   mov  r0, #0               @ set up for MCR
    276   mcr  p15, 0, r0, c8, c7, 0   @ invalidate TLBs
    277   mcr  p15, 0, r0, c7, c5, 0   @ invalidate icache
    278
    279   /*
    280       * disable MMU stuff and caches
    281       */
    282   mrc  p15, 0, r0, c1, c0, 0
    283   bic  r0, r0, #0x00002000  @ clear bits 13 (--V-)
    284   bic  r0, r0, #0x00000007  @ clear bits 2:0 (-CAM)
    285   orr  r0, r0, #0x00000002  @ set bit 1 (--A-) Align
    286   orr  r0, r0, #0x00000800  @ set bit 12 (Z---) BTB
    287   mcr  p15, 0, r0, c1, c0, 0
  • Arm Employee Badge
    Note: This was originally posted on 18th November 2010 at http://forums.arm.com

    Most ARM cores have registers to give information on the cause of an abort, which you can read within your abort handlers.  These are:

      - Fault Status Register - Type of abort (e.g. from the MMU, from external memory, unaligned access, ....)
      - Fault Address Register - The actual address that aborted

    There are usually separate registers for data aborts (DFSR and DFAR) and prefectch aborts (IFSR and IFAR).  So if you are getting a prefetch abort, a good place to start is the contents of these registers.

      http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344b/Bgbjhija.html - IFSR
      http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344b/Babcjgia.html - IFAR
  • Arm Employee Badge
    Note: This was originally posted on 18th November 2010 at http://forums.arm.com



    277   mcr  p15, 0, r0, c7, c5, 0   @ invalidate icache



    This is only invalidating the i-cache to the point of unification (i.e. it is invalidating the L1 cache, but it isn't invalidating the L2 cache because that is a unified cache used for instructions and data). Are you enabling the L2? If you are that will need invalidating before you do so also - but you have to iterate over the number of sets and ways it has - there isn't an invalidate entire-L2 instruction.

    You also invalidate the cache before disabling it (if it was enabled at all). If it was enabled and you had any data in your d-cache which is not yet written back to main memory then you are going to lose it. You need to clean + invalidate the D cache, before you disable it.

  • Cache memory needs to be invalidated before it is being used or initialized.

    Kindly go through the following steps :

    1. Clean and invalidate cache memory

    2. NOP for certain clock cycles as specified by TRM

    3. Initialize the I cache and D cache

    4. ISB / DSB should be executed.

    The above steps should be carried out for both L1 and L2 cache memory.