You copied the Doc URL to your clipboard.

Translation table configuration

In addition to storing individual translations within the TLB, the MMU can be configured to store translation tables in Cacheable memory. This usually provides much faster access to tables than always reading from external memory. TCR_EL1 has fields that control this. These fields specify the cacheability and shareability of translation tables for TTBR0 and TTBR1. The relevant fields are called SH0/1 Shareability, IRGN0/1 Inner Cacheable, and ORGN0/1 Outer Cacheable.

The following table shows the permitted settings for cacheability.


Cacheable Property


Normal memory, Inner Non-cacheable


Normal memory, Inner Write-Back Write-Allocate Cacheable


Normal memory, Inner Write-Through Cacheable


Normal memory, Inner Write-Back no Write-Allocate Cacheable

The corresponding table for shareability of memory is associated with translation table walks. For a device region, the value is ignored.

SH0 bits[13:12]







Outer Shareable


Inner Shareable

The attributes that are specified in the TCR_EL1 must be the same as those specified for the virtual memory region in which the translation tables are stored. Caching the translation tables is the normal default behavior.

Virtual address tagging

The Translation Control Register (TCR_ELn) has an extra field that is called Top Byte Ignore (TBI) that provides tagged addressing support. The most significant 16 bits of an address in a 64-bit general-purpose register must be 0xFFFF or 0x0000. Any attempt to use a different bit value triggers a fault.

When tagged addressing support is enabled, the top eight bits [63:56] of the virtual address are ignored by the processor. It internally sets bit [55] to sign-extend the address to 64-bit format. The top 8 bits can then be used to pass data. These bits are ignored for addressing and translation faults. The TCR_EL1 has separate enable bits for EL0 and EL1.

One example use case might be in support of object-oriented programming languages. In addition to having a pointer to an object, you might have to keep a reference count of the number of references or pointers or handles that refer to the object, for example, so that automatic garbage collection code can de-allocate objects that are no longer referenced. This reference count can be stored as part of the tagged address, rather than in a separate table, speeding up the process of creating or destroying objects.

Was this page helpful? Yes No