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

Trying to Freeze L1 Instruction Cache Contents on the Cortex A53

Hello everyone,

I recently have been testing the direct internal memory access of the Cortex A53 on the Xilinx ultrascale+ SoC, most notably to access the L1 data cache (data portion) and L1 instruction cache (data portion). I can successfully access the contents of both caches through the CP15 operations as described in the TRM but the issue I'm facing is that after disabling the instruction cache, the content in instruction cache is different when comparing previous reads on the instruction cache. The TRM has a section on the behavior of disabling the instruction cache but nothing that would explain the instruction cache contents changing other than perhaps cache maintenance operations (which I am not directly running). The procedure I have been using to test this behavior is:

  1. Disable the instruction cache (expectation: The contents inside the instruction cache should remain unchanged or 'frozen').
  2. Create an array large enough to store the instruction cache something like u32 cache[MAX_WAY][MAX_SET][MAX_OFFSET][NUMBER_DATA_REGISTERS] (expectation: the array should have enough memory to store the instruction cache content) 
  3. Iterate through the instruction cache and fill the array from step 2 (expectation: Instruction cache contents should be stored in the array)
  4. Iterate through the instruction cache again but compare the instruction cache with the array from step 3, if the array and the instruction cache differ print a message stating the way, set and offset as well as the data from both the array and instruction cache (expectation: The instruction cache content should not have changed since the last access to the instruction cache from step 3 because the instruction cache is disabled. This means there should not be any print messages).

The result of this procedure is that multiple (probably more than 50 or so) print messages appear notifying a difference between the array with the instruction cache contents and the current instruction contents. I can perform the same procedure on the L1 data cache that results in not receiving any print messages which is expected but not the instruction cache. It's completely possible that I am not accessing or storing the instruction cache correctly but the data cache I implemented is working as expected and I have made the necessary changes so that the instruction cache should perform in a similar way by using the TRM section on accessing the instruction cache. This brings me to a couple of questions:

  1. Does disabling the instruction cache guarantee the contents to be untouched and remain constant? (References to the Cortex A53 TRM or ARM v8 architecture would be helpful)
  2. Supposing that disabling does not guarantee the instruction cache to remain constant, is there any additional steps to make the instruction cache remain constant? (References to the Cortex A53 TRM or ARM v8 architecture would be helpful)

Any help would be greatly appreciated. Thank you.

Best Regards,

Nathan

  • Hi Nathan, 

    The disabled behavior means that fetches won't trigger lookups or allocations, but the cache will continue to be used for internal buffering (this usage is associated with the pre-decoder).

  • Resolution
    For system build with Intel® Boxed Processors, these are the possible causes with tips to try:-

    Overheating: When overheating, the CPU’s temp control circuit will attempt to throttle the CPU’s clock (stop/go/stop/go) to try and cool the CPU. That condition is called PROHOT. If the CPU continues to heat further, then the temperature control circuit (TCC) will halt the CPU completely, full stop to prevent damage. That’s call THERMTRIP and is an unrecoverable condition requiring a hard reboot (AC unplug, reboot).

    Make sure the thermal solution is compatible and installed properly. Refer to troubleshooting overheating issues.
    Power Fault: Power fault, lower than necessary total power supply (for example, a 450W power supply for system with 550W of desired power). It is common to see a hang here when loading an application that causes a power spike. Some low-cost power supplies, even if rated for enough power, often do not have robust enough power components to handle a large/instant power increase.
    Memory Issues: Either bad devices, DIMM improperly seated, DIMM edge connector, or size.
    Make sure the memory is seated well.
    Try a different memory.
    Try to have sufficient amount of memory in your build system.
    Motherboard issues: If possible, swap with a good working motherboard.
    Try to update system BIOS to the latest version, or reset BIOS to defaults, You can also try to clear CMOS.
    For laptops, All-In-Ones, or notebooks, refer to your to OEM (original equipment manufacturer): Computer Manufacturer Support Websites.

    Other reasons could be:

    CPU reaches 100% of usage. Refer to how to fix high CPU usage.
    Drivers not updated: Open the Start menu, then Settings. Click Updates & Security, then the Check for Updates button. This will update critical drivers.

    Windows* operating system needs to be updated.

    Greeting,

    Rachel Gomez