Remapping +Cache Attributes and Access Permissions on ARMv6K and ARMv7 Platforms

Reduced set +access permissions

The ARMv6-style page table reserves three bits +in the page/directory table for access permission, so eight possible values +are available. The use of four possible access permissions is sufficient. +Therefore, removing the surplus access permissions frees up one page table +bit that is used by Symbian platform internally.

Affected kernel interface

The +shadow pages kernel interface is valid on all platforms except for the emulator. +On ARMv6 and previous platforms, shadow pages are created using access permission PrivilegedRW/UserRO, +this is not supported by the limited set of encoding. Shadow pages are now +mapped as PrivilegedRO/UserRO, instead.

class Epoc + { +public: + ... + IMPORT_C static TInt AllocShadowPage(TLinAddr aRomAddr); + IMPORT_C static TInt FreeShadowPage(TLinAddr aRomAddr); + IMPORT_C static TInt FreezeShadowPage(TLinAddr aRomAddr); + ... + };

This represents a serious behaviour break in the kernel +interface. A device driver (running on ARMv7) that creates a shadow page and +then attempts to alter the content of the page now panics.

This is +a common use case for run-mode debuggers. However, a debugging interface is +already provided, see DebugSupport in ...\memmodel\epoc\platform.h, +where breakpoints are managed internally by the kernel. Therefore, it is believed +that a run-time debugger that uses the CodeModifier implementation +in the kernel should not be affected by this change.

After a shadow +page is created using Epoc::AllocShadowPage(), the kernel +allows the device driver to alter its content using Epoc::CopyToShadowMemory().

Epoc::FreezeShadowPage() is obsolete for platforms that use the reduced set of access permissions, +as the shadow memory is always in a “frozen” state, because it can only be +changed through the kernel interface.

Remapping cache +attributes

ARMv6 architecture uses a large number of bits in the +page table to describe all of the options for inner and outer cachability. +No applications use all of these options simultaneously so a smaller number +of configurable options has been implemented to meet the needs of the system.

This +alternative cache mapping allows up to eight different mappings in page tables. +The Symbian platform kernel and device drivers do not need more +than four or five different cache mappings.

Cache mapping cannot be +altered during run-time. It must be configured before the MMU is initialised.

See +the Bootstrap Port +Implementation Tutorial.

Types of memory supported

The +kernel supports the following types of memory:

+ + + +

Memory type

Description

+ + +

EMemAttStronglyOrdered

Writes are not combined. The order of memory accesses is preserved. +Serves as a memory barrier, which means:

previous accesses to +any type of memory must complete before accesses to strongly ordered memory +start
accesses to strongly +ordered memory must complete before any further access to any type of memory +takes place.

This type is used for hardware mapping.

+ + +

EMemAttDevice

Writes are not combined. The order of memory accesses is preserved. +This type is used for hardware mapping.

+ + +

EMemAttNormalUncached

Non cacheable memory: The order of accesses is not preserved. Writes +may be combined. For example, this is used for video memory.

+ + +

EMemAttNormalCached

Write-back read/write allocate cached memory, inner and outer. Used +for “ordinary” memory.

+ + + +

Device memory and normal memory can be set as shared or +non-shared, strongly ordered accesses are assumed to be shared.

The +complete set of memory types supported by Symbian platform are represented +by the values of the TMemoryType enum.

Mapping existing memory +types

The TMappingAttributes constants allow +the cache attributes to be manipulated. On remapped platforms, these map into TMemoryType as +follows:

+ + + +

Memory type described by TMappingAttributes

Memory type

+ + +

EMapAttrFullyBlocking

EMemAttStronglyOrdered

+ + +

EMapAttrBufferedNC

EMapAttrBufferedC

EMemAttDevice

+ + +

EMapAttrL1Uncached

EMapAttrCachedWTRA

EMapAttrCachedWTWA

EMemAttNormalUncached

+ + +

EMapAttrCachedWBRA

EMapAttrCachedWBWA

EMapAttrL1CachedMax

EmapAttrCachedMax

EMemAttNormalCached

+ + +

EMapAttrAltCacheWTRA

EMapAttrAltCacheWTWA

EMapAttrAltCacheWBRA

EMapAttrAltCacheWBWA

Return error

+ + +

EMapAttrL2CachedWTRA

EMapAttrL2CachedWTWA

EMapAttrL2CachedWBRA

EMapAttrL2CachedWBWA

EMapAttrL2CachedMax

Takes no effect. Only the inner cache description matters.

This +policy is already in place on ARMv5 platforms with L210, where the page table +does not support a separate description of the inner and outer cache attributes.

+ + + +

Mapping ARMv6K or ARMv7 +onto TMappingAttributes

To describe memory on ARMv6K or ARMv7 +using the original TMappingAttributes bit mask, the device +driver should use the following values:

+ + + +

ARMv6K/v7 memory type TMemoryType

TMappingAttributes mask to use

+ + +

EMemAttStronglyOrdered

EMapAttrFullyBlocking

+ + +

EMemAttDevice

EMapAttrBufferedNC

+ + +

EMemAttNormalUncached

EMapAttrL1Uncached

+ + +

EMemAttNormalCached

EmapAttrCachedMax

+ + + +