Table of Contents |
---|
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 | Permissions (RWXCS) | Purpose | ||||
---|---|---|---|---|---|---|---|---|---|---|
Null catcher | 0x00000000-0x00003fff | Reserved | 4K | n/a | None | 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 | 0x80000000-0x80bfffffDevice | 1M | No | RW..S | AXIReserved for | windowinterfaces | 1 (RCEto 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. |
...