This page provides information related to the Versal Platform Loader and Manager (PLM). 

Table of Contents

PLM Overview

The Platform Management Controller (PMC) in Versal has two Platform Processing Units (PPUs) to run Boot ROM and PLM respectively. PLM runs on the PPU Microblaze in PMC. PPU has 384 KB of PPU RAM and 128 KB of PMC RAM. PLM is responsible for doing the system initialization, booting and configuration of various devices as a part of Loader. It also takes care of secure boot which are authentication and/or decryption. After the initial boot is complete, PLM is responsible for Error Management, Partial Reconfiguration, Subsystem Shutdown/Restart, Health Monitoring and Soft Error Mitigation and remains active throughout the lifetime of the system.

During the initial boot, the Boot ROM decodes the Programmable Device Image (PDI) and loads the PLM into the PPU RAM. Once the PLM starts running, it will decode and process the rest of the PDI and boot up the system by loading the partitions present in the PDI. PLM also supports loading of the partial PDIs during run time.

Configuration Data Object

Configuration Data Object (CDO) contains set of commands which are required for configuring various components in the system. Any system configuration in Versal will come in the form of a CDO to PLM. These files are generated by the tools and are input to PLM. The CDO commands are registered by each module during module initialization phase. PLM decodes and passes this information to various modules for configuration. PLM copies the CDOs to PMC RAM in 64K chunks, decodes and processes them.

Please refer to UG1283 for PDI Specification

Modules in PLM

The PLM is designed with a modular subsystem-based configuration, and task-based services. Each functionally distinct feature is designed as a module. The PLM application layer contains the module initialization and start-up tasks. Depending on the modules selected in the configuration, different modules are initialized. Modules can register event handlers, IPI handlers, CDO commands, and scheduler events with the PLM interface layer.

Following are the list of modules present in the PLM:

1. XilPLMI

2. XilLoader

3. XilPM

4. XilSecure

5. XilSEM

User Modules

Apart from the above-mentioned list of modules, PLM also allows user to define their own modules if required. A compile time option “user_modules_count” is available to enable this. (Refer PLM Feature Configuration section below.) By default, this count is set to zero to save on code size. Once user sets this to any non-zero value, the configured number of user module IDs will be made available from base value of 0x81 sequentially. User can define necessary APIs in the modules and register them using XPlmi_ModuleRegister API available in xilplmi.

Building PLM

PLM can be built using Vitis and XSCT. PetaLinux uses XSCT flow to generate PLM elf while generating PetaLinux project. Please refer to <tbd page> for PetaLinux flow. Also, Vivado generates a pre-built PLM with plm.elf name.

Using Vitis

Following are the steps to generate PLM elf using Vitis tool. Additionally, please refer to UG1305 to build PLM application

1. Open Vitis

2. Create new application project with File → New → Application Project…

   1. New Application Window will pop up as shown below.

      Open

      

   2. Click on “Next”. Select “Create a new platform from hardware (XSA)”, provide XSA File in “Platform” window and click on “Next”.

      Open

      

   3. In “Application Project Details”, Select psv_pmc_0 processor and enter “Application project name” as “plm”.

   4. Click on Next.

   5. Select “versal PLM” in Templates window and click on “Finish”.

3. This would create PLM application with “plm_system” name along with the BSP.

4. Right-click on “plm_system” folder and click on “Build Project” to build PLM and generate elf.

Using XSCT

Following are the steps to generate PLM elf using XSCT:

These steps will create and build PLM. PLM elf can be found at plm/Debug/plm.elf

Generating Boot Image

Boot image can be generated using BootGen command. We need to create a BIF file to generate Boot image. Also, please refer to UG1283 for more details on this.

1. We already have PLM elf with us. Check the previous section to build PLM.

2. Create and build PSM Firmware elf for PSM Microblaze.

3. Create required applications for A72/R5, AIE, CPM etc.

4. Create BIF file (boot.bif) with the below format

   all: { id_code = 0x14ca8093 //Add ID_CODE as per the Hardware extended_id_code = 0x01 id = 0x2 image { name = pmc_subsys, id = 0x1c000001 {type = bootloader, file = ./plm.elf} {type = pmcdata, load = 0xf2000000, file = ./pmc_data.cdo} } image { id = 0x4210002, name = lpd {type = cdo, file = ./lpd_data.cdo} {core = psm, file = ./psm_fw.elf } } image { id = 0x18700000, name = pl_cfi {type = cdo,file = ./design.rcdo} {type = cdo,file = ./design.rnpi} } image { id = 0x420c003, name = fpd {type = cdo, file = ./fpd_data.cdo} } image { id = 0x4218007, name = cpm { type = cdo, file = ./cpm_data.cdo} } image { id = 0x1c000000, name = def_subsystem { load = 0x1000, file = ./system.dtb} { load = 0x10000000, file = ./image.ub} { core = a72-0,exception_level=el-3, trustzone, file = ./bl31.elf} { core = a72-0,exception_level=el-2, file = ./u-boot.elf} { load = 0x4000000, file = ./rootfs.cpio.gz.u-boot} } image { id = 0x1c000000, name = def_subsystem { core = r5-lockstep, file = ./rpu_hello.elf} } }

    

5. Below is the BootGen command to generate Boot image with the above boot.bif file.

   bootgen -arch versal -image boot.bif -w -o BOOT.BIN

Boot Modes

Following are the boot modes supported in Versal:

1. SD/eMMC

2. QSPI

3. OSPI

4. Slave device boot modes

   1. JTAG

   2. Select MAP

5. USB (Only supported as secondary boot device)

6. PCIe (Only supported as secondary boot device)

For more information, please refer to UG1304

Loading Boot Image on Hardware

We have created BOOT.BIN in “Generating Boot Image” section above. This image can be used to boot the Versal Hardware in any boot mode mentioned in “Boot Modes” section. In this section, we will see the steps to boot Versal in JTAG and SD boot mode.

In JTAG Boot Mode

Following are the steps to boot Versal Hardware in JTAG boot mode:

1. Set the boot mode pins to JTAG on Hardware, power on and connect to board.

2. Launch xsdb and connect to Hardware.

3. Once the Hardware is connected, you will see the following targets when “ta” command is issued on xsdb terminal.

4. Issue the following command to program the Hardware in JTAG boot mode.

5. Once the Hardware is booted, PLM, PSM and the other application prints will come on the console in the sequence of the images mentioned in BIF file.

6. Please refer to Debugging Tips section for more details on how to read PLM memory log and other debug tips.

In QSPI Boot Mode

Following are the steps to boot Versal Hardware in QSPI boot mode. Please refer to UG908 for more details.

1. Initially, boot Versal in JTAG boot mode till U-Boot.

2. Execute the following command in U-Boot on serial console to probe the flash device

3. On xsdb terminal, execute the following commands to write QSPI boot image to DDR

4. Then on serial console, execute the following commands in U-Boot to erase the flash memory and write the boot image to QSPI Flash

5. Change the boot mode to QSPI and boot. It will boot the Versal Hardware in QSPI boot mode and loads the boot image that we have written to QSPI flash using the above mentioned steps.

In OSPI Boot Mode

Following are the steps to boot Versal Hardware in OSPI boot mode. Please refer to UG908 for more details.

1. Initially, boot Versal in JTAG boot mode till U-Boot.

2. Execute the following command in U-Boot on serial console to probe the flash device

3. On xsdb terminal, execute the following commands to write OSPI boot image to DDR

4. Then on serial console, execute the following commands in U-Boot to erase the flash memory and write the boot image to OSPI Flash

5. Change the boot mode to OSPI and boot. It will boot the Versal Hardware in OSPI boot mode and loads the boot image that we have written to OSPI flash using the above mentioned steps.

In SD0/SD1/eMMC Boot Mode

Following are the steps to boot Versal Hardware in SD0 boot mode. Please refer to UG908 for more details.

1. Initially, boot Versal in JTAG boot mode till U-Boot.

2. Execute the following command in U-Boot on serial console to probe the emmc device

3. On xsdb terminal, execute the following commands to write the boot image to DDR

4. Then on serial console, execute the following commands in U-Boot to write the boot image to eMMC device

5. Change the boot mode to SD0_LS/SD1_LS/SD1/eMMC and boot. It will boot the Versal Hardware in SD/eMMC boot mode and loads the boot image that we have written to SD/eMMC flash device using the above mentioned steps.

Note: The boot image can be directly copied to SD card and boot as well.

Secondary Boot

Any of the boot devices supported for secondary boot mode can be used as secondary boot device. Please refer to UG1283 for more details on secondary boot. Following are the steps for secondary boot process:

1. PLM elf, LPD, Topology and PMC CDO and PSM elf must be part of primary boot image and any other images can be part secondary boot image.

2. Specify the secondary boot device in the bif file. For example, if QSPI is chosen as secondary boot device and the secondary boot image stored at 0xC000000 location in QSPI, specify the same in primary boot image bif file before providing any image. Example bif file for primary boot PDI:

    

3. When boot_device parameter is found in bif, BootGen will place the secondary boot device and secondary boot image details in image header table in meta header.

4. When PLM sees this information, it will initialize the secondary boot device if it is other than primary boot device and will read the specified location and loads the secondary boot image.

5. Example bif file for secondary boot PDI is below. Secondary boot PDI need to be generated and need to be copied to the boot device location as mentioned in the primary boot bif file. In this case, secondary boot image need to be copied to 0xC000000 location in QSPI Flash.

PLMI

The PLM Interface (XilPLMI) is a low-level interface layer for the PLM main application and other PLM modules. XilPLMI provides the common functionality required for the modules that run with PLM. Each new module can register itself with the supported command handlers which are executed based on the request received from other modules or from other subsystems. For more details on PLM modules, please refer to UG1304.

The XilPLMI layer provides the following functionalities:

• Interface for parsing CDO commands and execution of the corresponding CDO command handler of any module.

• Implementation for general PLM CDO commands

• Interface for registering handlers for commands that can be part of CDO/IPI

• Interface for scheduler timer events

• Debug print levels and common utilities

• Task Dispatcher

• Interface to set error actions and register notifications for error events

• Framework to update the PLM health periodically

• Logging PLM terminal prints and the image trace log to the memory

Please refer to CDO spec for the list of CDO/IPI commands supported by XilPLMI.

IPI Handling

IPI is a key interface between PLM and other processor entities on Versal. PMC has a dedicated IPI channel assigned to it. PLM uses this IPI channel and its associated buffers for communication, which is initiated by other masters on Versal to PLM.

Data that is sent through IPI follows the same format of CDO. PLM uses IPI driver to send and receive IPI messages. PLMI implements IPI manager layer over the driver and it takes care of dispatching the IPI messages to the registered modules based on Handler and API ID in the IPI header.

PLMI implements IPI APIs provided for other Modules to perform the following actions:

• Initializing and enabling IPI interrupts

• Send IPI Message/response to a processor

• Receive IPI Message/response to a processor

• Dispatch received IPI message to corresponding registered module

Task Modeling in PLM

PLM provides a very simple run-to-completion time-limited priority task loop model to get real-time behavior. This means that the main program is a simple loop that looks up the next task (typically a pointer to a function to be executed with a corresponding context data structure) from a queue of tasks and calls the function (executes the task) with the context as a parameter. Any interrupt that occur while the task is running, will obviously interrupt the execution, but since you are only allowed to do extremely simple things at interrupt level (i.e., disable interrupt and add a new task to the task queue), the task is logically executed in one chunk.

The complexity with the run-to-completion model comes when a particular task needs to run longer. If that happens, the task needs to be split into multiple events. There are three priority task queues, with Critical, High and Normal priority, Task dispatcher will check the priority queues in order and execute the Critical priority task handlers first. After executing task handler, dispatcher will check the task queues again and execute the next handler. If there are multiple tasks present in same queue, tasks will be executed one by one. All the tasks run to completion till task handler returns (i.e., there is no preemption). With no preemption, there will not be any need for locks and synchronization issues. Once the task is completed, it will be removed from the queue.

The priority order of the tasks are as below:

1. Critical priority tasks (XPLM_TASK_PRIORITY_CRITICAL)

2. High Priority tasks (XPLM_TASK_PRIORITY_0)

3. Normal Priority tasks (XPLM_TASK_PRIORITY_1)

The general specifications for each PLM module are

1. Run nothing in interrupt context; instead, add the necessary priority task to the task queue.

2. To allow PLM to move on to the next high-priority task, the running task must not take longer time.

3. No task should obstruct resources such as DMAs or CFI for longer duration.

Since PLM supports three priority tasks (Critical, High and Normal priority), below example shows how the user can create a high priority task within PLM

In the above example code, XPLM_TASK_PRIORITY_0 is passed to the XPlmi_TaskCreate function along with the task handler to create a task with high priority. Similarly, If user wants to create a Normal priority task, XPLM_TASK_PRIORITY_1 needs to be passed as priority argument for XPlmi_TaskCreate function.

Scheduler

Scheduler is a simple timer-based functionality to support execution of periodic/non-periodic tasks. A scheduler is required by modules such as XilSEM to support periodic tasks such as SEU detection scan operations. Scheduler also supports Critical, High and Normal priority tasks. The Critical priority tasks are given priority over High and Normal priority tasks.

Adding a task to scheduler

Tasks are functions which take void args and return the state of the task handler. Currently, PLM 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:

If we want to schedule the above task to occur every 100ms with highest priority, the following code can be used:

Removing a task from Scheduler

If we want to remove the previously scheduled task from the scheduler task list, the following code can be used:

Image Store

The Image Store feature allows PDI files to be stored in memory (DDR) and later be used to load specified images within the PDI. This is intended to allow partial reconfiguration, subsystem restart, etc without depending on external boot devices.
Also, this Image Store can be used as the Secondary Boot Device to use the PDI’s saved in the DDR.

PLM will have access to a dedicated DDR Location for storing of these user requested PDI's, the allocated DDR location address and size is Populated in the pre-defined RTCA region space for PLM to get the Image Store config details.

Currently user need to add below config at the end of “pmc_data.cdo” file before building the Boot PDI.

write 0xF2014288 <High 32bit addr> #Image Store Address High 32bit
write 0xF201428C <Low 32bit addr #Image Store Address Lower 32bit
write 0xF2014290 <Allocate size> #Image Store Allocated Size

*This above size which we give here is basically the total Image store memory allocated where multiple PDI’s are stored once the PDI add request is made.
Eg:

A new <PDI ID> field is added to the Add & Remove Image Store IPI command

This command adds PDI address to the list of Image Store PDIs that are maintained by PLM. During restore or reload of a image, PLM checks this dynamically added list of PDIs first to get the required image and in case of any failure, it falls back to next possible. If no valid entry is present, it uses boot pdi, which is the first entry in the list. 

This command removes PDI address from the list of Image Store PDIs that are maintained by PLM.

Also we can add the PDI via Boot Bif which will be part of CDO command (write image store) , in example below 2 pdi's will be added as a part of Image Store, 

Bif Example format below

write_image_store_pdi_1:
{
id_code = 0x14ca8093
extended_id_code = 0x01
id = 0x1
image
{
name = subsystem
id = 0x1c000008
partition
{
id = 0x9
core = a78-0
file = a78_0_ddr.elf
}
}
}

new_bif: {

}

Image Store can also be used the Secondary Boot Device , as shown below via Boot Bif.

 boot_device { imagestore, address = <Pdi id> }

e.g : Secondary Boot from Image Store

As show below PLM will process the PDI and add the Images with PDI ID 10,12 to the Image Store and after that will check if any Secondary Boot Mode is specified and sees source is Image Store with PDI ID 12,

it then starts processing the partial PDI from Image Store.

new_bif: {

}

Load Partial PDI is extended to support loading via Image Store

Examples :

Error Handling in PLM

Error Management HW

The Versal device has a dedicated error handler in PMC and PSM 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 PMC/PSM Error Manager can either set to be handled by HW ( and trigger a SRST/PoR/PS Error Out) or trigger an interrupt to PMC/PSM.

Error Management in PLM

The PLM Error Manager provides APIs for assigning a default error action for errors present in PMC and PSM in response to an error. During initialization of the PLM modules, the PLMI initializes the Error Manager, enables errors, and sets error action for each error in accordance with the Error Table structure defined in the xplmi_err.c file.

Following are the error actions supported by PLM for each error in PMC and PSM:

1. POR - Power On Reset

2. SRST - System restart

3. CUSTOM (Not supported through CDO)

4. PS Error Out - Error Out

5. Subsystem Shutdown - Shutdown of a specific subsystem

6. Subsystem Restart - Restart of a specific subsystem

7. No Action

8. Register notifier - Notifying a specified subsystem when error occurs

Error Management CDO commands

The following CDO commands are supported by the PLM error management module.

Set Em Action

This command is used to set error action for the specified Error Event ID and Error Mask. Refer to xil_error_node.h file for the list of Error Event IDs supported and Error Masks supported. Currently error management APIs are not supported over IPI.

Actions:

• Invalid – 0x0

• Power On Reset  – 0x1

• System Reset – 0x2

• Custom Action – 0x3 (Not supported)

• Error Out – 0x4

• Subsystem Shutdown – 0x5

• Subsystem Restart – 0x6

• None – 0x7. Disable all actions on the Event and clear error status

Note: For PSM error events, the command returns failure if LPD is not initialized.

**Setting subsystem action :

Any subsystem / core can use above command to request to set the subsystem actions via IPI, PLM will auto detect the subsystem from where the request is initiated and assigns Shutdown / restart action on that subsystem

on errors in the requested node and mask.

Register Notifier for EM Events

EM supports notifying a subsystem when registered error occurs, using the register notifier API supported by XilPM. Use this command to register for notifications when registered errors occur. Refer to xil_error_node.h for a list of supported error event IDs and error masks.

• Node ID: Can either be a Device ID or Error Event ID. Use an Error Event ID for registering error events.

• Event Mask

  • For Device ID: Event Type

  • For Error Event ID: Error Mask

• Argument 1

  • For Device ID: Wake

• Argument 2

  • For Device ID: Enable

The register notifier for an event of an error event ID enables the error event by clearing the corresponding PMC/PSM_ERR#N_STATUS bit and writes to the corresponding PMC/PSM_IRQ#N_EN. The notifier returns an event index (which is a bit that notify callback sets) to indicate the occurrence of the event.

The register notifier command works with the notify callback command. With register notifier command, multiple subscribers (A72, R5) can register for a single error event notification.

For example, register notifier of error node GT_CR error event clears PMC_ERR1_STATUS.GT_CR, enables PMC_IRQ1_EN.GT_CR, and returns a number, for example, 5. Notify callback sets bit 5 of the event status to indicate that the GT_CR error has occurred.

Notify Callback

On notify callback of an event of Error Event ID, the Error Node is disabled. For example, notification of the Error Node GT_CR error event disables the error by writing to PMC_IRQ1_DIS.GT_CR. You must re-register to be notified again.

For more information of registration/un-registration of error events, see Event Management Framework section in UG1304.

PSM errors handling by PLM

The HW error actions supported by PMC EAM for PMC errors are SRST, POR, IRQ (Interrupt to PMC Microblaze) and Error Out. And the HW error actions supported by PSM EAM for PSM errors are PSM_CR (PSM errors routed to PMC Microblaze as PSM_CR), PSM_NCR (PSM errors routed to PMC Microblaze as PSM_NCR), IRQ (Interrupt to PSM Microblaze) and SRST.

Even though these are the HW error actions, PLM supports the error actions mentioned in above section. So, any error can be configured to have the error action supported by PLM. Please refer to Additional information column in the table below to know the restrictions on the error actions for any error.

Since all the PLM supported error actions cannot be handled by the PSM HW supported error actions, the PSM errors are routed to PMC Microblaze either as PSM_CR or as PSM_NCR. So, all the PSM EAM errors are handled by PLM only. If a user selected error action for any PSM error matches with the PSM_CR error action, then PLM configures that PSM error as PSM_CR. If the user selected error action doesn’t match with PSM_CR error action, then PLM configures that as PSM_NCR and PLM executes the configured error action.

SW errors

The SW errors are the extended feature of the PLM error management. User can add any error to the SW errors list. These can also be configured through EAM CDO command. All the error actions are supported and handled by PLM. For the SW error to be handled by PLM, “XPlmi_HandleSwError" API need to be called from SW whenever there is an error occurrence.

For example. the “PLM_EXCEPTION” is not in the PMC EAM errors. So, to have any error action when any exception occurs, this is listed as one of the SW errors in the ErrorTable. And in the PLM Exception Handler, PLM calls “XPlmi_HandleSwError" to execute the configured error action. Please refer to https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_apps/versal_plm/src/common/xplm_proc.c#L115 code for the same. Also, please refer to xil_error_node.h for the Error Node ID for SW errors and the list of SW errors.

EAM errors and their default error actions

Below table lists PMC, PSM and SW supported errors and their default error actions set by PLM. Please refer to ErrorTable in xplmi_err.c