User manual

Table Of Contents
Zynq-7000 AP SoC Technical Reference Manual www.xilinx.com 102
UG585 (v1.11) September 27, 2016
Chapter 3: Application Processing Unit
Write to the interrupt clear register to clear any residual raw interrupts set.
Write to the interrupt mask register if it is desired to enable interrupts.
Write to control register 1 with the LSB set to 1 to enable the cache.
If a write is performed to the auxiliary, tag RAM latency, or data RAM latency control register with the
L2 cache enabled, a SLVERR (error) results. The L2 cache must be disabled by writing to the control
register before writing to these registers.
Cache Lockdown by Way Sequence
These are the steps to be followed for locking code by way:
1. Ensure the code to be locked is in a cacheable memory region. This can be done by programming
page table entry for the region with appropriate memory attributes. Refer to Memory Attributes.
2. Ensure the code to lockdown is in a non-cacheable memory region. For example, the region can
be marked as a strongly ordered region.
The following is the sequence that needs to be implemented in lockdown routine:
3. Disable the interrupts.
4. Clean and invalidate the entire L2 cache. This step is for ensuring that the code to be locked is
not loaded into L2 cache.
5. Find the number of ways required for loading code based on the code size.
6. Unlock the calculated ways and lock all the ways remaining. This is done by writing into data
lockdown registers. Refer to the PL310 L2 Cache Controller Document for information on these
registers.
7. Load the code into the L2 cache using PLD instruction. The PLD instruction always generates data
references; this is the reason for using data lockdown registers. For more information on PLD
instruction, refer to the ARMv7 TRM. This step loads the code into unlocked ways.
8. Lock the loaded ways and unlock the remaining ways by writing into data lockdown registers.
9. Enable Interrupts.
TIP: To check for whether the code is really locked into L2 cache, generate more references to the code
that has been locked. These references can be monitored by the L2 cache instruction hit event. For more
information on the available events of L2 cache and their initialization, refer to the PL310 L2 Cache
Controller document. This event initialization should be done prior to code locking. So more the
references to code, more the instruction hits. For example, the code that is locked can be called from a
timer interrupt handler which generates references as per the number of interrupts programmed.