UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 

ZynqMPSoC PMU Firmware - Build and Run

Moderator
Moderator
4 0 521

Introduction:

The Platform Management Unit Firmware (PMUFW) is a part of the software stack on Zynq® MPSoC devices that users expect to work out of the box, and so don't tend to pay much attention to until something goes wrong.

However, as the name states, this software manages the whole platform, so it has a huge impact on a lot of use cases that you might be using right now.

This blog entry is intended to be the starting point of a series where I will be covering different aspects of the PMU Firmware, from building or debugging it up to discovering its role in different system use cases.

Welcome to the PMU Firmware blog posts!

Zynq MPSoC PMU Firmware - Build and Run

 

Build

There are usually two flows to create and build a PMU Firmware image for the target, Xilinx SDK or PetaLinux/Yocto.

Under the hood the PetaLinux/Yocto flow makes use of Xilinx SDK so in this blog all of the steps will be done using SDK as it eventually applies for both use cases.

The PMU Firmware is provided as a template application for the PMU processor for any hardware platform including the Zynq MPSoC device.

The steps required to create and build it can be applied by selecting the appropriate platform, processor, and template.

001_pmufw.JPG

By default, Xilinx SDK has the "Build Automatically" setting enabled, so after a while the PMUFW application will be compiled and the console output will display the size of the ELF file as shown below.

pmufw_003.JPG

The default PMU Firmware application (115048 bytes = 112 KB) occupies almost the entire RAM memory available in the PMU (128 KB as documented in (UG1137)), so there are a few things that needs to be taken into account when playing around with the PMUFW.

The default compiler flags have been set up to optimize the code as much as possible both in the BSP and in the application code, setting the optimization level for size (-Os) and enabling link time optimization (-flto -ffat-lto-objects).

002_pmufw.png

As described in (UG1137), the PMU firmware is architected in a modular way so that it can be customized and extended according to the user's needs. However the default image only has some of the basic functionality enabled. The list of available PMU Firmware Build flags can be found in (UG1137) or the PMU Firmware default config file.

Run

Once the PMU firmware is built, it is ready to be loaded and executed in the target. The following debugger settings can be used to do so.

As shown below, the "Reset entire system" and "Run psu_init" checkboxes have been enabled to ensure that on every single session launch, the target starts in a known well defined state (Reset system with the PS configured according to the hardware platform settings).

003_pmufw.png

The serial console output prints the expected PMU Firmware banner after the execution of the application is resumed in the debug session.

pmufw_008.JPG

The steps provided here are enough to run the PMU firmware on the target, but it does not make much sense to have ONLY the PMUFW running on the target, as the platform management firmware always goes alongside application code running either on the APU or RPU.

A meaningful example is the FSBL application code, which from the early stages of a device boot sequence expects to have a PMU Firmware running on the target.

pmufw_009.JPG

To emulate or reproduce a boot image use case as closely as possible, you need to understand the different boot sequences related to the PMUFW. As described in (UG1137), the PMU Firmware can be either loaded by the CSU BootROM (CBR) or the FSBL.

Both use cases are supported by Xilinx and each one has its own advantages and disadvantages.

The output in the serial port differs in both cases because when the PMU Firmware is loaded by CBR the serial port has not yet been initialized by the FSBL initialization code.

Below you can see the boot image configuration files and the serial port output for both use cases:

006_pmufw.png

The first use case is quite straightforward to reproduce with the Xilinx SDK Debug Configuration wizard. It only requires that you add both FSBL and PMUFW applications to the corresponding targets.

Because the FSBL is in charge of initializing the processing subsystem, there is no longer a need to select the psu_init checkbox in the configuration, and you can just keep the "System Reset" option selected to start the debug session from a well known reset state.

By default, the debugger places a breakpoint at the main function, but as long as the PMUFW does not have a function named main, it will execute the whole application code without stopping, while the FSBL will hit the breakpoint at the main function.

As a result, just resuming the execution of the FSBL reproduces the use case where the CBR loads the PMUFW prior to the the FSBL execution.

004_pmufw.png

The second use case is bit more complicated to reproduce with the debugger, as it requires that the PMUFW be loaded after the FSBL starts the execution, but prior to when it attempts to initialize the PM.

To prevent the PMU Firmware from executing after being loaded in the target, select the "Stop at program entry" option in the Application tab. To stop the FSBL execution prior to the PM initialization, place a breakpoint in the InitializePM function.

Unfortunately, the FSBL application is also optimized by default, so not all of the functions are present in the symbol file.

However when you take a look at the code, if you place a breakpoint in the Xil_DCacheDisable function it behaves in a similar way, so it can be used for this use case.

005_pmufw.png

Once the debug session is launched, both processors (PMU and A53#0) will be loaded with the corresponding applications and the APU will start the execution, which will continue until the breakpoint in the main function is reached.

pmufw_015.JPG

When you resume the execution of the A53#0 processor, it will end again with the target hitting the next breakpoint at the XilDCacheDisable function, allowing the FSBL to execute the processing system initialization.

At this stage the PMU processor can be resumed, so that when the PMU Firmware is executed it will reproduce the execution timing of the use case where the PMUFW is loaded by the FSBL.

pmufw_016.JPG

Taking a look at the serial output confirms that the PMU Firmware has been executed after the PS initialization, providing the banner of both applications in the same way for the boot image use case, as shown below:

pmufw_017.JPG