Collapse all Symbian^3 Product Developer Library

Remapping Cache Attributes and Access Permissions on ARMv6K and ARMv7 Platforms

Describes the behavior change brought about by remapping the cache attributes and the access permissions on the ARMv6K (ARM1176 & ARM11MPCore), ARMv7 (Cortex-8N), and future 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().

Note: 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.

Note: 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`

Parent topic: Kernel-Side Services