Versal Platform Loader and Manager
This page provides information related to the Versal Platform Loader and Manager (PLM).
Table of Contents
- 1 PLM Overview
- 2 Modules in PLM
- 2.1 User Modules
- 3 Building PLM
- 3.1 Using Vitis
- 3.2 Using XSCT
- 4 Generating Boot Image
- 5 Boot Modes
- 6 Loading Boot Image on Hardware
- 7 PLMI
- 8 Image Store
- 9 Error Handling in PLM
- 9.1 Error Management HW
- 9.2 Error Management in PLM
- 9.3 Error Management CDO commands
- 9.3.1 Set Em Action
- 9.3.1.1 **Setting subsystem action :
- 9.3.2 Register Notifier for EM Events
- 9.3.3 Notify Callback
- 9.3.1 Set Em Action
- 9.4 PSM errors handling by PLM
- 9.5 SW errors
- 9.6 EAM errors and their default error actions
- 9.7 Configuration of EAM errors through a CDO
- 10 Loader
- 10.1 CDO Offset logging
- 11 PM
- 12 Secure
- 13 Sem
- 14 PLM Build Flags
- 15 PLM Foot Print
- 16 Debugging Tips
- 16.1 Debugging PLM errors
- 16.2 Error Codes
- 16.3 Source Level Debugging with Vitis
- 16.3.1 Prerequisite
- 16.3.2 Debug Procedure
- 16.3.3 Debugging via JTAG ( *2 xsdb instance)
- 16.4 Debugging MB Core Dumps
- 16.5 SSIT Debug
- 16.6 PLM Compatibility between releases
- 17 Registers reserved for PLM
- 18 FAQs
- 19 Design Guidelines
- 20 Known Issues and Workarounds
- 21 Revision History
- 22 Related Links
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:
XilPLMI
XilLoader
XilPM
XilSecure
XilSEM
Note: XilLoader internally uses XilPDI library for loading the PDI image. Currently, XilPLMI, XilLoader and XilPDI are intended as PLM internal only libraries. Thus, APIs from these libraries are not intended to be called directly from other software layers outside of PLM.
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.
Please refer XPlmi_GenericInit
API available in xilplmi library for an example of how a module can be registered. Once registered user can use the APIs defined as CDO commands or IPI commands.
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
Open Vitis
Create new application project with File → New → Application Project…
New Application Window will pop up as shown below.
Click on “Next”. Select “Create a new platform from hardware (XSA)”, provide XSA File in “Platform” window and click on “Next”.
In “Application Project Details”, Select psv_pmc_0 processor and enter “Application project name” as “plm”.
Click on Next.
Select “versal PLM” in Templates window and click on “Finish”.
This would create PLM application with “plm_system” name along with the BSP.
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:
mkdir plm_ws
cd plm_ws
setws .
app create -name plm -hw design.xsa -template "versal PLM" -os standalone -proc psv_pmc_0
app build -name plm
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.
We already have PLM elf with us. Check the previous section to build PLM.
Create and build PSM Firmware elf for PSM Microblaze.
Create required applications for A72/R5, AIE, CPM etc.
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} } }
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:
SD/eMMC
QSPI
OSPI
Slave device boot modes
JTAG
Select MAP
USB (Only supported as secondary boot device)
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:
Set the boot mode pins to JTAG on Hardware, power on and connect to board.
Launch xsdb and connect to Hardware.
Once the Hardware is connected, you will see the following targets when “ta” command is issued on xsdb terminal.
Issue the following command to program the Hardware in JTAG boot mode.
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.
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.
Initially, boot Versal in JTAG boot mode till U-Boot.
Execute the following command in U-Boot on serial console to probe the flash device
On xsdb terminal, execute the following commands to write QSPI boot image to DDR
Then on serial console, execute the following commands in U-Boot to erase the flash memory and write the boot image to QSPI Flash
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.
Initially, boot Versal in JTAG boot mode till U-Boot.
Execute the following command in U-Boot on serial console to probe the flash device
On xsdb terminal, execute the following commands to write OSPI boot image to DDR
Then on serial console, execute the following commands in U-Boot to erase the flash memory and write the boot image to OSPI Flash
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.
Initially, boot Versal in JTAG boot mode till U-Boot.
Execute the following command in U-Boot on serial console to probe the emmc device
On xsdb terminal, execute the following commands to write the boot image to DDR
Then on serial console, execute the following commands in U-Boot to write the boot image to eMMC device
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:
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.
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:
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.
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.
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
Note: CRC can be enabled for IPI messages by setting ENABLE_IPI_CRC_VAL to 1U in xipisu.h file. This will add CRC validation check for IPI to/from communication. Please note that this setting need to be done in all application libraries for the Versal boot and post boot to work without any issues.
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:
Critical priority tasks (
XPLM_TASK_PRIORITY_CRITICAL
)High Priority tasks (
XPLM_TASK_PRIORITY_0
)Normal Priority tasks (
XPLM_TASK_PRIORITY_1
)
The general specifications for each PLM module are
Run nothing in interrupt context; instead, add the necessary priority task to the task queue.
To allow PLM to move on to the next high-priority task, the running task must not take longer time.
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
Command: Add PDI to ImageStore | ||||
Reserved[31:25]=0 | Security Flag[24] | Length[23:16]=4 | XilLoader=7 | CMD_ADD_IMG_STORE_PDI=9 |
PDI ID | ||||
High PDI Address | ||||
Low PDI Address | ||||
PDI Size ( In Words ) |
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.
Response: Add PDI to ImageStore |
Status (XST_SUCCESS / XLOADER_ERR_PDI_IMG_STORE_CFG_NOT_SET / XLOADER_ERR_PDI_IMG_STORE_FULL) |
Command: Remove PDI from ImageStore | ||||
Reserved[31:25]=0 | Security Flag[24] | Length[23:16]=1 | XilLoader=7 | CMD_REMOVE_IMG_STORE_PDI=10 |
PDI ID |
This command removes PDI address from the list of Image Store PDIs that are maintained by PLM.
Response: Remove PDI from ImageStore |
Status ( XST_SUCCESS / XLOADER_ERR_PDI_ADDR_NOT_FOUND) |
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: {
id_code = 0x14ca8093
extended_id_code = 0x01
id = 0x1
image
{
name = pmc_subsys
id = 0x1c000001
partition
{
id = 0x2
type = bootloader
file = ./plm.elf
}
partition
{
id = 0x3
type = pmcdata,load=0xF2000000
file = ./pmc_data.cdo
}
}
image
{
name = IMAGE_STORE
id = 0x18700000
partition
{
id = 0xb15
imagestore = <Pdi id>
section = write_image_store_pdi_1
}
partition
{
id = 0xb15
imagestore = <Pdi id>
file = partial.bin
}
}
}
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: {
id_code = 0x14ca8093
extended_id_code = 0x01
id = 0x1
boot_device { imagestore, address = 12 }
image
{
name = pmc_subsys
id = 0x1c000001
partition
{
id = 0x2
type = bootloader
file = ./plm.elf
}
partition
{
id = 0x3
type = pmcdata,load=0xF2000000
file = ./pmc_data.cdo
}
}
image
{
name = IMAGE_STORE
id = 0x18700000
partition
{
id = 0xb15
imagestore = 10
section = partial2.bin
}
partition
{
id = 0xb15
imagestore = 12
file = partial.bin
}
}
}
Load Partial PDI is extended to support loading via Image Store
Command: LoadPartialPdi | ||||
Reserved[31:25]=0 | Security Flag[24] | Length[23:16]=3 | XilLoader=7 | CMD_XILLOADER_LOAD_PPDI = 1 |
PdiSrc – 0x1 for QSPI24, 0x2 for QSPI32, 0x8 for OSPI, 0xF for DDR, 0x10 for Image Store | ||||
High PDI Address / 0x00 ( If PdiSrc Image Store ) | ||||
Low PDI Address / PDI ID ( If PdiSrc Image Store ) |
Response: Load Partial PDI |
Status (XST_SUCCESS / XLOADER_ERR_PDI_ADDR_NOT_FOUND) |
Examples :
Following examples are present in the Xilloader Library.
Add PDI to Image Store : xilloader_add_image_store_pdi_example.c
Load PDI from Image Store : xilloader_load_pdi_example.c
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:
POR - Power On Reset
SRST - System restart
CUSTOM (Not supported through CDO)
PS Error Out - Error Out
Subsystem Shutdown - Shutdown of a specific subsystem
Subsystem Restart - Restart of a specific subsystem
No Action
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
Command: Set EM Action | ||||
Reserved[31:25]=0 | Security Flag[24] | Length[23:16]=3 | EM=8 | CMD_SET_EM_ACTION=1 |
Error Event ID | ||||
Reserved | Action | |||
Error Mask |
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
Command: Register Notifier | |||
Reserved[31:24]=0 | Length[23:16]=4 | PMC_LIBPM=2 | CMD_PM_REGISTER_NOTIFIER=5 |
Node ID (Error Event ID) | |||
Event Mask (Error Mask) | |||
Argument 1 | |||
Argument 2 |
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
Command: Notify Callback | |||
Reserved[31:24]=0 | Length[23:16]=4 | PMC_LIBPM=2 | CMD_PM_NOTIFY_CALLBACK |
Node ID (Error Event ID) | |||
Event Status (Error Mask) |
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