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

Reduced set access permissions
- Affected kernel interface
Remapping cache attributes
- Types of memory supported
- Mapping existing memory types
- Mapping ARMv6K or ARMv7 onto TMappingAttributes.

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

- - - -

+ + + + + +Remapping +Cache Attributes and Access Permissions on ARMv6K and ARMv7 PlatformsDescribes 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
- Affected kernel interface
Remapping cache attributes
- Types of memory supported
- Mapping existing memory types
- Mapping ARMv6K or ARMv7 onto TMappingAttributes.

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

+ + + +

\ No newline at end of file