The Platform Management Unit (PMU) controls the power-up, reset, and monitoring of resources within the system

What's new in 2018.2 release

Following are the new features added in PMU Firmware in 2018.2 release:
  1. Provide read/write access to AFI configuration registers through MMIO call
  2. While configuring PLL lock errors and its actions in EM module, wait for FSBL to complete psu_init to avoid initial PLL lock errors that occurs during FSBL initialization

What's new in 2018.1 release

Following are the new features added in PMU Firmware in 2018.1 release:
  1. PMU fail safe mechanism with CSU WDT is added
  2. Implemented idle hooks for nodes USB, DP and SATA
  3. Added suppoort for graceful force powerdown of PU
    1. This is to prevent any mid-flight AXI transactions from locking up the interconnect and hanging the device
  4. Added wake on USB support to wakeup all masters for which USB is set as wakeup source
  5. Added GPO section to config object to get the initial state of PMU GPO's and configure them in PMU Firmware
  6. Added modularity of xilfpga and xilsecure features using compiler switches
  7. Added Power Off Suspend to RAM feature
  8. Added support for resetting GPIO5 resets going to PL
  9. Added API to support secure single partition image

What's new in 2017.4 release

Following are the new features added in PMU Firmware in 2017.4 release:
  1. Exported efuse IP disable as part of version string in PmGetChipid to recognize eg/cg/ev devices

What's new in 2017.3 release

Following are the new features added in PMU Firmware in 2017.3 release:
  1. Added three level debug prints support in PMU Firmware application
  2. Added support to PMU EM module to set/remove the error action for any error at run time using IPI
  3. Added support to log EM errors that come to PMU and send when the target requests over IPI
  4. Added SRST support for FPD WDT
  5. Added xilsecure API calls to support xilsecure functionality from Linux

Overview of PMU Firmware

The Platform Management Unit (PMU) in Zynq MPSoC has a Microblaze with 32 KB of ROM and 128 KB of RAM. The ROM is pre-loaded with PMU Boot ROM (PBR) which performs pre-boot tasks and enters a service mode. For more details on PMU, PBR and PMUFW load sequence, refer to Platform Management Unit (Chapter-6) in Zynq MPSoC TRM (UG1085). PMU RAM can be loaded with a firmware (PMU Firmware) at run-time and can be used to extend or customize the functionality of PMU. Some part of the RAM is reserved for PBR, leaving around 125.7 KB for PMU Firmware.

Here is the memory layout of PMU RAM:
The PMU Firmware provided in SDK, comes with a default linker script which aligns with this memory layout and there is no specific customization required from user.


PMU Firmware is designed to be modular and enables adding new functionality in the form of modules. Each functionally distinct feature is designed in as a module, so that PMUFW can be configured to include only the required functionality for a user application. This type of modular design allows easy addition of new features and as well as optimizes memory footprint by disabling unused modules.

All the common functions that may be required by the modules are organized as separate libraries in PMUFW with APIs clearly specified. The included APIs in PMU Firmware are given below:
  1. ROM Services API
  2. Reset Services API
  3. BSP/Utility API

These APIs can be used by the modules in PMUFW to perform the specified actions as required.

Each module can be provided with three handlers which are called in during the respective phases as described below:
Module Handler
API for Registering the Handler
execution context
Called during the init of the core to configure the module, register for events or add scheduler tasks. This can be used to load the configuration data into the module if required.
XPfw_CoreSetCfgHandler(const XPfw_Module_t *ModPtr, XPfwModCfgInitHandler_t CfgHandler);
Event Handler
Called when an event occurs (module should have registered for this event, preferably during the init phase
XPfw_CoreSetEventHandler(const XPfw_Module_t *ModPtr, XPfwModEventHandler_t EventHandler);
IPI Handler
Called when an IPI message with respective module-id arrives
XPfw_CoreSetIpiHandler(const XPfw_Module_t *ModPtr, XPfwModIpiHandler_t IpiHandler, u16 IpiId);
PMUFW has a default set of modules which address most of the common use case for Power Management and Error Management. these modules can be taken as references for implementation of custom modules.

Inter-Processor Interrupts(IPI) Handling in PMUFW

PMU has 4 Inter-Processor Interrupts(IPI) assigned to it and one set of buffers. By default, PMUFW uses IPI-0 and associated buffers for all message exchange with other processors on the SoC. PMUFW uses IPI driver to send and receive messages. An IPI manager layer is implemented over the driver and it takes care of dispatching the IPI message to the registered module handlers based on IPI ID in the first word of the message. The message format for IPI is given below:
<target_module_id, api_id>
Module dependent payload
RESERVED – for future use

IPI-1 is used for a special purpose in warm-restart to trigger quiescening of APU cores by ATF. IPI-2 and IPI-3 are reserved.
Currently PM and EM module uses IPIs and this can be taken as reference for implementing custom modules which require IPI messaging.

Building PMU Firmware using SDK

  1. Open XSDK
  2. Create a new application with :
    1. Name your project / Board support package
    2. OS Platform : Standalone
    3. Hardware Platform : ZynqMP_ZCU102_hw_platform
    4. Processor : psu_pmu_0
  3. Click on next at the bottom. You will see "ZynqMP PMU Firmware" in the available templates.
  4. Click on Finish to generate PMUFW.
  5. Connect to the local board and test the connection. You should see a pop up showing that the connection was established successfully.
  6. Connect to the COM port on the terminal to view the UART prints.
    - PMUFW uses psu_uart_0 as default STDOUT. This can be changed to other UARTs using the "Modify BSP Settings" dialogue.
    To enable debug prints from PMUFW, add DEBUG_MODE to the defined symbols list in build settings dialog.- [Important] When PMUFW logging is enabled, power management for the logging UART port will be disabled. Because of that, some system-wide power management operations will also be affected (e.g. suspend/resume operations may not work properly.) Therefore, PMUFW logging should be enabled only when necessary.5-snap.PNG
  7. On XSCT Console, Connect to the board and Run the PMU firmware.

  8. View the PMU firmware prints on the Terminal console

Debugging PMU FW using SDK

PMU FW will be built with -Os and LTO optimizations by default.

If the user need to disable the optimization (for debugging), two things need to be done:
Since removing optimization results in increase of code size and can result in not being able to build PMU FW, some of the features that the user don’t use, need to be disabled by removing build flags from project settings. And to further disable some features, it can be disabled in xpfw_config.h file of PMU FW
To disable/modify Optimizations, below changes need to be done:
PMU FW application: In "Miscellaneous" section, need to remove/modify highlighted options below:

IMPORTANT NOTE: It has to be noted that the compiler “Optimization” screen in SDK cannot sense the optimization selected through “Miscellaneous” flags screen (above). This means “Optimization” screen still shows “-O0”, which can be misleading to the users (as shown below).

Below are the steps to debug PMU FW application using SDK:
  1. Right click on the application to "Debug As" and click on “Debug Configurations”.
  2. Right click on System Debugger and Click "New". You get a "New Configuration". Click on Debug.
  3. Choose the Debug perspective. Click OK.
  4. You will now see the debug perspective and PMU firmware will run.
  5. Place the break points to control the flow and rerun for debugging.

Loading PMU Firmware in JTAG boot mode

From 2017.1, PM operations depend on the configuration object loaded by FSBL. So it is mandatory to load PMU FW before loading FSBL. This is taken care in device boot modes, but in JTAG boot mode, user need to specifically ensure this.
Following are the steps for JTAG boot mode:
  1. For Silicon v3.0 and above, PMU Microblaze is not visible in xsdb. Hence disable security gates to view PMU Microblaze
  2. Load PMU FW and run
  3. Load FSBL and run
  4. Continue with U-Boot/Linux/user specific application
Following is the complete TCL script:
#Disable Security gates to view PMU MB target
targets -set -filter {name =~ "PSU"}
mwr 0xffca0038 0x1ff
after 500
#Load and run PMU FW
targets -set -filter {name =~ "MicroBlaze PMU"}
dow xpfw.elf
after 500
#Reset A53, load and run FSBL
targets -set -filter {name =~ "Cortex-A53 #0"}
rst -processor
dow fsbl_a53.elf
#Give FSBL time to run
after 5000
#Other SW...
dow u-boot.elf
dow bl31.elf

Loading PMU Firmware in SD boot mode

Note: When PMUFW is loaded in a non-JTAG Boot mode on a 1.0 Silicon, an error message "Error: Unhandled IPI received" may be logged by PMUFW at startup, which can be safely ignored. This is due to the IPI0 ISR not being cleared by PMU ROM which is fixed in 2.0 and later versions of Silicon.

PMU Firmware can be loaded by either FSBL or by CSU BootROM (CBR). Both these flows are supported by Xilinx. PMU Firmware loading by CBR will be needed in the cases where the customer board has an onboard regulator that needs to be programmed to bring up the boot processor's power rail. Loading PMU Firmware using FSBL has these benefits: (i) Possible quick boot time, when PMUFW is loaded after bit-stream, (ii) In use cases where the user want two BIN files - stable and up-gradable, PMUFW can be part of the up-gradable (by FSBL) image.

Using FSBL to load PMU FW

  1. We already have pmufw.elf with us. ( See building PMU FW at the top of this page)
  2. Build an FSBL in the SDK for A53. ( R5 can also be used)
  3. Create a hello_world example for A53. Right Click on the "hello_world example" project and select "Create a boot image"
  4. Create a new bif file. Choose
    1. Architecture : ZynqMP
    2. You will see A53 fsbl and hello_world example by default in partitions. We need pmufw too.
    3. Click on Add, then provide pmufw.elf path. Also Partition type: datafile, Destination device : PS, Destination CPU : PMU
    4. Click OK.
    5. After adding pmufw as partition. Click on pmufw partition and click UP bottom.
    6. Make sure partition order
      1. A53 fsbl
      2. pmufw
      3. hello world App
    7. Click on Create Image. You will see BOOT.bin created in a new folder "bootimage" in your example project.
    8. View the .BIF file to confirm the partition order.
    9. Now copy this BOOT.bin into SD card.
    10. Boot the ZCU102 board in SD boot mode. You can see the fsbl -> pmufw ->hello_world example prints in a sequence.

Using CBR to load PMU FW

Note: When PMUFW is loaded by CBR, it is executed prior to FSBL. So the MIOs, Clocks and other initializations are not done at this point and this means that the PMUFW banner and other prints may not be seen prior to FSBL.
Post FSBL execution, the PMUFW prints can be seen as usual.
  1. To make CBR load pmufw, we just need to change the BOOT.bin boot partitions.
  2. Now steps listed above (1 -> 3) are same.
  3. Create a new bif file. Choose
    1. Architecture : ZynqMP
    2. You will see A53 fsbl and hello_world example by default in partitions. We need pmufw too.
    3. Click on Add, then provide pmufw.elf path. Also Partition type: pmu (loaded by bootrom).
    4. Click OK.
    5. Click on Create Image. You will see BOOT.bin created in a new folder "bootimage" in your example project.
    6. You can also view .BIF to confirm the partition order.
    7. Now copy this BOOT.bin into SD card.
    8. Boot the ZCU102 board in SD boot mode. You can see the pmufw -> fsbl ->hello_world example prints in a sequence.

PMU FW Build Flags

Requires these flags/build options to be enabled
Default setting
Enables detailed debug prints in PMU Firmware

This feature is supported in 2017.3 release and above

Enables debug prints for PM Module
Enables Error Management Module
Enables escalation of sub-system restart to SRST/PS-Only if the first restart attempt fails
Enables WDT based restart of APU sub-system
Enables idling and reset of nodes before force shutdown of a sub-system

Enables Power Management Module

Enables Scheduler Module

Enables WDT based restart functionality for PMU using CSU WDT
Enables STL Module

Enables RTC Event Handler Test Module

Enables CRC calculation for IPI messages

Enables FPGA bitstream loading
Enables security features
Enables debug prints for XMPU/XPPU error handling
Enables dumping clock and PLL state functions
Enables debug functions for PM
Enables idling peripherals before PS or System reset
Enables Power Off Suspend feature

Power Management in PMU FW

Zynq MPSoC Power Management framework is based on an implementation of the Embedded Energy Management Interface (EEMI). This framework allows software components running across different processing units (PUs) on a chip or device to issue or respond to requests for power management.
The PM module is implemented within the PMU firmware as an event-driven module. Events processed by the PM module are called power management events. All power management events are triggered via interrupts.
When handling an interrupt the PMU firmware determines whether the associated event shall be processed by the PM module. Accordingly, if the PMU firmware determines that an event is power management related and if the PM module is enabled the PMU firmware triggers it to process the event.
When processing a power management event the PM controller may exploit the PMU ROM handlers for particular operations regarding the state control of hardware resources.
Refer to Zynq Power Management Framework User Guide(UG1199) for details.

PM Configuration Object

The configuration object is a binary data object used to allow updating data structures in the PMU firmware power management module at boot time. The configuration object must be copied into memory by a processing unit on the Zynq UltraScale+ MPSoC. The memory region containing the configuration object must be accessible by the PMU.
The configuration object specifies:
  • List of masters available in the system
  • All the slave nodes the master is currently using and current requirement of the master for the slave configuration
  • All the slave nodes the master is allowed to use and default requirement of the master for the slave configuration
  • For each power node, which masters are allowed to request/release/power down
  • For each reset line, which masters are allowed to request the change of a reset line value
  • Which shutdown mode the master is allowed to request and shutdown timeout value for the master
  • Which masters are allowed to set configuration after the configuration is already set upon the system boot by the FSBL

PM Configuration Object Generation

PM Configuration Object is generated as part of XilPM library which is included in A53/R5 FSBL BSP. The PM Configuration Object generation is as follows:
  1. The user specifies their custom PM framework Configuration using the PCW tool
  2. PCW generates the HDF file
  3. At build time, the HDF Parser parses the HDF file and insert the config object into the FSBL code


As mentioned above, the PM Configuration Object is generated by default for FSBL. Following are the steps to create Configuration Object with any A53/R5 application:
  1. Open SDK.
  2. Click on File -> New -> Application Project. "New Project" window will appear
  3. Select "Hardware Platform" from the pre-defined hardware platform drop down list. We can also specify new hardware platform by clicking on "New" button next to "Hardware Platform" drop down box. In this, we are selecting "ZCU102_hw_platform(pre-defined)".
  4. Select Processor. Here we are selecting "psu-cortexa53_0" processor.
  5. Enter project name: test
  6. Click Next and select "Hello World" template application. Click Finish.
  7. Right click on the application BSP and select "Board Support Package Settings". BSP settings window appears as below. Select "xilpm" library and click on "Ok"
    Screenshot-Board Support Package Settings -1.png
  8. Now the BSP and application will get regenerated with xilpm library.
  9. Now configuration object is generated as part of xilpm library. To verify the same, please check bsp -> psu_cortexa53_0 -> libsrc -> xilpm_v2_4 -> pm_cfg_obj.c

Initial Configuration at Boot

At boot-up:
  1. FSBL sends the config object to PMU with the Set Configuration API
  2. PMU parses config object and configures
  3. PMU powers off all nodes which are unused after all the masters have finished initialization
All other requests prior to the first Set Configuration API call will be rejected by PMU Firmware

Error Handling in PMU FW

Error Management Hardware

Zynq MPSoC has a dedicated error handler to aggregate all the fatal errors across the SoC and handle them. Refer to the TRM/Arch Spec for details.
All fatal errors routed to Error Manager can either set to be handled by HW ( and trigger a SRST/PoR/PS Error Out) or trigger an interrupt to PMU.

Error Management in PMU Firmware

Important Note: To enable Error Management module in PMUFW, the macro ENABLE_EM needs to be defined either in the compiler flags or in file xpfw_config.c

PMU Firmware provides APIs to register custom error handlers or assign a default SRST/PoR/PS Error Out action in response to an Error. There is a specific module (xpfw_mod_em.c) already provided in PMUFW and it is enabled by default.
All error handling code should reside in this module and there are already a couple of examples on handling WDT errors.
Action for each error can be setup using XPfw_EmSetAction API:
 * Set action to be taken when specific error occurs
 * @param ErrorId is the ID for error as defined in this file
 * @param ActionId is one of the actions defined in this file
 * @param ErrorHandler is the handler to be called in case custom action
 * @return XST_SUCCESS if the action was successfully registerd
 *         XST_FAILURE if the registration fails
s32 XPfw_EmSetAction(u8 ErrorId, u8 ActionId, XPfw_ErrorHandler_t ErrorHandler);
Actions supported for the parameter ActionId are:
Action ID
Trigger a Power-On-Reset
Trigger a System Reset
Call the custom handler registered as ErrorHandler param
Trigger a PS-Error out action

List of Error IDs for ErrorId parameter:
Error ID
Errors logged by CSU Boot ROM (CBR)
Errors logged by PMU Boot ROM (PBR) in the pre-boot stage
Errors logged by PBR in service mode
Errors logged by PMUFW
Un-Correctable Errors logged by PMU HW. This includes PMU ROM validation Error, PMU TMR Error, uncorrectable PMU RAM ECC Error, and PMU Local Register Address Error.
CSU HW related Errors
Errors set when a PLL looses lock (These need to be enabled only after the PLL locks-up)
PL Generic Errors passed to PS
All Time-out Errors [FPS_TO, LPS_TO]
Auxilliary Error 3
Auxilliary Error 2
Auxilliary Error 1
Auxilliary Error 0
Error associated with the unexpected enablement of DFT features
Clock Monitor Error
Supply Detection Failure Errors
FPD System Watch-Dog Timer Error
LPD System Watch-Dog Timer Error
Asserted if any of the RPU CCF errors are generated
Asserted if any of the RPU CCF errors are generated
FPD Temperature Shutdown Alert
LPD Temperature Shutdown Alert
RPU1 Error including both Correctable and Uncorrectable Errors
RPU0 Error including both Correctable and Uncorrectable Errors
OCM Uncorrectable ECC Error
DDR Uncorrectable ECC Error

Example for Error Management (Custom Handler)

For this example OCM uncorrectable error (EM_ERR_ID_OCM_ECC) is considered. A custom handler is registered for this error in PMUFW and the handler in this case just prints out the error message. In a more realistic case, the corrupted memory may be reloaded, but this example is just limited to clearing the error and printing a message.
Adding Error Handler in PMUFW:
@@ -88,6 +88,15 @@ static void FpdSwdtHandler(u8 ErrorId)
+/* OCM Uncorrectable Error Handler */
+static void OcmErrHandler(u8 ErrorId)
+       fw_printf(ËM: OCM ECC error detected\n");
+       /* Clear the Error Status in OCM registers */
+       XPfw_Write32(0xFF960004, BBIT(7));
 /* CfgInit Handler */
 static void EmCfgInit(const XPfw_Module_t *ModPtr, const u32 *CfgData,
                u32 Len)
@@ -102,6 +111,7 @@ static void EmCfgInit(const XPfw_Module_t *ModPtr, const u32 *CfgData,
        XPfw_EmSetAction(EM_ERR_ID_RPU_LS, EM_ACTION_CUSTOM, RpuLsHandler);
        XPfw_EmSetAction(EM_ERR_ID_LPD_SWDT, EM_ACTION_CUSTOM, LpdSwdtHandler);
        XPfw_EmSetAction(EM_ERR_ID_FPD_SWDT, EM_ACTION_CUSTOM, FpdSwdtHandler);
+       XPfw_EmSetAction(EM_ERR_ID_OCM_ECC, EM_ACTION_CUSTOM, OcmErrHandler);
        fw_printf(ËM Module (MOD-%d): Initialized. \r\n",
Injecting Error using debugger (xsdb) :
;# Enable ECC UE interrupt in OCM_IEN
mwr -force 0xFF96000C [expr 1<<7]
;# Write to Fault Injection Data 0 Register OCM_FI_D0
;# Errors will be injected in the bits which are set, here its bit0, bit1
mwr -force 0xFF96004C 3
;# Enable ECC and Fault Injection
mwr -force 0xFF960014 1
# Clear the Count Register : OCM_FI_CNTR
mwr -force 0xFF960074 0
;# Now write data to OCM for the fault to be injected
# Since OCM does a RMW for 32-bit transactions, it should trigger error here
mwr -force 0xFFFE0000 0x1234
;# Read back to trigger error again
mrd -force 0xFFFE0000

The above code is in TCL for debugger. Same can be easily ported to a 'C' source by just replacing the mwr/mrd with Xil_Out32/Xil_In32

Example for Error Management ( PoR as a response to Error)

Some error may be too fatal and the system recovery from those errors may not be feasible without doing a Reset of entire system. In such cases PoR or SRST can be used as actions. In this example we use PoR reset as a response to the OCM ECC double-bit error.
Here is the code that adds the PoR as action:
@@ -102,6 +102,7 @@ static void EmCfgInit(const XPfw_Module_t *ModPtr, const u32 *CfgData,
        XPfw_EmSetAction(EM_ERR_ID_RPU_LS, EM_ACTION_CUSTOM, RpuLsHandler);
        XPfw_EmSetAction(EM_ERR_ID_LPD_SWDT, Em_ACTION_CUSTOM, LpdSwdtHandler);
        XPfw_EmSetAction(EM_ERR_ID_FPD_SWDT, EM_ACTION_CUSTOM, FpdSwdtHandler);
        fw_printf(ËM Module (MOD-%d): Initialized.\r\n",
The TCL script is same as the one for above example to inject OCM ECC error. Once you trigger the error, a PoR occurs and you may see that all processors are in reset state similar to how they would be in a fresh power on state.
PMU RAM also gets cleared off during a PoR, so PMUFW needs to be reloaded.

Adding a Custom Module

Creating a New Module

Each set of user defined routines performing a specific functionality should be designed to be a module in PMUFW. These files should be self contained and can use APIs from xpfw_core.h to call in FW routines. Each module should support the following interfaces:
1. Config Handler : Called during Init.
2. Event Handler: When a registered event is triggered
3. IPI Handler: When an IPI Message arrives with the registered IPI ID
To create a module, in the user_startup routine:
PmModPtr = XPfw_CoreCreateMod();
(void)XPfw_CoreSetCfgHandler(PmModPtr, PmCfgInit);
(void)XPfw_CoreSetEventHandler(PmModPtr, PmEventHandler);
(void)XPfw_CoreSetIpiHandler(PmModPtr, PmIpiHandler,0U)

Adding a Task to Scheduler

Tasks are functions which take void args and return void. Currently PMU Firmware has no way to check that the task returns in a pre-determined time, so this needs to be ensured by the task design. Let us consider a task which prints out a message:
void TaskPrintMsg(void)
    xil_printf("Task has been triggered\r\n");
If we want to schedule the above task to occur every 500ms, the following code can be used:
Status = XPfw_CoreScheduleTask(TaskModPtr, 500U, TaskPrintMsg);
if(XST_SUCCESS == Status) {
    xil_printf("Task has been added successfully !\r\n");
else {
    xil_printf(Ërror: Failed to add Task.!\r\n");

Registering for an Event

All interrupts that come into PMU are exposed to user as Events with specific EVENTIDs defined in xpfwevents.h; Any module can register for an event (usually in CfgInitHandler) and the module's EventHandler will be called when an event is triggered. To register for an RTC Event:
Status = XPfw_CoreRegisterEvent(ModPtr,XPFW_EV_RTC_SECONDS);

Example of an EventHandler

void RtcEventHandler(const XPfw_Module_t *ModPtr, u32 EventId)
    xil_printf("MOD%d:EVENTID: %d\r\n", ModPtr->ModId, EventId);
    if(XPFW_EV_RTC_SECONDS == EventId){
            /* Ack the Int in RTC Module */
            xil_printf("RTC: %d \r\n", Xil_In32(RTC_CURRENT_TIME));

PMU Firmware Memory Footprint

This section contains the approximate details of PMU Firmware Memory Footprint with various modules enabled.
In PMU Firmware,
  • PM and FPGA modules are enabled by default. FPGA block in PMU Firmware does the xilfpga and xilsecure functionality which performs loading of bitstream to PL, loading of secure image to memory and reading FPGA status. FPGA block does not have a separate build flag for itself and is part of PM module.
  • Error Management and Restart modules are not enabled by default
Refer to PMU Firmware Build Flags for module default setting information

Note: All of the metrics are with compilation optimized for size -Os. This optimization setting is enabled by default in SDK. To disable the same, user need to follow the steps mentioned in Debugging PMU FW using SDK section above
Size occupied (KB)
Free space (KB)
Additional Notes
PMU Firmware without detailed debug prints enabled
This is with base PMU Firmware, PM module and FPGA block

PMU Firmware with detailed debug prints enabled
Detailed debug prints are enabled when XPFW_DEBUG_DETAILED and DEBUG_MODE flags are defined
This estimation is with combination of (1) and (2)
PMU Firmware with Error Management Module enabled
Error Management module is enabled when ENABLE_EM flag is defined
This estimation is with combination of (1) and (3)
PMU Firmware with Restart Module enabled
Restart module is enabled when ENABLE_RECOVERY and ENABLE_ESCALATION flags are defined
This estimation is with combination of (1) and (4)
PMU Firmware with debug prints and EM and Restart modules enabled

This estimation is with combination of (1), (2), (3) and (4)

Examples to enable/disable modules

  1. PM module is enabled by default with ENABLE_PM build flag. This build flag is defined in <PMU Firmware Application>/src/xpfw_config.h file. To disable PM Module, user need to make changes to xpfw_config.h file by removing/commenting defined ENABLE_PM flag.
  2. All other build flags can be enabled by following the below steps.
    1. Right click on the PMU Firmware project and select "C/C++ Build Settings" option. Properties window appears
    2. Select "Settings" from "C/C++ Build" options. In "Tool Settings" tab, select "Symbols" from "Microblaze gcc compiler" option
    3. Click on "Add" under "Defined symbols (-D)"
    4. Enter flag name to define and click "Ok"
    5. Again click "Ok" on properties window and the application will start building with the new compile flags defined

Registers reserved for PMU Firmware

Following are the general storage registers used by PMU Firmware
  1. 0xFFD80040 (PMU_GLOBAL_GLOBAL_GEN_STORAGE4 - bit 0) -> This register bit needs to be written by upper layer APU applications. So that, in case of FPD WDT error (and when ENABLE_RECOVERY and CHECK_HEALTHY_BOOT macros are defined), PMU checks this register to find out if previous boot was successful and does subsystem restart only if last boot was successful
  2. 0XFFD80040 (PMU_GLOBAL_GLOBAL_GEN_STORAGE4 - bit 16) -> Written by PMU Firmware, FSBL uses this register bit to know if reset is APU only reset
  3. 0XFFD80044 (PMU_GLOBAL_GLOBAL_GEN_STORAGE5) -> Written by FSBL, PMU Firmware uses this register to know if psu_init is completed by FSBL. Since 2018.1, this check is performed to initialize and start the CSU WDT timer when ENABLE_WDT macro is define
FSBL also uses few general storage registers. Please refer to this link in FSBL wiki for the list of registers reserved for FSBL

Related Links