Overview of PMU Firmware

Modules

1. ROM Services API
2. Reset Services API
3. BSP/Utility API

Inter-Processor Interrupts(IPI) Handling in PMUFW

IPI-1 is used for the callbacks from PMU to other masters and for communication initiated by PMUFW.

Currently, PM and EM modules use IPIs and this can be taken as reference for implementing custom modules which require IPI messaging.

Building PMU Firmware using Vitis

1. Open Vitis
2. Create a new application with File->New→Application Project...:
   1. Enter project name and click on Next. Eg: pmufw
      
   2. Select platform as "zcu102" from "Create a new platform from hardware (XSA)" tab options. Click on Next
      
   3. Now select the domain option as below and click on next
      1. CPU: psu_pmu_0
      2. OS: standalone
      3. Language: C
         
   4. Select "ZynqMP PMU Firmware" template from Templates list and click on Finish.
      
   5. After this, PMU project will be created. Right click on the project and select "Build Project" to build PMU Firmware.
3. Connect to the local board and test the connection. You should see a pop up showing that the connection was established successfully.
   

4. Connect to the COM port on the terminal to view the UART prints.

   Info
   title IMPORTANT
   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 and/or XPFW_DEBUG_DETAILED to the defined symbols list in build settings dialog. Additionally, Xilinx tools default to loading PMUFW from CBR in which case any early/init prints will not be seen.  See Using FSBL to load PMUFW for more details. Attention: 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. 
6. On XSCT Console, Connect to the board and Run the PMU firmware.
   
7. View the PMU firmware prints on the Terminal console

Debugging PMU FW using Vitis

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 Vitis 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

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

Power Management in PMU FW

Adding a Custom Module

Creating a New Module

PmModPtr = XPfw_CoreCreateMod();
(void)XPfw_CoreSetCfgHandler(PmModPtr, PmCfgInit);
(void)XPfw_CoreSetEventHandler(PmModPtr, PmEventHandler);
(void)XPfw_CoreSetIpiHandler(PmModPtr, PmIpiHandler,0U)

Adding a Task to Scheduler

void TaskPrintMsg(void)
{
    xil_printf("Task has been triggered\r\n");
}
 

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

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_Out32(RTC_RTC_INT_STATUS,1U);
            xil_printf("RTC: %d \r\n", Xil_In32(RTC_CURRENT_TIME));
    }
}

PMU Firmware Memory Footprint

• 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

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

1. 0xFFD80034 (PMU_GLOBAL_GLOBAL_GEN_STORAGE2) → Since 2018.1 if POS is enabled, FSBL waits till PMU has finished resuming by polling this register. Users are free to use this register after reset so it can still be considered as "reserved for customers".
2. 0xFFD80038 (PMU_GLOBAL_GLOBAL_GEN_STORAGE3) → Since 2018.1 if POS is enabled, PMU waits till FSBL has finished reading the boot type. This additional handshake step is required in boot scenarios where FSBL is started by CSU. PFW must wait for CSU to trigger FSBL start otherwise there may be race condition where PFW is trying to restore state of processor as part of resume from Power Off Suspend sequence while CSU is trying to run FSBL on that same processor. Users are free to use this register after reset so it can still be considered as "reserved for customers".
3. 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.
4. 0xFFD80040 (PMU_GLOBAL_GLOBAL_GEN_STORAGE4 - bits 1 and 2) → Since 2018.3, these bits are used to know the status of RPU 0 and RPU 1 usage which will be updated by FSBL. Based on this information, PMU will decide whether to shutdown the unused RPU cores or not.
5. 0xFFD80040 (PMU_GLOBAL_GLOBAL_GEN_STORAGE4 - bits 3 and 4) → Since 2018.3, these bits are used to set the restart scope to ATF in case of WDT restart.
6. 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.
7. 0XFFD80044 (PMU_GLOBAL_GLOBAL_GEN_STORAGE5 - bit 0) → Written by FSBL, PMU Firmware uses this register to know if FSBL has completed its execution. Since 2018.1, this check is performed to initialize and start the CSU WDT timer when ENABLE_WDT macro is defined.
8. 0XFFD80044 (PMU_GLOBAL_GLOBAL_GEN_STORAGE5 - bits 1 and 2) → Written by FSBL. PMU Firmware uses these bits to know if FSBL is running on which processor. 01: APU, 10: RPU0, 11: RPU LS
9. 0xFFD80044 (PMU_GLOBAL_GLOBAL_GEN_STORAGE5 - bits 16 to 23) → Since 2018.3, XilFPGA library in PMU uses these bits to store the PL state to know whether secure bit-stream or non-secure bit-stream or no bit-stream loaded. This information is used by XilFPGA Readback feature to dis-allow readback in case secure bit-stream is loaded.
10. 0xFFD80050 (PMU_GLOBAL_PERS_GLOBAL_GEN_STORAGE0) → This register is used to store Exception Status Register (ESR) value of the PMU Microblaze register when any exception occurs.
11. 0xFFD80054 (PMU_GLOBAL_PERS_GLOBAL_GEN_STORAGE1) → This register is used to store Exception Address Register (EAR) value of the PMU Microblaze register when any exception occurs.
12. 0xFFD8006C (PMU_GLOBAL_PERS_GLOBAL_GEN_STORAGE7 - bit 3) → Since 2018.3, PMU is using this bit to indicate FSBL whether DDR is in self-refresh mode or not. PMU will set this bit if DDR is in self-refresh during warm-restart and clears after the restart.

And 0xFFD8004C (PMU_GLOBAL_GLOBAL_GEN_STORAGE7) is used by PMU_ROM. This register is used in case we encounter problems with the PL Power Up routine in which ROM does not wait long enough for the PL to come out of reset. The time ROM waits can be extended by increasing the value of this register.