A domain is a separate execution environment with its own address space and potentially attached devices. On a simple CPU, such as a minimal MicroBlaze™ processor without a memory management unit (MMU), there is only one domain. On more advanced CPUs, such as the APU, there are multiple domains, isolated by exception levels 0-3 (EL0-3) and some of those can have a segmented secure domain (SEL0-1) as shown in the following figure.
The following table shows examples of what can run in the various domains on an APU.
Domain | Non-Secure | Secure (TrustZone) |
---|---|---|
EL0 | Linux process/application RTOS application process model |
Secure or trusted application |
EL1 | Linux kernel RTOS kernel |
Secure OS such as OP-TEE |
EL2 | Optional hypervisor (Xen), U-Boot | Not supported |
EL3 | TF-A |
For CPU-like execution engines (APUs, RPUs, MicroBlaze processors, AI Engine, and etc.) an image is the compiled program that runs in a domain. Typically, the standard ELF format is used, but in some cases, it is converted to more compact formats such as a PDI.
The term, image, is also used for the “code/logic” running in the PL/FPGA. The PL image or bitstream is an overloaded term as it refers both to configuration information (for example, initiating a device) and the customer code that is translated to PL fabric configuration.
The images are loaded into their domains in a few different ways:
- During Boot
-
- A PDI file in QSPI, SD, eMMC, or OSPI
- BootROM handles loading the PLM, while the PLM handles loading the rest of images. Additionally, U-Boot handles loading a hypervisor, if used, and an OS, such as Linux.
- A JTAG debugger or SelectMAP can place an image into memory.
- A PDI file in QSPI, SD, eMMC, or OSPI
- During Runtime
-
- An operating system can load an image from a filesystem (rootfs, remote
filesystem, SD card, etc.):
- Another process (fork/exec)
- Another CPU (through OpenAMP)
- A hypervisor can load another virtual machine (VM) and its associated set of software.
- An advanced RTOS with access to a filesystem can load images.
- The PLM can load an image dynamically during restart or at the request of a client.
- An operating system can load an image from a filesystem (rootfs, remote
filesystem, SD card, etc.):
Most of the time, an image is loaded into a domain and while the data in the image changes, the code does not change until the end of the lifecycle. There are exceptions to this, most notably when Linux dynamically loads a driver as a kernel module, when a DFX region is loaded into the PL, or when a firmware update occurs.
An application can have multiple images attached to it. These multi-image applications are used for example when a regular Linux process is using an accelerator that needs to be loaded at the same time.