L2 Cache

If I check the ARM Data Fault Status Register (DFSR) I usually see a 0x1008. The 8 mean

Synchronous external abort, the 1 means

ExT, bit [12]

External abort type. This bit can be used to provide an IMPLEMENTATION DEFINED classification of external aborts.

brad badke said:

If I check the ARM Data Fault Status Register (DFSR) I usually see a 0x1008. The 8 mean

Synchronous external abort, the 1 means

ExT, bit [12]

External abort type. This bit can be used to provide an IMPLEMENTATION DEFINED classification of external aborts.

Where are you finding this description of the DFSR register? Looking at section 3.2.35 of the Cortex-A8 TRM from ARM I don't see any mention of 'implementation defined', it refers to this bit combination as 'precise external abort, nontranslation' where bit 12 is labeled the SD bit defining this as a AXI slave error. This does sound like an implementation related issue though since it is an external abort from the AXI bus. Unfortunately I am not all that familiar with the internals of the ARM core itself, as we generally only support the device from a high level OS perspective (i.e. Linux), however if I can get on the same document you are reading I would be glad to take a look into it a bit further.

  The quote was from ARM DDI 0406B the Architecture Reference Manual. Sorry I said TRM. Since you have shown an interest I will give you more detail. I have 8 prototype boards. I am using a boot loader and application I have ported over from an ARM 11, so I am not starting from scratch here and have some familiarity with MMUs and caches. I am mixing in the OMAP specific stuff I need from xloader and uboot. My application produces a timer interrupt every 710 us. On this interrupt task switching may occur among 7 different tasks. I am using a fixed memory map so no cache maintenance should be required once I get everything up and running. I have run this application on the ARM 11 in my product for several years so I am pretty confident in the basics of my RTOS/application. Anyway, on the OMAP, if I just run Data and Instruction cache w/o L2 cache enabled I have no problems. I really need the L2 cache to work though because I need the perfomance. Interestingly, I do get the L2 cache to work succesfully one one of my prototype boards. When it works I have seen it run for 20+ hours w/o problem. Very odd that I get it to work some times and not others. I would be surprised to eventually discover I am not invalidating something correctly, but the random behavior is starting to make me think hardware. I am more than happy to share my boot loader code with you which is where the cache is enabled, cleaned, and invalidated (flushed) before it jumps to the application. The cleaning, enabling, and flushing code is essentially lifted from xloader and uboot since it is somewhat different than ARM 11.

c5, Data Fault Status Register (DFSR)

The Data Fault Status Register, DFSR, holds status information about the last data fault.

The DFSR is:

• a 32-bit read/write register

• accessible only in privileged modes.

The format of the DFSR is:

IMPLEMENTATION DEFINED

classification of external aborts.

For aborts other than external aborts this bit always returns 0.

Write not Read bit. Indicates whether the abort was caused by a write or a read access:

0

Abort caused by a read access

1

Abort caused by a write access.

For faults on CP15 cache maintenance operations this bit always returns a value of 1.

FS, bits [10,3:0]

Fault Status and Fault Address registers in a PMSA

implementation

on page B4-18.

Accessing the DFSR

set to

c0, and

<opc2>

set to 0. For example:

MRC p15,0,<Rt>,c5,c0,0 ; Read CP15 Data Fault Status Register

MCR p15,0,<Rt>,c5,c0,0 ; Write CP15 Data Fault Status Register

brad badke said:

The quote was from ARM DDI 0406B the Architecture Reference Manual. Sorry I said TRM.

You did not mention TRM, it was just the first place I would typically look for such a register, and since i happened to find it in there I was not sure if you were using some other version, or as it turned out, another more  interesting document.

Based on the architecture manual it seems more clear that the ARM core itself does not identify such an error, so if this were to be traced down it would have to be through the TI implementation, some (probably reserved) status register, if it is truly traceable at all. This being said, I would probably recommend working with your local TI contact, as I believe you already are, to run down the issue from that aspect.

brad badke said:

I would be surprised to eventually discover I am not invalidating something correctly, but the random behavior is starting to make me think hardware.

Some bad cache management sequence could explain some randomness depending on the status of the memory in the cache, but that should be relatively deterministic if you power cycle the board for each test as the memory would be entirely cleared, unless your code has some external dependency that changes the execution sequence slightly.

Since it sounds like you are using custom hardware, have you tried running your code in some form on a dev board (Mistral EVM or Beagle)? If your code is not highly dependent on the custom hardware than running on one of these 'known good' boards may be a good way to narrow down if the problem is specific to your custom hardware.

brad badke said:

I am more than happy to share my boot loader code with you which is where the cache is enabled, cleaned, and invalidated (flushed) before it jumps to the application. The cleaning, enabling, and flushing code is essentially lifted from xloader and uboot since it is somewhat different than ARM 11.

While I would have no problem taking a look I am afraid there is not much I could do with it other than basic comparisons to what exists in X-Loader and U-Boot, since I mostly work at the higher system levels when it comes to ARM processors I am not all that familiar with the ARM cache management sequences or ARMv7 assembly.

The OMAP specific hardware is quite similar to the Beagle Board which I started development with until my boards were ready. We required a custom board because we interface to a custom ASIC on GPMC CS2.

brad badke said:

The OMAP specific hardware is quite similar to the Beagle Board which I started development with until my boards were ready. We required a custom board because we interface to a custom ASIC on GPMC CS2.

Is the L2 cache enable crash something that happens on the Beagle as well, or is it something that only showed up with the new board?

The Beagle has been around for a while now and is known to be stable, so if you see the same crash on the Beagle it would make something software wise more suspect, if things run smooth on the Beagle than you may want to take a closer look at your schematics as there would likely be something in your hardware that makes your board special. If this is a hard test to run than it may not be worth it, but if it is something you could do quickly it is one way to 'divide and conquer' the problem.

Hi brad badke,

iam facing the problem while enabling MMU on the OMAP with Cortex A8 as when I enabled MMU before loading program it is giving error that can not write to target. and i did this with CCS Gel file. or if i directly enabled with CP15 control register it is gving exception after that instruction.

as you said that in ur post that you have enabled the MMU.

so suggest me how to enable the MMU in OMAP.

Thanks in advance,

Vinay.

I use the ARM RealView compiler not CCS. Further, I run my own OS not Linux, so I may do some things differently than what you need.

1) initialize the page tables

2) map the sections

3) initialize the MMU

4) enable the mmu

    ; This macro enables the MMU.
    MACRO
    enableMMU $w1   

        ; read current settings in control reg
        getARMControl  $w1

        ; set the mmu bit
        orr   $w1, $w1, #CONTROL_MMU        ;;Note CONTROL_MMU = 0x1
        ; write back the new value
        setARMControl $w1

    MEND

Depending on your background you may not know what any of the above means, see if you can do a little reasearch on the steps I have outlined and feel free to ask more questions.

Also, if anybody cares, the  piece of information I was missing in my L2 cache enable is

    mov r12, #0x1   ;;set up to invalidate L2 
    DCD 0xE1600070    ;;Call SMI monitor

I now have L2 cache working perfectly.

brad badke said:

Also, if anybody cares, the  piece of information I was missing in my L2 cache enable is

    mov r12, #0x1   ;;set up to invalidate L2 
    DCD 0xE1600070    ;;Call SMI monitor

I now have L2 cache working perfectly.

Thanks for sharing.  I think instead of the magic number you can just put in the instruction "SMI" (or maybe it was (SMI #0).  That's mentioned in the "Initialization" chapter of the TRM.  Here's a screenshot.

I've had some other customers that had issues with the L2 cache.  What we discovered in the end was that the SMI call to enable the L2 cache should only be done ONCE during initialization.  Any subsequent operations should use the usual MCR/MRC instructions, otherwise you will get an unintended reset.

brad badke said:

Also, if anybody cares, the  piece of information I was missing in my L2 cache enable is

    mov r12, #0x1   ;;set up to invalidate L2 
    DCD 0xE1600070    ;;Call SMI monitor

I now have L2 cache working perfectly.

PS.  I tracked down the proper mnemonic -- though now I forget if this was using the ARM compiler or GCC!  (Maybe it doesn't matter...)

    mov r12, #0x1   ;;set up to invalidate L2 
    SMCEQ #0    ;;Call SMI monitor

The SMCEQ #0 instruction disassembles to 0xE1600070 like you have above but looks a lot less cryptic!

SMC = Secure Monitor Call. Does work with the ARM Realview compiler. The instruction used to be SMI. Very odd that I needed an instruction from ARM Architecture Reference Manual Security Extensions Supplement. Anyway, it does work, and I beleive you are correct about only using it once and from then on using the usual methods to clean and invalidate cache.

Actually SMCEQ is the same as DCD 0x01600070 and SMC is the same as DCD 0xE1600070.

With the TMS470 compiler looks like we need

asm(" MOV  r12,#0x1"); 
asm(" SMI #0x0");

Could you confirm this. SMC is not supported by the TMS470 compiler.

Angelo,

Please start a new thread in the Compiler forum (under Development Tools).  You might reference this thread to give the compiler guys a little background as to what you're doing, but they should be able to help answer.  I don't think the right people are going to see it over here.

Thanks,
Brad