Isolation Configuration
The Zynq UltraScale+ MPSoC can be partitioned into sub-systems, so that they can be managed independently by the power management framework. For example, you can define a Linux sub-system and a Real-time sub-system. The Linux sub-system may include the APU (as the PM master) and a number of peripherals (as the PM slaves). The Real-time sub-system may include the RPU and a number of other peripherals. Each sub-system can be powered up, powered down, restarted or suspended without affecting the other sub-systems. A sub-system has only one PM Master, and may include both FPD and LPD peripherals.
You can create your own sub-systems using the Vivado® PCW tool. The following figure shows the PCW screen shots of a valid configuration, which contains only an APU sub-system and no RPU sub-systems.
Configuration Object
The sub-system configuration is captured in a Configuration Object, which is generated by the Vivado and PetaLinux toolchain. The Configuration Object contains:
- The PM Masters that are present in the system (APU and/or RPU). Any PM Master not specified in the Configuration Object will be powered down by the PMU.
- Configurable permissions for each PM Master, such as:
- Which PM Master can use which PM Slave (A PM Master can use all the PM Slaves that belong in the same sub-system.)
- Access to MMIO address regions.
- Access to peripheral reset lines.
- Pre-allocated PM Slaves. The PM Master can use these PM Slaves without requesting for them first. These PM Slaves are needed by the PM Master in order to boot. The toolchain makes sure that the APU can access the L2 cache and DDR banks without first requesting for them. The same is true for the RPU accessing all the TCM banks.
Power Management Initialization
Power management is disabled during boot and all the peripherals are powered up at this time. That is because it is often necessary to allow for possible, and temporary, inter-dependencies between peripherals during boot and initialization. When FSBL is finished with initializing the peripherals and loading the application binaries, it passes the Configuration Object to the PMU. The PMU is now aware of all the sub-systems and their associated PM Masters and PM Slaves. PM Masters and PM Slaves that are not included in the Configuration Object are never used, and are powered down by the PMU.
A PM Master is not likely to use all the PM Slaves at all times. Therefore, a PM
Slave should be powered up only when it is being used. The PM Master must notify the
PMU before and after using a PM Slave. This functionality is implemented in the
PetaLinux kernel. This requirement hinders developers starting with a new RPU
application, when the focus is on functionality and not power optimization.
Therefore, it is convenient for the PMU to also support PM-incapable Masters that do
not provide notifications when they are using the PM Slaves. This is done by keeping
all the PM Slaves in the sub-system powered up until the PM Master sends the
PmInitFinalize request to the PMU. A PM-incapable Master will
never send this request, which means that its PM Slaves will remain powered up at
all times or until this PM Master itself is powered down.
A PM-capable Master sends this request after initializing the sub-system. The PMU then begins powering down the PM Slaves in this sub-system whenever they are not being used.
As a result, when there is an RPU master present in the system but it is not running any application, the PMU firmware will consider it as a PM incapable master and hence will never power down the RPU and its slaves. From the 2018.3 release and onwards, this behavior is fixed and allows you to power down unused RPUs. This change is protected by the compilation flag ENABLE_UNUSED_RPU_PWR_DWN and is enabled by default. When this flag is enabled, the unused RPU and allocated slaves will be powered down if not in use.
| Boot Mode | APU Image | RPU Image | RPU Mode | ENABLE_UNUSED_RPU_PWR_DWN_VAL | RPU0/TCM0 State | RPU1/ TCM1 State |
|---|---|---|---|---|---|---|
| JTAG | Don’t Care | Don’t Care | Don’t Care | Don’t Care | ON | ON |
| Non-JTAG Boot modes | Don’t Care | Don’t Care | Don’t Care | 0 | ON | ON |
| Linux or PM aware app that calls PM_INIT_FINALIZE | RPU app in boot image | Lock step mode | 1 | ON | OFF | |
| RPU0 app in boot image | Split mode | 1 | ON | OFF | ||
| RPU1 app in boot image | Split mode | 1 | OFF | ON | ||
| Both RPU apps in boot image | Split mode | 1 | ON | ON | ||
| RPU app not in boot image | 1 | OFF | OFF | |||
| Bare Metal app that does not call PM_INIT_FINALIZE | Don’t Care | Don’t Care | Don’t Care | ON | ON |
Default Configuration
By default, Isolation Configuration is disabled, and the tool chain generates a configuration with three sub-systems. Each has a PM Master: APU, R5-0 and R5-1. All three sub-systems contain all the PM Slaves (meaning that the sub-systems completely overlap each other.) This is the default configuration generated by PCW when the “Enable Isolation” box is unchecked. The default PetaLinux kernel configuration is PM-capable, but R5-0 and R5-1 must be also running “PM-capable” applications, or be powered down. Otherwise, the PMU will not power down any PM Slaves.
RPU Lock-step vs. Split Mode
The toolchain infers the RPU run modes from the PCW Isolation Configuration as follows:
- No RPU present in any subsystem: Configuration Object contains no RPU.
- Only R5-0 present in subsystem(s): Configuration Object contains R5-0 running in lock-step mode.
- Both R5-0 and R5-1 in subsystems: Configuration Object contains R5-0 and R5-1 running in split mode.
- Only R5-1 present in subsystem(s): Configuration Object contains R5-1 running in split mode.
The default Configuration Object contains two RPU PM Masters: R5-0 and R5-1, and the PMU assumes that the R5-0 and R5-1 are running in split mode. However, the boot image actually determines whether the RPU runs in lock-step or split mode at boot time. The RPU run mode from the boot image must match the number of RPU PM Masters in the Configuration Object. Otherwise, the power management framework will not work properly.