• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 101 subscribers
  • Views 2754 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Does the ARM Cortex-A15 treat the invalidate instruction as a clean/invalidate instruction due to a design decision or due to an errata?

Chester Gillon
Guru 92251 points
Other Parts Discussed in Thread: SYSBIOS, 66AK2H14

The SYS/BIOS 6.45.1.29 documentation for the ti.sysbios.family.arm.a15.Cache module contains the following note:

Note: The invalidate instruction is treated by A15 as a clean/invalidate instruction. Therefore, calls to Cache_inv()/Cache_invAll() will behave like Cache_wbInv()/Cache_wbInvAll() on A15.

From tests on the r2p4 Cortex-A15 within a 66AK2H14 PG2.0 device confirm that the invalidate instruction is treated as a clean/invalidate instruction.

From looking at the ARM Cortex-A15 documentation I haven't been able to work out if the behavior is due to a design decision or due to an errata. The ARM Cortex™-A15 Revision: r2p1 Technical Reference Manual ARM DDI 0438D (ID122011) implies the Data cache invalidate by MVA and Data cache invalidate by set/way should perform a Data Cache invalidate operation since the Cortex-A15 TRM just refers to the ARM Architecture Reference Manual:

In the ARM documentation the only note I can find about the DCISW invalidate by set/way instruction is treated by A15 as a DCCISW clean/invalidate by set/way instruction is the workaround description for errata 794724: L2 Cache initialization sequence may not function correctly if the L2 tag RAM requires two-cycle setup time.

The reason I started investigating the Cortex-A15 handling of the cache invalidate instructions is that found the code in bios_6_45_01_29\packages\gnu\targets\arm\rtsv7A\boot.asm which attempts to invalidate the entire L1 and L2 caches by set/way was actually performing a Data cache clean and invalidate by set/way which was causing program crashes by overwriting the downloaded program with "stale" data in the cache from a previous run. Initially I thought there was a bug in that the boot.asm code wasn't invalidating the L1 and L2 caches correctly - but then found the note in the ti.sysbios.family.arm.a15.Cache documentation about the invalidate instruction being handled as a clean/invalidate instruction.

  • 0
    TI__Mastermind 21645 points

    Hi Chester,

    Chester Gillon said:

    Does the ARM Cortex-A15 treat the invalidate instruction as a clean/invalidate instruction due to a design decision or due to an errata?

    I believe it is by design, but, you should confirm directly with ARM. I can understand why you would think it is an errata, as it is not documented anywhere.

    Chester Gillon said:

    The reason I started investigating the Cortex-A15 handling of the cache invalidate instructions is that found the code in bios_6_45_01_29\packages\gnu\targets\arm\rtsv7A\boot.asm which attempts to invalidate the entire L1 and L2 caches by set/way was actually performing a Data cache clean and invalidate by set/way which was causing program crashes by overwriting the downloaded program with "stale" data in the cache from a previous run. Initially I thought there was a bug in that the boot.asm code wasn't invalidating the L1 and L2 caches correctly - but then found the note in the ti.sysbios.family.arm.a15.Cache documentation about the invalidate instruction being handled as a clean/invalidate instruction.

    According to A15 TRM, the implementation guarantees that the L1 caches are clean when the core comes out of reset. In addition the L2 cache is also guaranteed to be clean if L2RSTDISABLE signal is low, which I believe is the case on TI SoCs. So, performing a write-back invalidate in the boot code should not break the program. If a bootloader is run before SYS/BIOS application is loaded and run, then the bootloader must clean the cache and disable it before jumping to SYS/BIOS (uboot does this for example).

    One case where you might see a problem is if back to back applications are loaded in CCS with a CPU reset in between the previous run and next load. This can be fixed by performing a system reset instead of a CPU reset.

    See below wiki:

    http://processors.wiki.ti.com/index.php/Debugging_Cortex_A15

    Best,

    Ashish

  • 0 in reply to Ashish Kapania
    Guru 92251 points

    Ashish Kapania said:
    I believe it is by design, but, you should confirm directly with ARM. I can understand why you would think it is an errata, as it is not documented anywhere.

    I will contact ARM. Thanks for confirming that I hadn't missed anything in the ARM documentation.

    Ashish Kapania said:
    One case where you might see a problem is if back to back applications are loaded in CCS with a CPU reset in between the previous run and next load. This can be fixed by performing a system reset instead of a CPU reset.

    The case where I was seeing the problem was loading SYS/BIOS applications back-to-back in CCS.

    The work-around I ended up using was to issue a reset command from the BMC on the EVMK2H prior to loading a new program, where the BMC reset ended up performing a system reset.

    Since GEL scripts can issue a System Reset will try modifying the GEL script to issue a System Reset before loading a program, since then I won't have to remember to manually perform a System Reset.