You copied the Doc URL to your clipboard.

Chapter 9 IDAU interface, IDAU, and memory map

The IDAU is used to indicate to the processor if a particular memory address is Secure, Non-secure Callable (NSC), or Non-secure, and provides the region number within which the memory address resides

It can also mark a memory region to be exempted from security checking, for example, a ROM table. The IDAU interface in general is processor-specific. However, there is a high similarity between the IDAU interfaces on different Cortex-M processors.

Figure 9-1 Example IDAU interface.

Example IDAU interface

In theory it is possible to design the IDAU to be programmable. However, the signals on the IDAU interface are likely to be on timing critical paths which can make a complex IDAU impractical and could result in a higher gate count in the design. As a result, the IDAUs provide simple memory mapping with limited configurability.

Armv8-M defines a default memory map divided on 512MB boundaries when the MPU is disabled. The example memory map in the following figure adds support for Security by aliasing each of these at their halfway point such that the lower half provides access to a 256MB Non-secure window. The upper half provides a Secure view of the same 256MB region. Control points elsewhere in the system determine what is accessible in each of the Secure and Non-secure windows.

For example, a designer could use bit [28] of the address to define if a memory is Secure or Non-secure, resulting in the following example memory map.

Figure 9-2 Simple memory map created by a minimal IDAU design

Simple memory map created by a minimal IDAU design

Note: The use of bit[28] for both aliasing and defining Secure vs Non-secure is an example only and must not be relied upon by software.

Such an IDAU can generate the required signals in the following ways:

  • The Secure or Non-secure indication can be generated using address bit [28].
  • The Secure NSC indication can reuse the Secure indication. This results in all Secure regions being indistinguishable from Secure NSC regions, and are therefore callable from Non-secure software by default. The Secure software must therefore use the internal SAU to force most of the Secure NSC regions to be Secure regions (not NSC) before allowing any Non-secure software to run.

It is important to ensure that only those memory areas that contain valid Secure entry functions (using the SG instruction) are configured to be NSC. Other Secure memories, for example, the stack, could contain data pattern that matches the SG instruction and therefore must not be configured as an NSC region.

  • The region number can be generated from bits [31:28] of the address value, with the Region Valid signal tied high. It is important that region numbers are unique for each memory region, unless the memory region number is indicated as invalid by the IDAU interface.
  • The Exempted Region control is set to 1 if the address is in the CoreSight ROM table address ranges, allowing the debugger to access to the ROM tables for device identification, even if the debugger is restricted to Non-secure debug only.

There is no restriction on whether Secure memory must be in the upper or lower half of each memory region. If the processor being used has an initial boot address that is restricted to address 0x00000000, then it is better to have the lower half of the address marked as Secure so that the processor can boot in the Secure state.

For application scenarios where an Armv8-M processor is used together with an Armv8-A system with a shared memory security attribute configuration, then the IDAU response signal should be generated based on the system-wide security arrangement; the simple memory map arrangement that is described here would be insufficient.

Was this page helpful? Yes No