System overview

The Zynq system-on-a-chip at the highest level consists of:

...

Programs running in the UPCPUs of the cores see the non-core resources of the PS, such as the L2 cache controller, the UART and the GPIC as sets of memory-mapped registers. They see the in-core resources through the standard coprocessor interface instructions, which can address up to 16 coprocessors numbered 0-15. Coprocessor 15 is reserved for the MMU, L1 caches and various core control functions. Coprocessors 12-14 are reserved for SIMD and floating-point operations provided by the NEON.

The ARM Cortex-A9

ARM is an old semi-RISC processor design; the first version of it was released in 1985. Implementations are classified broadly by architecture and by the design of the processor core implementing the architecture:

• Architecture.This is the view of the UPCPU seen by programmers (privileged and not). The architecture revision is referred to as ARMv5, ARMv7, etc. There used to be only one current version of the architecture but lately this has been split into three "profiles":
  • A or Application profile. Intended for use with multi-user operating systems such as Linux, A-profile architectures include a Virtual Memory System Architecture (VMSA) wherein an MMU (or several) provide full-blown address remapping and memory attributes such as cached, non-executable, etc.
  • R or Real-Time profile. Meant for single-user RTOSes such as VxWorks or RTEMS. Incorporates a Protected Memory System Architecture (PMSA) wherein an MPU provides memory attributes but not address mapping. Integer division is implemented in hardware. There are "tightly coupled" memories that are closer to the UPCPU than any L1 caches.
  • M or Microcontroller profile. Intended for the simplest embedded systems which don't run a true operating system.
• UPCPU implementation. There have been many implementations, until recently designated by "ARM" followed by a processor family number and a bunch of letters telling what extra features are present, e.g., ARM7TDMI. Note that the family number doesn't indicate which ARM architecture revision is implemented, e.g., ARM7 processors implement architecture v5. Lately this scheme has been abandoned in favor of a family name, architecture profile letter and family revision number such as "Cortex-A9".
• Number of cores. In later systems a number of ARM cores may share main memory, some or all peripherals and some caches. Such systems have the word "MPCore" appended to the classification.

ARM features implemented in the Zync

The APU on the Zync implements these ARM features:

...

• Obsolete floating-point (FP) independent of NEON
• Alternate NEON floating point (VFP3-16 or VFP4-anything)
• 40-bit physical addresses (Large Physical Address Extension)
• Virtualization (hypervisor support)
• SWP instruction.

UPCPU "state" vs. "mode" and "privilege level"

Both mode and state are reflected in bits in the Current Processor State Register, or CPSR. "State" refers to the instruction set being executed. "Mode" and "privilege" determine the view of the UPCPU the programmer sees; some instructions may be forbidden and the visible bank of registers may differ.

...

The two privilege levels are duplicated in Secure mode and Non-Secure mode, which have distinct address spaces. Under RTEMS we'll be using only Secure mode running at PL1.

MMU

There can be up to four logical MMUs per ARM core (they may be implemented with a single block of silicon with multiple banks of working registers). Without the security or virtualization extensions there is just one logical MMU which is used for both privileged and non-privileged accesses. Adding the security extension adds another for secure code, again for both privilege levels. Adding the virtualization extension adds two more logical MMUs, one for the hypervisor and one for a second stage of translation for code running in a virtual machine. The first stage of translation in a virtual machine maps VM-virtual to VM-real addresses while the second stage maps VM-real to actual hardware addresses. The hypervisor's MMU maps only once, from hyper-virtual to actual hardware addresses.

...

If No Access is specified in the DACR, access attempts generate Domain exceptions. If a type of access is denied by the translation table entry it causes a Permission exception.

MMU translation tables implemented for RTEMS

The 4 GB address space is divided into Regions, where each Region is assigned a page size and default memory access rights based on the the intended use of the Region. Simple dynamic allocation is supported for Regions where that makes sense. In Regions where we don't need to change access permissions on relatively small areas, e.g., I/O buffers, we set the page size to 1 MB, the size of a section. Regions which require finer-grained control of access permissions, e.g., where shared libraries are loaded, are given a page size of 4 KB. All MMU table entries specify access domain 15 which is set up for Client access, meaning that the translation table entries specify access permissions. All entries are global entries, meaning that they apply to all code regardless of thread; the table is never modified by context switches. The address mapping is the identity, i. e., virtual == real.

...

Region

Addresses

Mem type

Page size

Allocatable

Purpose

Null catcher

0x00000000-0x00003fff

Reserved

4K

n/a

Catch attempts to deference null pointers.

Syslog

0x00004000-0x00103fff

Normal

4K

Yes

RWXC.

Circular buffer for captured console output.

MMU

0x00104000-0x00167fff

Strongly ordered

4K

Yes

R...S

MMU tables.

Run-time support

0x00168000-0x0a9fffff

Normal

4K

Yes

RWXC.

Loaded shared libraries.

Workspace

0x0aa00000-0x153fffff

Normal

1M

Yes

RW.C.

RTEMS workspace, C/C++ heap, application data.

Uncached

0x15400000-0x1fffffff

Normal

1M

Yes

RW...

I/O buffers.AXI

 0Socket

0x40000000-0x400fffff0x500fffff

Device

1M

No

RW..S

AXIInterfaces to (firmware) window 0 (unused for now).

AXI 1

firmware sockets.

AXI0 test

0x50100000-0x501fffff

Device

1M

No

RW..S

Reserved for interfaces to non-standard firmware.

Firmware Version/Control

0x80000000-0x800fffff

Device

1M

No

RW..S

Version info, some control registers.

BootStrap Information

0x84000000-0x840fffff

Device

1M

No

RW..S

Bootstrap info structure.

AXI1 test

0x84100000-0x841fffff

Device

1M

No

RW..S

Reserved for 

interfaces 

to non-standard firmware

.

IOP

0xe0000000-0xe02fffff

Device

1M

No

RW..S

Various I/O devices.

Static

0xe1000000-0xe5ffffff

Device

1M

No

RW..S

Static memory controllers, e.g., flash.

High-reg

0xf8000000-0xfffbffff

Device

4K

No

RW..S

Various I/O devices.

OCM

0xfffc0000-0xffffffff

Normal

4K

Yes

RW.CS

On-chip memory.

...