Versal Platform Loader and Manager
P-192,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
- 2.1.1 Steps
- 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
- 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 0x80 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.
Steps
To register and utilize user modules, you need to call the 'user_module_init' function from 'XPlm_ModuleInit' in the following code: embeddedsw/lib/sw_apps/versal_plm/src/common/xplm_module.c at be4f96f3f73b0e47036eeb77949c1cc638b7648c · Xilinx/embeddedsw
Additionally, you need to set the user modules count using the XILPMLI BSP options as mentioned in the PLM Feature Configuration
Please note the following requirements for user modules:
The user modules index and API IDs should start from 0.
Use the predefined macro 'XPLMI_SET_USER_MODULE_ID' to create the user module ID, as the PLM reserved modules starts from 0x0, and the user modules starts from 0x80.
The maximum number of supported user modules is 0xF.
The major error code format for user modules is 0x3XYZ, where 'X' is the user module ID and 'YZ' represents the API ID.
Example User module code
/* User Module ID */
#define USER_MODULE_ID 0
/* User API IDs */
#define RESERVED_API_ID 0
#define USER_R5_API_ID 1
#define USER_A72_API_ID 2
static void user_module_init(void) {
static XPlmi_Module UserModule;
static XPlmi_ModuleCmd cmds[] = {
XPLMI_MODULE_COMMAND(NULL),
XPLMI_MODULE_COMMAND(user_r5_handler),
XPLMI_MODULE_COMMAND(user_a72_handler),
};
static XPlmi_AccessPerm_t perms[XPLMI_ARRAY_SIZE(cmds)] = {
XPLMI_ALL_IPI_NO_ACCESS(RESERVED_API_ID),
XPLMI_ALL_IPI_FULL_ACCESS(USER_R5_API_ID),
XPLMI_ALL_IPI_SECURE_ACCESS(USER_A72_API_ID),
};
UserModule.Id = XPLMI_SET_USER_MODULE_ID(USER_MODULE_ID);
UserModule.CmdAry = cmds;
UserModule.CmdCnt = XPLMI_ARRAY_SIZE(cmds);
UserModule.AccessPermBufferPtr = perms;
XPlmi_ModuleRegister(&UserModule);
XPlmi_Printf(DEBUG_PRINT_ALWAYS, "Initialized User module\r\n");
}
static int user_r5_handler(XPlmi_Cmd *Cmd) {
XPlmi_Printf(DEBUG_PRINT_ALWAYS, "User API; CMD ID: 0x%08x\r\n", Cmd->CmdId);
return XST_SUCCESS;
}
static int user_a72_handler(XPlmi_Cmd *Cmd) {
XPlmi_Printf(DEBUG_PRINT_ALWAYS, "User API; CMD ID: 0x%08x\r\n", Cmd->CmdId);
return XST_SUCCESS;
}
There are two options for adding the user module initialization code to the PLM Vitis project:
Directly to the xplm_module.c file in the created project, or
By creating new source and header files within the project.
To create a new user module initialization code file, follow these steps:
Remove the static keyword from the "user_module_init" function when defining it in a new ".c" file.
The "user_module_init" function initializes the user APIs to receive and process IPI commands.
IPI access permissions must be configured for each individual user API in the "user_module_init" function.
There are four types of IPI access permissions:
XPLMI_ALL_IPI_NO_ACCESS: No IPI access is allowed.
XPLMI_ALL_IPI_SECURE_ACCESS: IPI access is allowed only for secure IPI commands.
XPLMI_ALL_IPI_NON_SECURE_ACCESS: IPI access is allowed only for non-secure IPI commands.
XPLMI_ALL_IPI_FULL_ACCESS: Both secure and non-secure IPI commands are allowed.
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.
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 (Not supported through CDO)
Subsystem Restart - Restart of a specific subsystem (Not supported through CDO)
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.
^Note: Error actions like Subsystem restart or Subsystem shutdown need to be requested via IPI to PLM(Not through error action CDO commands), hence this is not listed in the error actions option in Iso Util.
**Setting subsystem error action ( Subsystem Shutdown or Subsystem Restart ) :
Any desired run time application can request Set Em Action based API’s to request or to set subsystem actions for desired errors (Subsystem restart or Subsystem shutdown) using platform management API’s (via IPI to PLM). PLM will auto detect the subsystem from where the request is initiated and assigns Shutdown / restart action on that subsystem.
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 file for the same.
Error IDs | Error | Description | Default action (In 2022.1) | Default action (In 2022.2) | Additional information |
---|---|---|---|---|---|
PMC Error1 | |||||
0x0 | BOOT_CR | PMC Boot Correctable Error. (Set by ROM code during ROM execution during Boot) | No action | Preferred action: None |
|
0x1 | BOOT_NCR | PMC Boot Non-Correctable Error. (Set by ROM code during ROM execution during Boot) | No action | Preferred action: None |
|
0x2 | FW_CR | PMC Firmware Boot Correctable Error. (Set by PLM during firmware execution during Boot) | Error Out | Error Out |
|
0x3 | FW_NCR | PMC Firmware Boot Non-Correctable Error. (Set by PLM during firmware execution during Boot) | SRST | SRST |
|
0x4 | GSW_CR | General Software Correctable Error. (Set by any processors after Boot) | No action | Default to PLM Print Log |
|
0x5 | GSW_NCR | General Software Non-Correctable Error. (Set by any processors after Boot) | No action | Default to PLM Print Log |
|
0x6 | CFU | CFU Error | No action | None |
|
0x7 | CFRAME | CFRAME Error | No action | None |
|
0x8 | PSM_CR | PSM Correctable Error (Summary from PSM Error Management). | SRST | SRST | The default error action for PSM_CR is SRST. PLM allows changing the error action for this error only once. If user tries to change it, PLM gives “ |
0x9 | PSM_NCR | PSM Non-Correctable Error (Summary from PSM Error Management). | CUSTOM | CUSTOM | PLM doesn’t allow changing the error action for PSM_NCR through a CDO. If user tries to change it, PLM gives “ |
0xA | DDRMC_MB_CR | DDRMC MB Correctable ECC Error. | No action | Default to PLM Print Log |
|
0xB | DDRMC_MB_NCR | DDRMC MB Non-Correctable ECC Error. | No action | Default to PLM Print Log |
|
0xC | NOC_TYPE1_CR | NoC Type1 Correctable Error. | No action | Default to PLM Print Log |
|
0xD | NOC_TYPE1_NCR | NoC Type1 Non-Correctable Error. | No action | Default to PLM Print Log |
|
0xE | NOC_USER | NoC User Error. | No action | None |
|
0xF | MMCM | MMCM Lock Error. (PLL for PL) | No action | Default to PLM Print Log |
|
0x10 | ME_CR | ME Correctable Error. | No action | None |
|
0x11 | ME_NCR | ME Non-Correctable Error. | No action | Default to PLM Print Log |
|
0x12 | DDRMC_MC_CR | DDRMC MC Correctable ECC Error. | No action | Default to PLM Print Log |
|
0x13 | DDRMC_MC_NCR | DDRMC MC Non-Correctable ECC Error. | No action | Default to PLM Print Log |
|
0x14 | GT_CR | GT Correctable Error. | No action | None - This error is not set to "PLM Print Log" because of SV60 VDU interrupts (scan clear and memclear done) are getting set and routed by default |
|
0x15 | GT_NCR | GT Non-Correctable Error. | No action | None - This error is not set to "PLM Print Log" because of SV60 VDU interrupts (scan clear and memclear done) are getting set and routed by default |
|
0x16 | PL_SMON_CR | PL Sysmon Correctable Error. | No action | Default to PLM Print Log |
|
0x17 | PL_SMON_NCR | PL Sysmon Non-Correctable Error. | No action | Default to PLM Print Log |
|
0x18 | PL0 | User defined PL generic error. | No action | Preferred action: None |
|
0x19 | PL1 | User defined PL generic error. | No action | Preferred action: None |
|
0x1A | PL2 | User defined PL generic error. | No action | Preferred action: None |
|
0x1B | PL3 | User defined PL generic error. | No action | Preferred action: None |
|
0x1C | NPI_ROOT | NPI Root Error. | No action | None (Need to check later) |
|
0x1D | SSIT_ERR3 | SSIT Error from Slave SLR1. (Only used in Master SLR) | No action | Preferred action: None |
|
0x1E | SSIT_ERR4 | SSIT Error from Slave SLR2. (Only used in Master SLR) | No action | Preferred action: None |
|
0x1F | SSIT_ERR5 | SSIT Error from Slave SLR3. (Only used in Master SLR) | No action | Preferred action: None |
|
PMC Error2 | |||||
0x20 | PMC_APB | General purpose PMC error, can be triggered by any of the following peripherals:
| No action | Currently, this is being used for triggering secure lockdown to PLM by ROM. Default action is CUSTOM |
|
0x21 | PMC_ROM | PMC ROM Validation Error. | No action | Preferred action: None |
|
0x22 | MB_FATAL0 | PMC PPU0 MB TMR Fatal Error. | No action | Default to PLM Print Log |
|
0x23 | MB_FATAL1 | PMC PPU1 MB TMR Fatal Error. | No action | Default to PLM Print Log |
|
0x24 | PMC_PAR | PMC Switch and PMC IOU Parity Errors. | No action | Default to PLM Print Log |
|
0x25 | PMC_CR | PMC Correctable Errors: | No action | Default to PLM Print Log |
|
0x26 | PMC_NCR | PMC Non-Correctable Errors: | No action | Default to PLM Print Log |
|
0x27 | PMC_SMON0 | PMC Temperature Shutdown Alert and Power Supply Failure Detection Errors from PMC Sysmon alarm[0]. (Indicates an alarm condition on any of SUPPLY0 to SUPPLY31) | No action | Default to PLM Print Log |
|
0x28 | PMC_SMON1 | PMC Temperature Shutdown Alert and Power Supply Failure Detection Errors from PMC Sysmon alarm[1]. (Indicates an alarm condition on any of SUPPLY32 to SUPPLY63) | No action | Default to PLM Print Log |
|
0x29 | PMC_SMON2 | PMC Temperature Shutdown Alert and Power Supply Failure Detection Errors from PMC Sysmon alarm[2]. (Indicates an alarm condition on any of SUPPLY64 to SUPPLY95) | No action | Default to PLM Print Log |
|
0x2A | PMC_SMON3 | PMC Temperature Shutdown Alert and Power Supply Failure Detection Errors from PMC Sysmon alarm[3]. (Indicates an alarm condition on any of SUPPLY96 to SUPPLY127) | No action | Default to PLM Print Log |
|
0x2B | PMC_SMON4 | PMC Temperature Shutdown Alert and Power Supply Failure Detection Errors from PMC Sysmon alarm[4]. (Indicates an alarm condition on any of SUPPLY128 to SUPPLY159) | No action | Default to PLM Print Log |
|
0x2F | PMC_SMON8 | PMC Temperature Shutdown Alert and Power Supply Failure Detection Errors from PMC Sysmon alarm[8]. (Indicates an over-temperature alarm) | Default action through PMC_DATA.CDO is SRST | Default to PLM Print Log Action through CDO is SRST |
|
0x30 | PMC_SMON9 | PMC Temperature Shutdown Alert and Power Supply Failure Detection Errors from PMC Sysmon alarm[9]. (Indicates a device temperature alarm) | No action | Default to PLM Print Log |
|
0x31 | CFI | CFI Non-Correctable Error. | No action | None as we are checking after PDI load |
|
0x32 | CFRAME_SEU_CRC | CFRAME SEU CRC Error. | No action | Preferred action: None as this error is getting routed to IOMODULE as well and XilSem is handling them. Additionally, XilSem is planning to add SW errors through which this error occurrence is communicated to user based on error action configured |
|
0x33 | CFRAME_SEU_ECC | CFRAME SEU ECC Error. | No action | Preferred action: None as this error is getting routed to IOMODULE as well and XilSem is handling them. Additionally, XilSem is planning to add SW errors through which this error occurrence is communicated to user based on error action configured |
|
0x36 | RTC_ALARM | RTC Alarm Error. | No action | Preferred action: None |
|
0x37 | NPLL | PMC NPLL Lock Error (This error can be unmasked after the NPLL is locked to alert when the NPLL loses lock). | No action | Preferred action: None |
|
0x38 | PPLL | PMC PPLL Lock Error (This error can be unmasked after the PPLL is locked to alert when the PPLL loses lock). | No action | Preferred action: None |
|
0x39 | CLK_MON | Clock Monitor Errors. | No action | Default to PLM Print Log |
|
0x3A | PMC_TO | PMC Interconnect Timeout Errors. | No action | Default to PLM Print Log |
|
0x3B | PMC_XMPU | PMC XMPU Errors: | CUSTOM | CUSTOM |
|
0x3C | PMC_XPPU | PMC XPPU Errors: | CUSTOM | CUSTOM |
|
0x3D | SSIT_ERR0 | For Master SLR: SSIT Error from Slave SLR1. | No action | CUSTOM for SSIT devices |
|
0x3E | SSIT_ERR1 | For Master SLR: SSIT Error from Slave SLR2. | No action | CUSTOM for SSIT devices |
|
0x3F | SSIT_ERR2 | For Master SLR: SSIT Error from Slave SLR3. | No action | CUSTOM for SSIT devices |
|
PSM Error1 | |||||
0x40 | PS_SW_CR | PS Software can write to trigger register to generate this Correctable Error. | No action | Default to PLM Print Log |
|
0x41 | PS_SW_NCR | PS Software can write to trigger register to generate this Non-Correctable Error. | No action | Default to PLM Print Log |
|
0x42 | PSM_B_CR | PSM Firmware can write to trigger register to generate this Correctable Error. | No action | Default to PLM Print Log |
|
0x43 | PSM_B_NCR | PSM Firmware can write to trigger register to generate this Non-Correctable Error. | No action | Default to PLM Print Log |
|
0x44 | MB_FATAL | Or of MB Fatal1, Fatal2, Fatal3 Error. | No action | Default to PLM Print Log |
|
0x45 | PSM_CR | PSM Correctable | No action | Default to PLM Print Log |
|
0x46 | PSM_NCR | PSM Non-Correctable | No action | Default to PLM Print Log |
|
0x47 | OCM_ECC | Non-Correctable ECC Error during an OCM access. | No action | Default to PLM Print Log |
|
0x48 | L2_ECC | Non-Correctable ECC Error during APU L2 Cache access. | No action | Default to PLM Print Log |
|
0x49 | RPU | ECC Errors during a RPU memory access. Floating-point operation exceptions. RPU REG APB error. | No action | Default to PLM Print Log |
|
0x4A | RPU_LS | RPU Lockstep Errors from R5_0. The Lockstep error is not initialized until RPU clock is enabled; therefore, error outcomes are masked by default and are expected to be unmasked after processor clock is enabled and before its reset is released. | No action | Default to PLM Print Log |
|
0x4B | RPU_CCF | RPU Common Cause Failures ORed together. The CCF Error register with the masking capability has to reside in the RPU. | No action | Default to PLM Print Log |
|
0x4C | GIC_AXI | APU GIC AXI Error by the AXI4 master port, such as SLVERR or DECERR. | No action | Default to PLM Print Log |
|
0x4D | GIC_ECC | APU GIC ECC Error, a Non-Correctable ECC error occurred in any ECC-protected RAM. | No action | Default to PLM Print Log |
|
0x4E | APLL_LOCK | APLL Lock Errors. The error can be unmasked after the PLL is locked to alert when the PLL loses lock. | No action | Preferred action: None |
|
0x4F | RPLL_LOCK | RPLL Lock Errors. The error can be unmasked after the PLL is locked to alert when the PLL loses lock. | No action | Preferred action: None |
|
0x50 | CPM_CR | CPM Correctable Error. | No action | Default to PLM Print Log |
|
0x51 | CPM_NCR | CPM Non-Correctable Error. | CUSTOM | CUSTOM |
|
0x52 | LPD_APB | LPD APB Errors from: | No action | Default to PLM Print Log |
|
0x53 | FPD_APB | FPD APB Errors from: | No action | Default to PLM Print Log |
|
0x54 | LPD_PAR | Data parity errors from the interfaces connected to the LPD interconnect. | No action | Default to PLM Print Log |
|
0x55 | FPD_PAR | Data parity errors from the interfaces connected to the FPD interconnect. | No action | Default to PLM Print Log |
|
0x56 | IOU_PAR | LPD IO Peripheral Unit Parity Error. | No action | Default to PLM Print Log |
|
0x57 | PSM_PAR | Data parity errors from the interfaces connected to the PSM interconnect. | No action | Default to PLM Print Log |
|
0x58 | LPD_TO | LPD Interconnect Timeout errors. | No action | Default to PLM Print Log |
|
0x59 | FPD_TO | FPD Interconnect Timeout errors. | No action | Default to PLM Print Log |
|
0x5A | PSM_TO | PSM Interconnect Timeout Errors. | No action | Default to PLM Print Log |
|
0x5B | XRAM_CR | XRAM Correctable error. (Only applicable in devices that have XRAM) | No action | Default to PLM Print Log |
|
0x5C | XRAM_NCR | XRAM Non-Correctable error. (Only applicable in devices that have XRAM) | No action | Default to PLM Print Log |
|
PSM Error2 | |||||
0x60 | LPD_SWDT | Error from Watchdog Timer in the LPD Subsystem. | No action | Default to PLM Print Log |
|
0x61 | FPD_SWDT | Error from Watchdog Timer in the FPD Subsystem. | No action | Default to PLM Print Log |
|
0x72 | LPD_XMPU | LPD XMPU Errors: | CUSTOM | CUSTOM |
|
0x73 | LPD_XPPU | LPD XPPU Errors: | CUSTOM | CUSTOM |
|
0x74 | FPD_XMPU | FPD XMPU Errors: | CUSTOM | CUSTOM |
|
SW Errors | |||||
0x80 | HB_MON_0 | Health Boot Monitoring Error0 | No action | As per SW configuration |
|
0x81 | HB_MON_1 | Health Boot Monitoring Error1 | No action | As per SW configuration |
|
0x82 | HB_MON_2 | Health Boot Monitoring Error2 | No action | As per SW configuration |
|
0x83 | HB_MON_3 | Health Boot Monitoring Error3 | No action | As per SW configuration |
|
0x84 | PLM_EXCEPTION | PLM Exception during run time | No action | As per SW configuration |
|
Configuration of EAM errors through a CDO
Since the tools support to configure the EAM errors is not yet added, this section describes how they can be configured through a CDO. Below snippet shows the example EAM CDO which can be modified as per the requirement, can be included in the BIF as a CDO and PDI can be generated.
Loader
PDI contains all the images that must be loaded into the system. PLM reads the PDI from the boot device and loads the images to the respective memories based on the image header. For more details on PDI, refer to UG1304.
Following are the responsibilities of XilLoader:
Boot device initialization
Interface for modules to load/start/look up the image present in PDI
Interface with XilPDI to decode and validate images present in PDI
Support secure boot loading using XilSecure module
Subsystem bring up by calling XilPM
Please refer to CDO spec for the list of CDO/IPI commands supported by XilLoader.
CDO Offset logging
CDO offset logging helps in identifying and resolving issue with CDO command failures. This process can be done in two ways: through XSDB or from PMC CDO.
To enable CDO offset logging from XSDB, you need to use the "mwr" command to set the register "0xF1110054" with the value "0x8".
The command will look like this:
mwr 0xF1110054 0x8
On the other hand, to enable CDO offset logging from PMC CDO, you need to add the following CDO command to PMC CDO:
mask_write 0xF1110054 0x8 0x8
Once you have enabled CDO offset logging, you can fetch the last executed CDO offset address. This can be done either through the PLM log or from the "error_status" register. In the PLM log, the offset can be found in the register dump, specifically under "PMC_GLOBAL_PMC_GSW_ERR". In the "error_status" register, you can fetch it from xsdb by running "device status -hex error_status" and looking for "GSW ERROR (Bits [93:64])".
After obtaining the hex value from GSW ERROR, multiply it by 4. Then, identify the partition where the failure occurred.
To generate a CDO dump, use the command "cdoutil -annotate=offset <path to pdi>". Redirect this command output to a file to capture it.
Finally, open the dump and look for the partition offset. Subtract the partition offset with the GSW error offset calculated earlier. This will give you a new offset for the partition. Look for the command with this new offset to complete the process.
**Note: Generate the CDO dump for the entire PDI, rather than just for individual CDOs.
PM
Platform Management (XilPM) is a library that provides interfaces to create and manage subsystems, MIO, Clocks, Power and Reset settings of nodes. The following table provides the list of commands supported by this module. For details about Platform Management, refer to the Chapter 10: Versal ACAP Platform Management in UG1304
Secure
The XilSecure library is a library of security drivers that access the hardened cryptographic cores to support the AES-GCM 256-bit/128-bit engine, the RSA/ECC engine that supports RSA-4096, RSA-3076, RSA-2048 as well as ECDSA NIST P-384 and NIST P-521, and the SHA3/384 engine.
For more information, see Chapter 9: Security in UG1304.
Sem
The Xilinx Soft Error Mitigation (XilSEM) library is a pre-configured, pre-verified solution to detect and optionally correct soft errors in Configuration Memory of Versal ACAPs.
See the OS and Libraries Document Collection (UG643) for more information.
PLM Build Flags
The following table lists the important build flags in PLM and their usage. For a complete list of build flags, see the xplmi_config.h file in the XilPLMI library.
Flag | Description | Requires these flags/build options to be enabled | Default Setting |
---|---|---|---|
PLM_PRINT_NO_UART | Disables prints to UART. Prints to memory are still enabled as defined by PLM DEBUG macros below | None | Disabled |
PLM_PRINT | Prints PLM header and any mandatory prints | None | Disabled |
PLM_DEBUG | Prints basic information and any error messages | None | Enabled |
PLM_DEBUG_INFO | Prints with format specifiers in addition to the basic information | None | Disabled |
PLM_DEBUG_DETAILED | Prints detailed information | None | Disabled |
PLM_PRINT_PERF | Prints the time taken for loading the partitions, images and tasks | Any of the above mentioned print related flags | Enabled |
PLM_PRINT_PERF_POLL | Prints the time taken for any poll for the MASK_POLL command | PLM_PRINT_PERF | Disabled |
PLM_PRINT_PERF_DMA | Prints the time taken for PMC DMA, QSPI and OSPI | PLM_PRINT_PERF | Disabled |
PLM_PRINT_PERF_CDO_PROCESS | Prints the time taken for processing a CDO file | PLM_PRINT_PERF | Disabled |
PLM_PRINT_PERF_KEYHOLE | Prints the time taken for processing keyhole command | PLM_PRINT_PERF | Disabled |
PLM_PRINT_PERF_PL | Prints the PL power and house cleaning status | PLM_PRINT_PERF | Disabled |
PLM_QSPI_EXCLUDE | Excludes QSPI code when this flag is enabled | None | Disabled |
PLM_SD_EXCLUDE | Excludes SD code when this flag is enabled | None | Disabled |
PLM_OSPI_EXCLUDE | Excludes OSPI code when this flag is enabled | None | Disabled |
PLM_USB_EXCLUDE | Excludes USB code when this flag is enabled | None | Enabled |
PLM_SEM_EXCLUDE | Excludes SEM module code when this flag is enabled | None | Disabled |
PLM_SECURE_EXCLUDE | Excludes Secure code when this flag is enabled | None | Disabled |
PLM_DEBUG_MODE | Changes the PLM to Debug mode to keep the system in hang state instead of doing SRST in case of an error for the user to debug further | None | Disabled |
PLM_ENABLE_STL | Enables STL when this flag is enabled | Add STL library to the PLM BSP | Disabled |
XILPM_USB_EXCLUDE | Excludes USB related code for the XilPM library | None | Disabled |
PLM Feature Configuration
In Zynq UltraScale+, for applications FSBL and PMUFW changing of configuration (enable/disable certain feature(s)) was possible through Vitis GUI (where we can define or undefine), same could be done in command line using -D or -U as parameter to make (for defining or undefining).
In Versal, most of the PLM application functionality is distributed to various libraries and configuration of various features is done in XilPLMI library. Hence, these features shall be enabled/disabled through Board Support Package Settings. This enhancement in PLM is done in 2022.1
Enabling of certain features (e.g. boot modes, SEM feature, UART debug) as referred here is w.r.t. enabling the corresponding support in PLM. For these features to be fully enabled and available, the hardware configuration(s) corresponding to these features too should be available. However, disabling these features in PLM results in overall disabling irrespective of the corresponding hardware configuration.
Below table lists the PLMI library configuration options, their description and default configuration:
Option Name | Description | Type/Options | Default Value |
---|---|---|---|
plm_uart_dbg_en | Enables (if enabled in hardware design too) or Disables Debug prints from UART (log to memory done irrespectively) | Bool (true, false) | true |
plm_dbg_lvl | Selects the debug logs level | Enum | level1 |
plm_mode | Selects between Release and Debug modes (PLM errors lead to SRST for former and system hang for latter) | Enum (release, debug) | release |
plm_perf_en | Enables or Disables Boot time measurement | Bool (true, false) | true |
plm_qspi_en | Enables (if enabled in hardware design too) or Disables QSPI boot mode | Bool (true, false) | true |
plm_sd_en | Enables (if enabled in hardware design too) or Disables SD boot mode | Bool (true, false) | true |
plm_ospi_en | Enables (if enabled in hardware design too) or Disables OSPI boot mode | Bool (true, false) | true |
plm_sem_en | Enables (if enabled in hardware design too) or Disables SEM feature | Bool (true, false) | true |
plm_secure_en | Enables or Disbales Secure features | Enables or Disbales Secure features | true |
plm_usb_en | Enables (if enabled in hardware design too) or disables USB boot mode | Bool (true, false) | false |
plm_nvm_en | Enables or Disables NVM handlers | Bool (true, false) | false |
plm_puf_en | Enables or Disables PUF handlers | Bool (true, false) | false |
plm_stl_en | Enables or Disables STL | Bool (true, false) | false |
plm_add_ppks_en | Enables or disables additional PPKs | Bool (true, false) | false |
ssit_plm_to_plm_comm_en | Enables or Disables SSIT PLM to PLM communication (valid only for Versal) | Bool (true, false) | true |
plm_ecdsa_en | Enables or Disables ECDSA handlers | Bool (true, false) | true |
plm_rsa_en | Enables or Disables RSA handlers | Bool (true, false) | true |
sem_override_dbg_lvl | Overrides plm_dbg_lvl as 0 for XilSEM designs if enabled (1) | Bool (true, false) | true |
user_modules_count | Number of User Modules | int | 0 |
xplmi_mode | Enables server mode for PMC and client mode for APU, RPU and Microblaze | enum (“client”, “server”) | “server” |
PLM Feature Configuration through Vitis Unified IDE
Click "vitis-comp.json" file, expand "standalone_psv_pmc_0" and click on "Board Support Package" as shown in below screen highlighted in RED boxes.
All the configurable libraries/drivers will be shown below "Board Support Package".
Click on the xilplmi library in the GUI as shown in the below screen. All the configurable parameters for the library xilplmi are now visible under column "Name". By default, "Value" and "Default" fields show same configuration.
Click on Value column against configurable to list the available options against configuration. Choose the option from the dropdown as appropriate. Wait until the BSP generation happens as per the selection.
and build the Platform project as usual.
PLM Feature Configuration through Vitis GUI
Click on the <project>.prj file and click on the "Navigate to BSP Settings" button as shown in below screen.
Click on the Modify BSP Settings… button as shown in below screen.
All the configurable libraries will be shown with tick mark in the Supported Libraries frame.
Click on the xilplmi library in the GUI as shown in the below screen. All the configurable parameters for the library xilplmi are now visible under column "Name". By default "Value" and "Default" fields show same configuration.
Click on Value column against configurable to list the available options against configuration. Change the selection as appropriate and click on OK button. Wait until the BSP generation happens as per the selection.
Now build the PLM project as usual.
PLM Feature Configuration through xsct
The below snippet shows steps involved in initially building the PLM with default configuration, then changing the debug level to debug info and regenerate BSP and rebuilding PLM, and then finally changing the debug level back to general (which is default), enabling the USB boot mode and regenerate BSP and rebuilding PLM. Refer above table for the different configuration options.
PLM Feature Configuration for PetaLinux
Refer above table for the different configuration options. Below example shows how to enable USB boot mode (which is disabled by default).
Create a _plm_ _bbappend_ file and add below content
To add BSP flags(to enable USB boot mode) in PLM:
Building PLM:
XILSECURE Feature Configuration
In Versal, the XilSecure library supports the NIST P-192, P-224, P-256, P-384 and P-521 elliptic curves for signature generation, signature verification, public/private key pair generation and public key validation operations. Configurations for the NIST P-192, P-224, P-256, and P-521 curves can be set through the Board Support Package (BSP). The below table provides details on the supported curves, their descriptions, and default configurations. P-384 is enabled by default for use in secure boot and does not require an explicit enable option.
Option Name | Description | Type/Options | Default Value |
---|---|---|---|
xsecure_elliptic_p192_support | Enables/Disables P-192 curve support | enum (true, false) | false |
xsecure_elliptic_p224_support | Enables/Disables P-224 curve support | enum (true, false) | false |
xsecure_elliptic_p256_support | Enables/Disables P-256 curve support | enum (true, false) | false |
xsecure_elliptic_p521_support | Enables/Disables P-521 curve support | enum (true, false) | true |
XILSECURE Feature Configuration through Vitis GUI
Click "vitis-comp.json" file, expand "standalone_psv_pmc_0" and click on "Board Support Package", configure the elliptic curves as shown in below screen highlighted in RED boxes.
XILSECURE Feature Configuration through xsct
To configure the elliptic curves while building the PLM in XSCT flow, update the related curves configurations in the following path.
(ESW PATH)/lib/sw_services/xilsecure/data/xilsecure.mld
PLM Foot Print
PPU RAM which is of 384KB is used for PLM elf (Text, Data, BSS and Stack sections). In this, 16KB of memory is reserved for user code to add any custom code to the PLM.
This section contains the approximate details of PLM memory footprint with various build flags enabled. Refer to PLM Build Flags section above for the list of build flags and their default settings.
In PLM, PLM_DEBUG and PLM_PRINT_PERF build flags along with all modules are enabled by default.
[2022.2]
S No.
| Feature/Build Flag | Size occupied (KB) | Free space (KB) | Additional Notes | Remarks |
---|---|---|---|---|---|
1 | PLM default build | 363.6 | 20.4 | Default PLM includes all PLM modules and basic PLM prints, and has time stamp enabled. (PLM_DEBUG and PLM_PRINT_PERF) |
|
2 | PLM_PRINT_NO_UART enabled/plm_uart_dbg_en set to false | 363.6 | 20.4 | Disables prints to UART (Print to memory is enabled irrespective of this option being set) | This estimate is with the combination of (1) and (2) |
3 | PLM_PRINT enabled/plm_dbg_lvl set to level 0 | 331.9 | 52.1 | Enables only mandatory prints | This estimate is with PLM_PRINT macro enabled and all other print macros (PLM_DEBUG, PLM_DEBUG_INFO and PLM_DEBUG_DETAILED) disabled |
4 | PLM_DEBUG_INFO enabled/plm_dbg_lvl set to level 2 | 376.6 | 7.4 | Enables more info prints | This estimate is with PLM_DEBUG_INFO macro enabled and all other print macros (PLM_PRINT, PLM_DEBUG and PLM_DEBUG_DETAILED) disabled |
5 | PLM_DEBUG_DETAILED enabled/plm_dbg_lvl set to level 3 | Overflowed by 1480 bytes | - | Enables detailed debug prints | This estimate is with PLM_DEBUG_DETAILED macro enabled and all other print macros (PLM_PRINT, PLM_DEBUG and PLM_DEBUG_INFO) disabled |
6 | PLM_DEBUG_MODE enabled/plm_mode set to debug | 362.8 | 21.2 | PLM debug mode is enabled when PLM_DEBUG_MODE flag is enabled or plm_mode option is set to debug | This estimate is with the combination of (1) and (6) |
7 | PLM_PRINT_PERF disabled/plm_perf_en set to false | 363.3 | 20.7 | Disables PLM performance prints | This estimate is with the combination of (1) and (7) |
8 | PLM_QSPI_EXCLUDE enabled/plm_qspi_en set to false | 355.5 | 28.5 | Excludes QSPI related code | This estimate is with the combination of (1) and (8) |
9 | PLM_SD_EXCLUDE enabled/plm_sd_en set to false | 343.3 | 40.7 | Excludes SD related code | This estimate is with the combination of (1) and (9) |
10 | PLM_OSPI_EXCLUDE enabled/plm_ospi_en set to false | 363.6 | 20.4 | Excludes OSPI related code | This estimate is with the combination of (1) and (10) |
11 | PLM_SEM_EXCLUDE enabled/plm_sem_en set to false | 363.6 | 20.4 | Excludes SEM related code | This estimate is with the combination of (1) and (11) |
12 | PLM_SECURE_EXCLUDE enabled/plm_secure_en set to false | 317.5 | 66.5 | Excludes Secure related code | This estimate is with the combination of (1) and (12) |
13 | PLM_USB_EXCLUDE disabled/plm_usb_en set to true | 374.1 | 9.9 | Enables USB related code | This estimate is with the combination of (1) and (13) |
14 | PLM_NVM_EXCLUDE disabled/plm_nvm_en set to true | Overflowed by 232 bytes | - | Enables NVM related code | This estimate is with the combination of (1) and (14) |
15 | PLM_PUF_EXCLUDE disabled/plm_puf_en set to true | 366.5 | 17.5 | Enabled PUF related code | This estimate is with the combination of (1) and (15) |
[2023.1]
S No. | Feature/Build Flag | Size occupied (KB) | Free space (KB) | Additional Notes | Remarks |
1 | PLM default build | 376.35 | 7.65 | Default PLM includes all PLM modules and basic PLM prints, and has time stamp enabled. (PLM_DEBUG and PLM_PRINT_PERF) |
|
2 | PLM_PRINT_NO_UART enabled/plm_uart_dbg_en set to false | 376.35 | 7.65 | Disables prints to UART (Print to memory is enabled irrespective of this option being set) | This estimate is with the combination of (1) and (2) |
3 | PLM_PRINT enabled/plm_dbg_lvl set to level 0 | 342.23 | 41.77 | Enables only mandatory prints | This estimate is with PLM_PRINT macro enabled and all other print macros (PLM_DEBUG, PLM_DEBUG_INFO and PLM_DEBUG_DETAILED) disabled |
4 | PLM_DEBUG_INFO enabled/plm_dbg_lvl set to level 2 | Overflowed by 7664 bytes | - | Enables more info prints | This estimate is with PLM_DEBUG_INFO macro enabled and all other print macros (PLM_PRINT, PLM_DEBUG and PLM_DEBUG_DETAILED) disabled |
5 | PLM_DEBUG_DETAILED enabled/plm_dbg_lvl set to level 3 | Overflowed by 16880 bytes | - | Enables detailed debug prints | This estimate is with PLM_DEBUG_DETAILED macro enabled and all other print macros (PLM_PRINT, PLM_DEBUG and PLM_DEBUG_INFO) disabled |
6 | PLM_DEBUG_MODE enabled/plm_mode set to debug | 374.46 | 9.54 | PLM debug mode is enabled when PLM_DEBUG_MODE flag is enabled or plm_mode option is set to debug | This estimate is with the combination of (1) and (6) |
7 | PLM_PRINT_PERF disabled/plm_perf_en set to false | 376.15 | 7.85 | Disables PLM performance prints | This estimate is with the combination of (1) and (7) |
8 | PLM_QSPI_EXCLUDE enabled/plm_qspi_en set to false | 367.21 | 16.79 | Excludes QSPI related code | This estimate is with the combination of (1) and (8) |
9 | PLM_SD_EXCLUDE enabled/plm_sd_en set to false | 353.46 | 30.54 | Excludes SD related code | This estimate is with the combination of (1) and (9) |
10 | PLM_OSPI_EXCLUDE enabled/plm_ospi_en set to false | 376.35 | 7.65 | Excludes OSPI related code | This estimate is with the combination of (1) and (10) |
11 | PLM_SEM_EXCLUDE enabled/plm_sem_en set to false | 376.35 | 7.65 | Excludes SEM related code | This estimate is with the combination of (1) and (11) |
12 | PLM_SECURE_EXCLUDE enabled/plm_secure_en set to false | 324.36 | 59.64 | Excludes Secure related code | This estimate is with the combination of (1) and (12) |
13 | PLM_USB_EXCLUDE disabled/plm_usb_en set to true | Overflowed by 3088 bytes | - | Enables USB related code | This estimate is with the combination of (1) and (13) |
14 | PLM_NVM_EXCLUDE disabled/plm_nvm_en set to true | Overflowed by 12872 bytes | - | Enables NVM related code | This estimate is with the combination of (1) and (14) |
15 | PLM_PUF_EXCLUDE disabled/plm_puf_en set to true | 378.89 | 5.11 | Enabled PUF related code | This estimate is with the combination of (1) and (15) |
16 | PLM_ECDSA_EXCLUDE enabled/plm_ecdsa_en set to false | 361.5 | 22.5 | Excludes ECDSA related code | This estimate is with the combination of (1) and (16) |
17 | PLM_RSA_EXCLUDE enabled/plm_rsa_en set to false | 368.5 | 15.5 | Excludes RSA related code | This estimate is with the combination of (1) and (17) |
18 | PLM_ENABLE_PLM_TO_PLM_COMM disabled/ssit_plm_to_plm_comm_en set to false | 376.35 | 7.65 | Excludes PLM to PLM communication related code | This estimate is with the combination of (1) and (18) |
Debugging Tips
PLM throws XYZ error code when any error occurs. This error code will also be stored in PMC_GLOBAL FW_ERR (0xF1120100) registers.
Reading PLM memory log and interpreting PLM prints
By default PLM prints are stored in PMC RAM at address 0xF2019000. Maximum size allocated for PLM print log memory is 16KB. After that PLM will overwrite the existing prints.
From xsdb, we can read and view the prints using either of the following three commands.
If prints are read using first command, user can open uart.bin in vi or any editor and see the prints.
Below is the example log for the PLM prints:
"[X]" at the start of the print signifies the total cumulative time taken in ms from the start of PLM to that print statement.
"X ms for Partition#: Y, Size: Z Bytes" - this print indicates time taken for loading partition number Y of size Z bytes is X ms.
ROM time is from start of ROM to PLM start point.
"[X] Total PLM Boot Time" indicates that the total PLM boot time in ms.
PLM error code format:
0xXXXX_YYYY is the error code format.
XXXX - Major error code - PLM/LOADER/XPLMI error codes as defined in xplmi_status.h file in XilPLMI library
YYYY - Minor error code - Libraries / Drivers error code as defined in corresponding modules.
Below table describes the major error code decoding for CDO Command failures(Supported from 2020.2):
Error Code | Description |
---|---|
0x2XYZ | 0x2XYZ - 0x2 indicates failure in CDO command 0x2XYZ - 0xX indicates command module. 1 - PLM, 2 -PM, 3 - SEM, 7 - Loader, 8 - Error, etc.. Please refer https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_services/xilplmi/src/common/xplmi_modules.h#L61 for module IDs supported by PLM 0x2XYZ - 0xYZ indicate handler ID of the CDO command. Handler IDs can be checked in CDO spec against the module PLMI handlers: Please refer to https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_services/xilplmi/src/common/xplmi_generic.c#L1985 for handlers supported in PLMI (GENERIC) module. |
Ex: 0x223E | 0x223E - 0x2 indicates failure in CDO command 0x223E - 0x2 indicates command failed in PM Command. 0x223E - 0x3E indicate handler ID of the PM command which is PM_INIT_NODE. |
YYYY | Minor error code - Libraries / Drivers error codes as defined in corresponding modules. Refer “Error Codes” Section Below |
Debugging PLM errors
Preferred Debug Level
Enable PLM_DEBUG_INFO Macro for more verbose detailed logs.
Enabling debug mode in PLM
PLM_DEBUG_MODE macro in xplmi_config.h file can be enabled to enable the debug mode in PLM. Enabling this flag disables soft reset and memory clearing in case of error during initial PDI loading. This will be helpful in maintaining the system state for debugging when any error occurs. If this flag is not enabled, PLM does a soft reset and there is a chance that PLM first error gets overwritten by next error code of PDI load.
Following are the register writes required to enable DAP in case security is enabled. These register writes need to happen at the start of PLM. This DAP CDO need to be included in BIF to merge it as part of PMC CDO.
Further data that can help in debugging:
Reading the device status from xsdb with the following commands
PLM State
And UART console or memory log
If UART is enabled in the design and no prints on the terminal, then PLM has failed before LPD configuration. PLM might have failed in PMC or LPD CDOs or boot device initialization.
Error Codes
Below table provides links to PLM Major and Minor error codes.
Major Error Codes |
|
---|---|
Major error codes | |
Minor Error Codes |
|
XilPLMI | |
XilLoader | From 2024.1 From 2022.2 https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_services/xilloader/src/common/xloader.h#L224 2022.1 https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_services/xilloader/src/xloader.h#L230 From 2021.1 2020.3 or previous releases |
XilSecure | |
XilPM | Before 2022.2 |
The following table lists various error codes present in PLM and provides additional information on next steps:
Verify with a second Versal ACAP device or board if available, to eliminate board setup for these errors. If error persists, contact Xilinx®
Verify voltages and temperatures are within device operating specifications and reboot the device
This can occur when PDI data is corrupted from the boot device. Enable checksum to detect any PDI errors.
Check if older version of PLM elf is used with new CDO files. Check “PLM Compatibility between releases” section to verify the compatibility of PLM and CDOs files version.
Please check the design if proper configuration is selected in Vivado for IO peripherals (QSPI, OSPI, SD, eMMC, UART) and if same design is used to generate PLM elf. Design parameters can also be verified in xparameters.h to know if they are exported properly or not from xsa.
Please check the design if proper configuration is selected in Vivado and it is properly reflected in CDO files generated
Error Code | Description | Next steps |
---|---|---|
Error codes used in XilPLMI | ||
0x100 | Error when DMA driver lookup fails | 1 |
0x101 | Error when DMA driver config fails | 1 |
0x102 | Error when DMA Self test fails. It occurs when DMA is in reset and PLM tries to initialize it | 1 |
0x103 | Error when IOModule driver look up fails | 1 |
0x104 | Error when IOModule driver startup fails | 1 |
0x105 | Error when IOModule driver connection fails | 1 |
0x106 | Error when PLMI module is not registered. Can occur when invalid CDO CMD is processed by Xilplmi | 3, 4 |
0x107 | Error when valid module and unregistered CMD ID is processed by xilplmi | 3, 4 |
0x108 | Error when no command handler is registered by module for CDO CMD | 1 |
0x109 | Error returned by the CDO CMD handler. For error returned by the CMD, check the PLM minor code. Deprecated from 2020.2 | Deprecated from 2020.2 |
0x10A | Error returned by the CDO CMD resume handler. For error returned by the CMD, check the PLM minor code | Depends on error. Follow similar to 0x220e command |
0x10B | Error when valid CDO header ID is not present in CDO header. | Please check the bif file and make sure partition type is CDO for only CDO files and not for others. 3 |
0x10C | Error when CDO header checksum is wrong. Can happen when CDO header is corrupted | 3 |
0x10D | Error when XilPM request device for UART fails. PM error code is present in PLM minor code | 1 Minor Error code: XilPM |
0x10E | Error when UART driver lookup fails | 5, 1 |
0x10F | Error when UART driver config fails | 5, 1 |
0x110 | Error when SSIT slave sync fails with master | Check the error in Master SLR |
0x111 | Error when SSIT master times out waiting for slaves sync point | Check if there is any error in Slave SLRs. Check the boot PDI for proper sync commands in both Master and Slave SLRs |
0x112 | Error when invalid log level is received in Logging command | Check the IPI command if valid log level is specified or not. Refer to CDO spec to know the valid log level values. |
0x113 | Error when invalid log buffer address is received in Logging command | Check the IPI command if buffer address is valid or not. Refer to CDO spec to know he valid buffer address values. |
0x114 | Error when invalid log buffer length is received in Logging command | Check the IPI command if buffer length is valid or not. Refer to CDO spec to know he valid buffer length values. |
0x115 | Error when command execution through IPI is not supported | Command is not supported through IPI and is only supported through CDO in PDI. Refer to CDO spec to check if the command is supported through IPI or not. |
0x116 | Error when registering IoModule Handler | 1 |
0x117 | Invalid Periodicity parameter for SetWDT command | Check the WDT parameters given in Vivado. Minimum periodicity value is 15ms |
0x118 | Invalid Node ID parameter for SetWDT command | Check the Node ID parameter generated from Vivado. Only PMC and LPD MIO node ids are supported. |
0x119 | LPD MIO is used for WDT but LPD is not initialized | Set WDT CDO command uses LPD MIO node before LPD is initialized. This means SetWDT CDO command is present before LPD CDO (Lpd init finish command) is executed. Ensure SetWdt is selected in Vivado and corresponding PMC/LPD CDO is used |
0x11A | Invalid Interrupt ID used to disable interrupt | 1 |
0x11B | Invalid Interrupt ID used to clear interrupt | 1 |
0x11C | Invalid Interrupt ID used to register interrupt handler | 1 |
0x11D | Dma transfer wait failed | 1 |
0x11E | Non Block Dma transfer wait failed in Src channel | 1 |
0x11F | Non Block Dma transfer wait failed in Dest channel WaitForDone | 1 |
0x120 | Non Block Src Dma transfer wait failed | 1 |
0x121 | Non Block Dest Dma transfer wait failed | 1 |
0x122 | Dma Xfer failed in Src Channel wait for done | 1 |
0x123 | Dma Xfer failed in Dest Channel wait for done | 1 |
0x124 | Memset of UartPsv Instance failed | 1 |
0x125 | Error during memcpy of CdoCopyCmd | 1 |
0x126 | Error during memcpy of CdoCmdExecute | 1 |
0x127 | Error during memcpy of XLoader_ImageInfo | 1 |
0x128 | Error during setting XUartPsv_SetBaudRate to XPLMI_UART_BAUD_RATE | Please check the baudrate selected in Vivado is valid. |
0x129 | Invalid IoModule Interrupt Number used to register interrupt handler | 1 |
0x12A | Invalid IoModule interrupt Number used to clear interrupt | 1 |
0x12B | Invalid IoModule interrupt Number used to disable interrupt | 1 |
0x12C | Detected NPI errors in NPI root (REG_ISR) | NPI errors bits can be set when invalid NPI address or unaligned NPI address is accessed. This can also occur when DMA writes to NPI block is not 16 byte aligned. RNPI errors are enabled in PLM from 2021.1. Please use RNPI and bootgen from 2021.1 or above to make sure NPI address alignment is taken care in tools. NPI_NIR_ERR_LOG_P0_INFO_1 + 0xF600_0000 gives the NPI address which generated the error. |
0x12D | IPI CRC mismatch error | CRC is enabled in PLM for IPI channel. Make sure to have CRC enabled in ATF/IPI client examples. 1 |
0x12E | Error in processing IPI request It could be due to invalid message length error when CRC is enabled or invalid buffer address error from driver | Check if valid message length(0x8) is passed to |
0x12F | Error during DMA involving of unaligned SrcAddr, DestAddr or number of words | 1 |
0x130 | Access permissions failed for PLMI IPI command received | IPI and CDO commands share the same command structure. If a particular command is supported in IPI, then this error occurs. Please check CDO spec for supported commands through IPI. Also, check the subsystem permissions |
0x131 | Error when the task that is being added to scheduler already exists | If custom PLM code is added, please check if same task is added scheduler again. |
0x132 | Error when invalid task type is used to add tasks in scheduler | If custom PLM code is added, please check if the task type is correct is not. Valid task types are periodic and non-periodic tasks. |
0x133 | Error when invalid task period is used to add tasks in scheduler | For a periodic task, period in ms shall be mandatorily specified. If custom PLM code is added, please check if valid period is specified or not. |
0x134 | Error locking NPI address space | 1 |
0x135 | Invalid ProcID received | This error occurs when invalid ProcID is received during Proc execution. Please check if ProcID provided is stored in proc location. |
0x136 | Maximum supported proc commands are received | This error occurs when maximum supported proc commands (10) are already received to PLM. No more procs can be stored. |
0x137 | Received proc doesn’t fit in proc memory | This error occurs when available proc memory is less than proc command payload. No more procs can be stored. |
0x138 | LPD is not initialized. Proc commands can not be stored/executed | This error occurs when LPD is off and PLM received proc commands to be stored or executed. Proc commands cannot be stored or executed when LPD is not on/initialized as PSM RAM is used for this purpose. |
0x139 | Scheduler task missed executing at the scheduled interval | This error occurs when scheduler task missed executing in scheduled interval due to other tasks got scheduled. |
0x13A | Error when setting PMC IRO frequency | This error occurs when invalid IRO frequency is passed. But PLM passes proper IRO frequency. |
0x13B | Error received from SSIT Slave SLR | This error occurs in Master SLR when Slave SLR failed due to some error while loading PDI. Please check the error in Slave SLRs. |
0x13C | Error when the given address range for storing Proc commands is invalid | This error occurs when the PSM RAM address range given by PSM Firmware during boot for storing procs is invalid. |
Error codes used in PLM main application | ||
0x200 | Error when task create fails. This can happen when max tasks are created | If custom PLM code is added, please increase the XPLMI_TASK_MAX in xplmi_task.h as per the needs. |
0x201 | Error initializing the PM Module | 1 |
0x202 | Error initializing the LPD Module | 1 |
0x203 | Exception has occurred during PLM initialization. EAR and ESR are printed on UART console if enabled. | Please check the EAR value to know the address which PLM failed to access for further debug. Observed in cases where GTY memory or PCSR registers are not accessible by PLM in SRST cases. |
0x204 | Unable to lock NOC PLL for master SLR devices | 1 |
0x205 | Error initializing the STL Module | 1 |
0x206 | Error while creating PSM keep alive task | Minimum FTTI time is 100ms. Please check the FTTI for PSM Alive task. Try to increase the number of tasks in xplmi_task.h if custom tasks are added. |
0x207 | Error while removing PSM keep alive task | 1 |
0x208 | PSM is not alive | Make sure to use PLM and PSM elf from the same release. PMC RAM shall not be powered off by using any custom code as counter is placed in PMC RAM. |
0x209 | Error while sending IPI | Make sure in Vivado to enable PMC and PSM IPI in the project. |
0x20A | Error while clearing the PMC CDO region in PMC RAM | This error occurs when clearing secure state of PMC. |
Error codes used in XilLoader | ||
0x300 | Error for unsupported bootmode. It occurs if invalid boot mode is selected or selected boot mode peripheral is not selected in CIPS | Check the boot mode on the board and check if it is valid boot mode or not. Make sure to enable boot peripheral in CIPS so that PLM elf has corresponding driver included to boot from device. |
0x302 | Multiple conditions can give this error.
| Please check if proper flash configuration is done in Vivado and PLM is able to read data from flash device. Make sure PDI is copied properly in flash / DDR. |
0x303 | Error if image header checksum fails | Please check if proper flash configuration is done in Vivado and PLM is able to read data from flash device. Enable DEBUG_INFO in xplmi_config.h and read the image header data from PPU RAM that is copied from flash and check for correctness. |
0x304 | Error if partition header checksum fails | Please check if proper flash configuration is done in Vivado and PLM is able to read data from flash device. Enable DEBUG_INFO in xplmi_config.h and read the image header data from PPU RAM that is copied from flash and check for correctness. |
0x305 | Error waking up the A72-0 during handoff. Check the PLM minor code for PM error code | Please check minor error code received from PM to know the reason for failure |
0x306 | Error waking up the A72-1 during handoff. Check the PLM minor code for PM error code | Please check minor error code received from PM to know the reason for failure |
0x307 | Error waking up the R5-0 during handoff. Check the PLM minor code for PM error code | Please check minor error code received from PM to know the reason for failure |
0x308 | Error waking up the R5-1 during handoff. Check the PLM minor code for PM error code | Please check minor error code received from PM to know the reason for failure |
0x309 | Error waking up the R5-L during handoff. Check the PLM minor code for PM error code | Please check minor error code received from PM to know the reason for failure |
0x30A | Error waking up the PSM during handoff. Check the PLM minor code for PM error code | Please check minor error code received from PM to know the reason for failure |
0x30C | Error for unsupported OSPI flash | Check if the flash is present in the supported flash list by Xilinx. <AR link for supported devices list> PLM recognizes OSPI flash based on flash ID. Flash ID is not supported |
0x30D | Error for unsupported OSPI flash size | Check if the flash is present in the supported flash list by Xilinx. <AR link for supported devices list> PLM recognizes OSPI flash based on flash ID. Flash ID is not supported |
0x30E | Error when OSPI driver lookup fails. | 1 |
0x30F | Error when OSPI driver CFG fails | 1 |
0x310 | Error when OSPI driver is unable to select flash CS0. Check minor code for OSPI driver error code | 1 |
0x311 | Error when OSPI ReadID fails | Check the flash configuration (MIO and clock) selected in CIPS. Check if the flash connections are made correctly on board. |
0x312 | Error when OSPI driver read fails. Check minor code for OSPI driver error code | Check the flash configuration (MIO and clock) selected in CIPS. Check if the flash connections are made correctly on board. |
0x313 | Error when OSPI is unable to enter/exit 4B mode | Check if the flash supports 4 Byte mode |
0x314 | Error when QSPI read fails | Check the flash configuration (MIO and clock) selected in CIPS. Check if the flash connections are made correctly on board. |
0x315 | Error when QSPI flash ID is not supported | Check if the flash is present in the supported flash list by Xilinx. <AR link for supported devices list> PLM recognizes QSPI flash based on flash ID. Flash ID is not supported |
0x316 | Error when QSPI driver look up or cfg fails | 1 |
0x317 | Error when QSPI driver manual start fails | 1 |
0x318 | Error when QSPI driver Prescalar setting fails | 1 |
0x319 | Error when invalid QSPI connection listed other than Single, Dual, stacked | Check if the QSPI connection mode is selected properly in CIPS and connections are proper on board. There are other cases where this error code can come. If PLM finds any error, PLM does a soft reset in non-JTAG boot modes. In those cases, there can be chances where same boot image is booted again with different multiboot value. ROM checks for 512M in parallel mode, so if QSPI flash size is 256M, address wraps around to 0x0 and it boots the same image. PLM checks for multiboot value and flash size. As it is beyond flash size, PLM fails with QSPI error. To debug the issue properly, enable PLM_DEBUG_MODE to debug the system at first PLM error. |
0x31A | Error when QSPI driver Read fails | Check if the QSPI connection mode is selected properly in CIPS and connections are proper on board. |
0x31B | Error when QSPI read length is greater than flash size | Offsets in partition header point to the offset greater than the QSPI flash size. Check if PDI is fully copied into flash or not. Check if the offset specified in the bif fits into the QSPI flash from the start of boot image. |
0x31C | Error when SD mount fails | 1 |
0x31D | Error when SD file open fails. This can happen when file is not present or read from SD fails. File system error code is present in PLM minor code | Check if SD is formatted properly with FAT32 file system or not. Check if BOOT.BIN file is present. Check if required SD controller is selected in CIPS and connections are proper on board. |
0x31E | Error when f_seek fails while reading from SD card | Check if BOOTXXXX.BIN is copied properly into the filesystem. |
0x31F | Error while reading from SD card | Check if BOOTXXXX.BIN is copied properly into the filesystem. |
0x320 | Error when Image ID is not found in subsystem while reloading image | Reload image is used by PM for subsystem restart or through IPI to request for any reload of a image. Cross check the image IDs / subsystems IDs present in the initial boot image or later added to the image store or not. |
0x321 | Error while loading to TCM and if address is out of range | Check the load address of R5 application. It might be more than TCM range for R5-0/R5-1/R5-lockstep. For R5-0 / R5-1: Valid TCM load address values are 0-128KB For R5-lockstep: Valid TCM load address values are 0-256KB Use bootgen read command to read the load address and length values for R5 partitions for checking. |
0x322 | Error when CFRAME driver look up fails | 1 |
0x323 | Error when CFRAME driver CFG fails | 1 |
0x324 | Error for unsupported secondary boot mode | Check if secondary boot mode device is enabled in design or not. Check if secondary boot mode is in the list valid secondary boot mode devices for PLM. |
0x325 | Error when meta header secure validations fail | Error occurs when security is enabled on board and metaheader is neither authenticated nor encryption. Check if encryption/authentication is enabled in BIF |
0x326 | Error caused due to mismatch in IDCODEs | PLM checks for the IDCODE and extended IDCODE during configuration. IDCODE/extended IDCODE should match the part and extended ID code should be non-zero.
Please make sure to select the correct part(including silicon version) in Vivado for successful configuration. Please make sure you are running the PDI on the board which has correct Silicon version(S80-ES1 vs S80-PROD) and part (vck190 vs vmk180 vs vck5000/v350) |
0x327 | Error when USB lookup fails | 1 |
0x328 | Error when USB cfg initialize fails | 1 |
0x329 | Error when USB fails to start | 1 |
0x32A | Error when pdi fails to download | 1 |
0x32B | Error occurred while processing CDO but error is deferred till whole CDO processing is completed | CDO Deferred error. Currently deferred error will occur only when DDR calibration is failed. Log:
In PLM, Mask Poll has timed out after waiting for <TimeOut(1000000)> us for the expected value <(ExpVal: 0x10)>, reading from Address <Addr (0xF6110008)> From 2021.1, support is being added in PLM to print the DDRMC registers for calibration failure. OR, From PG313, user can run the “report_hw_ddrmc” command in Vivado, to get state of DDR status registers. |
0x32C | Error when SD look up fails | 1 |
0x32D | Error when SD config fails | 1 |
0x32E | Error when SD card init fails | Check the MIO, clock configuration in CIPS |
0x32F | Error when MMC part configuration fails | Check the MIO, clock configuration in CIPS |
0x330 | Error while stopping the SEM Scan | Error occurs when there is a hardware failure. Enable Error notification for XilSEM to get notified when there is any internal/fatal error |
0x331 | Error while starting the SEM Scan | Error occurs when there is a hardware failure. Enable Error notification for XilSEM to get notified when there is any internal/fatal error |
0x332 | Error when both delay handoff and delay load are set for the same image | Check the bif file if delay_handoff and delay_load are set for the same image. |
0x333 | Error when number of CPUs exceed max count | PLM supports maximum of 10 CPUs for handoff for a single image. Generally 10 is good for any use case. |
0x334 | Error when OSPI mode is not supported | 5 |
0x335 | Error when OSPI driver is unable to select flash CS1. Check minor code for OSPI driver error code | 1 |
0x336 | Error when OSPI driver is unable to set the controller to SDR NON PHY mode | 1 |
0x337 | Error when source address in OSPI copy exceeds flash size | Check if the PDI is fully present inside the OSPI Flash |
0x338 | Error on closure of file in SD filesystem modes | 1 |
0x339 | Error on unmounting filesystem | 1 |
0x33A | DMA Transfer failed | 1 |
0x33B | DMA Transfer failed in SD Raw | 1 |
0x33C | Error while configuring subsystem | Minor Code: 0x7D3 Please check the Image ID in bif files for APU and RPU images. For a default subsystem, Id should be 0x1c000000. |
0x33D | Error on copying image to DDR with the copy to memory attribute enabled | Copy failed from flash to DDR address. Check the image lengths and addresses of flash to make sure they are in range. Make sure DDR is present in the design and DDR is initialized (rnpi file is loaded) before using the copy_to_memory attribute for any image. |
0x33E | When the image has delay load attribute set and the boot source is SMAP, SBI, PCIE or JTAG, the image is copied to PMC RAM to free it from the SBI buffers. Errors occurred during such copies to PMC RAM is denoted using this error code | 0x223E: minor Code: 0x7D3 Topology CDO not included in PMC CDO. 0x223E: Minor Code: 1 Check if the PL power is present or not. This can happen when bif does not have valid subsystem IDs. |
0x33F | Error while adding task to the scheduler | Error happens when max normal or scheduler tasks are created in PLM. Check if any normal or scheduler tasks are added to PLM using custom code. |
0x340 | Error code returned when search for bootable file crosses max limit | Check the multiboot offset value. Max value for SD in file system mode is 8190. |
0x341 | Error when QSPI flash Size is not supported | Check the supported QSPI flashes and their sizes with Xilinx. |
0x342 | Failed in XPM Request Device for PM_DEV_PSM_PROC | Error occurs when request device fails for PSM processor while loading elf. Check for any PM error codes in the PLM console log for the reason |
0x343 | Failed in XPM Device Ioctl for RPU0_0 in SPLIT mode | Check for any PM error codes in the PLM console log for the reason |
0x344 | Failed in XPM Device Ioctl for RPU0_1 in SPLIT mode | Check for any PM error codes in the PLM console log for the reason |
0x345 | Failed to XPM Device Ioctl for RPU0_0 in LOCKSTEP mode | Check for any PM error codes in the PLM console log for the reason |
0x346 | Failed to XPM Device Ioctl for RPU0_1 in LOCKSTEP mode | Check for any PM error codes in the PLM console log for the reason |
0x347 | Failed to XPM Request Device for PM_DEV_TCM_0_A | Check for any PM error codes in the PLM console log for the reason |
0x348 | Failed to XPM Request Device for PM_DEV_TCM_0_B | Check for any PM error codes in the PLM console log for the reason |
0x349 | Failed to XPM Request Device for PM_DEV_TCM_1_A | Check for any PM error codes in the PLM console log for the reason |
0x34A | Failed to XPM Request Device for PM_DEV_TCM_1_B | Check for any PM error codes in the PLM console log for the reason |
0x34B | Failed to XPM Request Device for PM_DEV_DDR_0 | Check for any PM error codes in the PLM console log for the reason |
0x34C | Failed to XPM Request Device for PM_DEV_QSPI | Check for PLM minor error code received from PM |
0x34D | Failed to XPM Request Device for PM_DEV_SDIO_0 | Check for PLM minor error code received from PM |
0x34E | Failed to XPM Request Device for PM_DEV_SDIO_1 | Check for PLM minor error code received from PM |
0x34F | Failed to XPM Request Device for PM_DEV_USB_0 | Check for any PM error codes in the PLM console log for the reason |
0x350 | Failed to XPM Request Device for PM_DEV_OSPI | Check for PLM minor error code received from PM |
0x351 | Device ID of the image to be loaded is not defined | 1 |
0x352 | Failed to Query Parent ID of an image while verifying its Image UIDs | Check if the Partial PDI loaded belongs to the same design, 1 |
0x353 | Error while checking compatibility of a image with it's parent | Check if the Partial PDI loaded belongs to the same design, 1 |
0x354 | Error if No Valid Parent Image Entry is found in the ImageInfo Table | 1 |
0x355 | Error while Invalidating the Child Image Entry | 1 |
0x356 | Error when Invalid ParentImgID is obtained when queried for parent ImgID | 1 |
0x357 | Error when ImageInfo Table overflows | This occurs when more than 48 distinct images are loaded by PLM. Ideally this number should be sufficient in most of the cases. |
0x358 | Error when Function ID given while loading Image from DDR is not matching with the ID stored in Image Header | Check if the function ID used while Restarting or Reloading a image is correct Note: UIDs and Function IDs are not enabled by default in Vivado in 2021.2 Release |
0x359 | Error during memset | 1 |
0x35A | Error when source address, destination address or length params passed to XLoader_DdrCopy are not word aligned | 3 |
0x35B | XPlmi_InitCdo failed | 1 |
0x35C | Error when the load address of the elf is not valid | Check the load address of the elf used in the bif. This might occur if the elf is attempted to load to a restricted address |
0x35D | Error due to unsupported Flash Type used with Update Multiboot command | Check the Flash Type argument used with Update Multiboot command Refer CDO spec for more details related to the command. |
0x35E | Error due to unsupported PdiSrc used with Update Multiboot command | Check the PdiSrc argument used with Update Multiboot command Refer CDO spec for more details related to the command. |
0x35F | Error due to unsupported Filenum used to update multiboot register | Check the FileNum argument used with Update Multiboot command Refer CDO spec for more details related to the command. |
0x360 | Error when given multiboot offset is not valid (not a multiple of 32K) | Check the multiboot offset value passed to the Update Multiboot command. Make sure it’s a multiple of 32K |
0x361 | Error as secure critical code is excluded and Secure boot is attempted | Check if PLM_SECURE_EXCLUDE macro is enabled. If enabled, secure boot doesn’t work. |
0x362 | Error when unsupported PdiSrc is used for subsystem load | Check the PdiSrc argument in LoadPdi command used to load partial PDIs |
0x363 | Error when PdiList is full and user is trying to add a new PdiAddr | PLM supports a maximum of 32 PDIs to be added to ImageStore during run-time. This error occurs if more than 32 PDIs are used. |
0x364 | Error when PdiAddr that is being added already exists in the PdiList | Check the Pdi Addr used to add the PDI to ImageStore |
0x365 | Error when PdiList is empty and user is trying to remove a PdiAddr | No PDI has been added during run-time to Image Store. Add one before trying to remove it. |
0x366 | Error when the PdiAddr that is being tried to remove does not exist in the PdiList | Error occurs when given PdiAddr is not in ImageStore. Check the PdiAddr used to remove the PDI |
0x367 | Failed to XPM Release Device for PM_DEV_DDR_0 | Check if DDR is in requested state to release it |
0x368 | Failed to Request Boot Device | Reserved |
0x369 | Failed to Release Boot Device | Reserved |
0x36A | Failed to disable DUAL BYTE OP | Error occurs when there is an issue in disabling dual byte operation mode for OSPI during initialization. |
0x36B | Invalid TCM address for A72 elfs | This error occurs when TCM address is invalid for loading A72 elfs. Verify the A72 elfs and the boot image if the valid TCM address is provided or not. |
0x36C | Invalid destination address for copying ATF Handoff Parameter | Check is the passed destination address where the Handoff parameters to be stored is in valid range |
0x36D | Invalid destination size for copying ATF Handoff Parameters | Check if the destination size is enough to hold the requested Handoff parameters |
Error codes used in XilSecure | ||
0x600 | Failed to get DMA instance at time of initialization | 1 |
0x601 | Only SHA3 checksum is supported | Only SHA3 checksum is allowed for the partition. Check in the bif if checksum other than SHA3 is being used for the partition |
0x602 | Failed when copying Checksum from flash device | Failure in copying checksum from flash. Check the image lengths and addresses of flash to make sure they are in range |
0x603 | Failed when copying AC from flash device | Failure in copying Authentication Certificate from flash. Check the image lengths and addresses of flash to make sure they are in range |
0x604 | Failed as checksum was enabled with authentication and encryption enabled | Checksum should not enabled along with authentication/encryption for a partition. Please check the bif to ensure that either checksum or authentication/encryption is enabled for given partition. |
0x605 | DMA Transfer failed while copying | 1 |
0x606 | Authentication is not enabled for Image Header table | Deprecated |
0x607 | Failed to get DMA instance for IHT authentication | 1 |
0x608 | Failed when copying IHT AC from flash device | Failure in copying Image Header Table authentication Certificate from flash. Check the image lengths and addresses of flash to make sure they are in range |
0x609 | Failed to calculate hash for IHT authentication | SHA3 hash calculation failed for Image Header Table. Please check XilSecure minor error codes to get more information about the cause of failure |
0x60A | Failed to authenticate IHT | Signature verification failed for Image Header Table. Please check if the hash calculated by Bootgen matches the hash calculated by SHA3 engine and correct RSA/ECDSA keys are being used. |
0x60B | Failed when copying IH/PH from flash device | Failure in copying Image Header/Partition Header from flash. Check the image lengths and addresses of flash to make sure they are in range |
0x60C | Failed due to AES init or Decrypt init or key selection failed | Error in initializing AES driver. Check if valid input parameters are passed |
0x60D | Failed to decrypt IH/PH | Error due to Secure Header decryption failure. Check if Key/Iv/AAD are proper in BIF Error due to decryption of partition data. This error might come for several reasons.
|
0x60E | Failed to authenticate IH/PH | Error occurs when signature verification is failed. Check if SPK is valid in BIF. |
0x60F | Neither authentication nor encryption enabled for IH/PH | Error occurs when security is enabled on board and metaheader is neither authenticated nor encryption. Check if encryption/authentication is enabled in BIF |
0x610 | Failed to get DMA instance for IH/PH authentication/decryption | 1 |
0x611 | Failed to calculate hash for IH/PH authentication | SHA3 hash calculation failed for Image Header/ Partition Header. Please check XilSecure minor error codes to get more information about the cause of failure |
0x612 | IH/PH is not encrypted | Error occurs when meta header is not encrypted but symmetric HWRoT is enabled. Please create boot image with encryption enabled for meta header |
0x613 | Authentication disabled for IH/PH | Deprecated Error occurs when meta header is not authenticated but asymmetric HWRoT is enabled. Please create boot image with authentication enabled for meta header |
0x614 | Failed to read IH and verify checksum | Error occurs when checksum is failed for IH. Check if proper boot image is loaded |
0x615 | Failed to read PH and verify checksum | Error occurs when checksum is failed for PH. Check if proper boot image is loaded |
0x616 | Hash calculation failed for partition authentication | SHA3 hash calculation failed for partition. Please check XilSecure minor error codes to get more information about the cause of failure |
0x617 | Partition authentication failed | Signature verification failed for partition. Please check if the hash calculated by Bootgen matches the hash calculated by SHA3 engine and correct RSA/ECDSA keys are being used. |
0x618 | Partition hash comparison failed | Error occurs when SHA3 checksum is failed for partition. Check if proper boot image with correct partition lengths is loaded |
0x619 | Partition decryption failed | Error occurs when partition decryption is failed. Please refer to minor error code for the cause of the failure |
0x61A | PPK Programmed but eFuse authentication is disabled | Authentication is compulsory if PPK hash is programmed in eFuses. Please enable authentication in your bif |
0x61B | PPK Programmed and BH authentication is enabled | Bootheader authentication is not allowed id PPK hash is programmed in eFuses. Please check your bif to ensure that bh_auth_enable is not included in bif. |
0x61C | PPK not programmed and authentication is enabled | Authentication is not allowed if PPK hash is not programmed in eFuses. Please disable authentication in your bif or program PPK hash in eFuses. |
0x61D | Encryption is disabled | Error occurs when meta header is not encrypted but symmetric HWRoT is enabled. Please check if meta header is encryption in the boot image |
0x61E | KAT failed | Error occurs when KAT fails for AES/RSA/SHA/ECDSA. Please check if AES/RSA/SHA/ECDSA engines are initialized properly and are in proper state |
0x61F | Data copy to internal memory failed | Error occurs when Device copy is failed for secure partitions. Check if boot device is initialized properly and length of the data is proper |
0x620 | Failed when total size is greater than Metahdr length | Error occurs when meta header length is greater than 64K. Check if BIF has more number of partition that is causing the overflow of meta header. And check if the block size of the encryption mentioned in the BIF is causing the issue. |
0x621 | Jtag Authentication failed when PPK not programmed | Authentication of JTAG message is not allowed as PPK hash is not programmed into eFuses. Please program PPK hash in eFuse before re-attempting. |
0x622 | Jtag Authentication disable efuse bit is set | Authentication of JTAG message is not allowed as JTAG disabled eFuse bits are programmed into eFuses. Please check on a different device on which the eFuse bits are not programmed. |
0x623 | Jtag Authentication failed when verification of PPK hash verification failed | The SHA3 hash of the PPK used in Authenticated JTAG message is not matching the PPK hash programmed in eFuses. Please use the correct PPK while creating the Authenticated JTAG message. |
0x624 | Jtag Authentication failed when verification of signature failed | Signature verification failed for Authenticated JTAG message. Please check if the hash calculated by Bootgen matches the hash calculated by SHA3 engine and correct RSA/ECDSA keys are being used. |
0x625 | Jtag Authentication failed more than once | Error occurs when user tries to push the auth-jtag bin when the previous attempt is failed |
0x626 | Failed to get DMA instance for JTAG authentication | 1 |
0x627 | Hash calculation failed before signature verification | SHA3 hash calculation failed for Authenticated JTAG message. Please check XilSecure minor error codes to get more information about the cause of failure |
0x628 | Failed to get Auth Jtag data with DMA Xfr | 1 |
0x629 | Error during memset for SecurePtr | Error during when initializing the Secure structure with 0. Please check if proper lengths are passed to the function |
0x62A | Error glitch detected | Error due to temporal redundancy failed. Please check if condition is altered between reads |
0x62B | Jtag Authentication failed when revoke id is programmed | The SPK ID used in Authenticated JTAG message is already revoked. Please use a different SPK ID in the Authenticated JTAG message. |
0x62C | Metaheader Key Source does not match PLM Key Source | The encryption key source for Metaheader must be same as PLM. Please check the encryption key source used for PLM and metaheader in the bif. |
0x62D | Invalid key source when encryption only is enabled | In case of Symmteric HWRoT boot mode(Encrypt only eFuse bits are programmed), only eFuse black key and BBRAM black key are the valid encryption key sources. Please check the encryption key source used in the bif. |
0x62E | Error when state of boot is non secure | Obsolete |
0x62F | Updating IHT as AAD failed during secure header decryption | Updating IHT in AES engine as AAD failed. |
0x630 | PDI version used in secure operations is unsupported | Secure flow is supported for PDI version < 4.0. Please check PDI version in Image header Table in PDI |
0x631 | Partition is not allowed to be encrypted if State of boot is non secure | Encrypted partition is not allowed if state of boot is non secure. Only allowed for Symmetric HWRot(Encrypt only efuse bits are programmed) or Asymmetric HWRot boot mode(PPK hash is programmed in eFuses). |
0x632 | User provided Device DNA is not valid | Please verify that the proper DNA is provided. |
0x633 | Failed to verify checksum of image headers | This error occurs when there is a mismatch in image header checksum present in PDI and calculated by PLM. Please verify if the image is created properly. |
0x634 | Failed to verify checksum of partition headers | This error occurs when there is a mismatch in partition header checksum present in PDI and calculated by PLM. Please verify if the image is created properly. |
0x635 | Failed to place either AES, RSA, SHA3 engine in reset | This error occurs when resetting secure engines fail while clearing the secure state of PLM. |
Source Level Debugging with Vitis
Prerequisite
Compilation Settings
Debugging software requires as minimum as possible optimizations to be used at build time in order to ensure that translation from C files to the final assembly code is as close as possible. This would translate on a proper debugging experience where stepping through the C files is performed in the written order. Any optimization in the build means that stepping through the code might end up jumping through the lines as the final application does not correspond 1:1 to the code written in C. The different components of the PLM have different build settings as shown below.
Application
The PLM application code is configured without optimization options, so there is no need of modifying anything in the setting to get a proper debug experience.
Board Support Package
The BSP is configured with -O2 optimization level, and LTO optimization enabled (-flto -ffat-lto-objects) in order to reduce the size of the library as much as possible. As mentioned before, this means that any attempt to debug code within the library would be almost impossible. Unfortunately removing the optimization is not possible at BSP level as that would lead to a size overflow in a way that the PLM would not fit in the memory.
Removing optimization ( File level example )
The board support package build architecture is designed in a hierarchical way, so that each library/driver has it's own Makefile that inherits the variables set in a higher level. Removing or reducing the optimization level on the PLM BSP requires modifying the Makefile of individual components, either changing the settings for the whole component or individual files.
As an example the Makefile for XilPlmi library can be modified in the following way at File level:
Default Makefile uses the same compilation options for all the C files in the directory, therefore to compile a single file with different options a new target has to be defined in the Makefile. In the bellow case xplmi.c is build using custom flags(highlighted below) rather than using the EXTRA_COMPILER_FLAGS defined for the whole library.
clean:
rm -rf $(LIBPLMI_DIR)/${OBJECTS}
rm -rf ${RELEASEDIR}/${LIB}
$(LIBPLMI_DIR)/xplmi.o: $(LIBPLMI_DIR)/xplmi.c $(INCLUDEFILES)
$(COMPILER) $(COMPILER_FLAGS) -g -ffunction-sections -fdata-sections -Wall -Wextra -Og $(INCLUDES) -c $< -o $@
$(LIBPLMI_DIR)/%.o: $(LIBPLMI_DIR)/%.c $(INCLUDEFILES)
$(COMPILER) $(COMPILER_FLAGS) $(EXTRA_COMPILER_FLAGS) $(INCLUDES) -c $< -o $@
Remember that rebuilding the platform project does not take into account any changes in the Makefile. A complete clean + build process is required. Additionally the PLM application needs to be rebuild as well to use the latest library files generated by the in the platform build process.
Debug Procedure
Configuring the Target Connection Details
Under Debug Configurations → Single Application Debug ( Create New Configuration ) as shown below
Choose Debug Type - “Attach to running Target” , Connect Type - Local (Direct Connection)/ New (for Remove Target Setup)
Connect Type - Local (Direct Connection)
Connect Type - New (for Remove Target Setup)
Enter the host name details with port # as example below
Apply above configuration and continue to debug, following view should get populated ( Left side panel showing the Subsystem List )
Open xsct console and list targets using “ta”
and select target Versal by “ta 1” command as below
Loading the Boot PDI and Mapping PLM elf symbols
device program <pdi file> - To download PDI via Jtag
Select ppu core target, stop and execute below command to map the symbols
memmap -file <plm.elf> - To map symbols
Setting breakpoints , step over , step in / out via options available in Vitis Tool / Menu Bar
Debugging via JTAG ( *2 xsdb instance)
Vitis IDE
After placing a breakpoint where needed, select the target PPU, and map the "plm.elf" as mentioned in above procedure
ta 9
memmap -file plm.elf
Stop the ppu core and run again for Vitis to sync with Hardware Target
Disable the Jtag Lock with below command
“configparams config-jtag-lock 0”
Now open second xsdb instance & execute below steps
Connect to HW { Local / Remote url }
Increase the default timeout(*value in milli sec) with below command
configparams default-config-timeout 300000
Program the device with boot pdi - this will make to hit the set breakpoint in IDE
device program <boot pdi>
We can see that in the Vitis IDE breakpoint is Hit, user can continue to further debug PLM
Debugging via DDR ( JTAG Download)
Load Partial PDI to DDR[eg: dow -data <partial pdi> 0x100 (ddr address)] and use the IPI commands to process this PDI
and put breakpoints in PLM for stepping in code.
Debugging via QSPI/OSPI/SD/eMMC
Add while loop in PLM main to get control of the core , to map the Symbols and continue further debug.
Debugging MB Core Dumps
Microblaze Core Dumps are logg’d by the PLM running on the MB core in the event on any exception, there could be various types of exceptions (Refer Below Table “ESR EC Encoding”) which could be triggered,
Some examples are shown below explaining the possible causes and solutions to address them.
Example Dumps :
*Refer MB ESR EC encoding table for the ESR register bit encoding below.
Core Dump | Debug Tips / Next Steps |
---|---|
[Stack Protection Violation] r30: 00000001 r31: f7ffffff pc: f0200308 msr: 00000600 ear: 000000f0235b50 esr: 00000de7 → Stack protection violation exception btr: f021d780 pvr slr: f0235ba0 | Based on the ESR register it indicates a Stack Protection violation, so there has been an stack overflow. → Based on the Call Trace we can check which function caused to hit the exception. → Increase the Stack size in the linker script to the required amount based on stack usage to fix the issue.
|
[Data Bus Error Exception] Received Exception | Based on the ESR register it indicates a Data Bus Error, Causes - → Accessing invalid address region (indicated by EAR register) → Accessing a memory region where protection is enabled or the requester don’t have R/W access to that region. Fix - → Check the address range we are trying to access as indicated in EAR register is valid or has required access permissions. |
[Unaligned data access exception] [3597.751431]Received Exception | Based on the ESR register it indicates a Unaligned data access exception Causes - → Accessing unaligned address, accessed address is indicated in EAR register. Fix - → Align the address access to word boundary |
Exception Address Register (EAR)
The Exception Address Register stores the full load/store address that caused the exception.
Exception Status Register (ESR) Bit Encoding
MB ESR EC encoding
EC [ 27:31] Exception Cause |
00000 = Stream exception |
00001 = Unaligned data access exception |
00010 = Illegal op-code exception |
00011 = Instruction bus error exception |
00100 = Data bus error exception |
00101 = Divide exception |
00110 = Floating point unit exception |
00111 = Privileged instruction exception |
00111 = Stack protection violation exception |
10000 = Data storage exception |
10001 = Instruction storage exception |
10010 = Data TLB miss exception |
10011 = Instruction TLB miss exception |
Refer below for the Microblaze reference guide
Reference https://docs.xilinx.com/v/u/en-US/ug984-vivado-microblaze-ref
SSIT Debug
Getting PLM Log for Secondary SLR / Slave SLR
plm log -log-mem-addr 0x10A019000 -log-size 0x1000 → SLR1 / Slave 0
plm log -log-mem-addr 0x112019000 -log-size 0x1000 → SLR2/ Slave 1
plm log -log-mem-addr 0x11A019000 -log-size 0x1000 → SLR3/ Slave 2
*log-size (Max: 0x4000)
error_status / jtag_status for Secondary SLR / Slave SLR
device status -slr <SLR number> error_status
device status -slr <SLR number> jtag_status
eg: device status -slr 1 error_status → SLR1
device status -slr 1 jtag_status → SLR1
PLM Compatibility between releases
Following table give the PLM compatibility details between releases:
PLM Version | Supported CDOs and BootGen Versions | Comments |
---|---|---|
2020.2 | CDOs: 2020.2 BootGen: 2020.2 | CDOs:
BootGen:
|
2020.3 | CDOs: 2020.3 to 2020.2 BootGen: 2020.3 to 2020.2 | CDOs: None BootGen:
|
2021.1 | CDOs: 2021.1 to 2020.2 BootGen: 2021.1 to 2020.2 (Non-Secure PDIs) BootGen: 2021.1(Secure PDIs) | CDOs: None BootGen:
|
2021.2 | CDOs: 2021.2 BootGen: 2021.2 to 2021.1 | CDOs:
BootGen: None |
2022.1 | CDOs: 2022.1 BootGen: 2022.1 | CDOs:
BootGen: None |
2022.2 | CDOs: 2022.2 BootGen: 2022.2 | CDOs: None BootGen: None |
2023.1 | CDOs: 2023.1 BootGen: 2023.1 | CDOs: None BootGen: None |
2023.2 | CDOs: 2023.2 BootGen: 2023.2 | CDOs: None BootGen: None |
2024.1 | CDOs: 2024.1 BootGen: 2024.1 | CDOs: None BootGen: None |
2024.2 | CDOs: 2024.2 BootGen: 2024.2 | CDOs: None BootGen: None |
Registers reserved for PLM
Following table lists the registers/memories reserved for PLM:
Register/Memory | Description |
---|---|
PPU RAM | This memory location which is of 384KB size is used for code, data and BSS section of the PLM ELF file |
PMC RAM | This memory location which is of 128KB size is used for processing tool generated data, for authentication/decryption chunks, boot modes and event logging (storing PLM print log and image trace log). Refer to the table below this for the detailed usage of PMC RAM. |
PMC_GLOBAL_GLOBAL_GEN_STORAGE0, PMC_GLOBAL_GLOBAL_GEN_STORAGE1 | Contains ROM execution time stamp. When PLM is active, it reads these two registers to obtain the execution time of ROM. These registers can be used after loading boot PDI |
PMC_GLOBAL_GLOBAL_GEN_STORAGE2 | Contains device security status, updated by ROM. PLM uses this register to determine if KAT needs to be performed. |
PMC_GLOBAL_GLOBAL_GEN_STORAGE4 | Used by PLM to store ATF handoff parameter address pointer. |
PMC_GLOBAL_PERS_GLOB_GEN_STORAGE0 | Reserved for XilPM to save the status of each power domain initialization |
PMC_GLOBAL_PERS_GLOB_GEN_STORAGE1 | Reserved for PLM for future use |
PMC_GLOBAL_PERS_GLOB_GEN_STORAGE2 | PLM and XilPM uses it to store reset reason |
Following table gives detailed usage of PMC RAM memory:
Description | Memory start address | Size |
---|---|---|
Intermediate storage for chunks(32K+32K) for PDI load | 0xF200_0000 | 64KB + 320B |
Unused (Free) | 0xF201_0140 | 16KB - 320B |
PLM Runtime Configuration Registers Area (RTCA) | 0xF201_4000 | 4KB |
SSIT PLM-PLM communication | 0xF201_5000 | 4KB |
Storing procs for Secure Lockdown | 0xF201_6000 | 3KB |
Unused (Free) | 0xF201_6C00 | 1KB |
SEM NPI Descriptor Table/DDR exchange RAM storage for Self Refresh use cases | 0xF201_7000 | 8KB |
UART log buffer | 0xF201_9000 | 16KB |
Events/Trace log buffer | 0xF201_D000 | 4KB |
Boot Header | 0xF201_E000 | 0xF80 |
Authentication Certificate | 0xF201_EF80 | 0xE60 |
Unused (Free) | 0xF201_FDE0 | 540B |
FAQs
How is PLM different from ZU+ FSBL?
The biggest difference is that FSBL either stops running after it hands-off to another application or keeps running in a loop after finishing its job. It does not service any interrupts after that. PLM can reload images, can load partial PDIs and service interrupts. PLM can be viewed as combination of FSBL and PMUFW of ZU+.
What else is different in PLM, architecturally?
In addition to handling configuration through CDOs (rather than psu_init), below are few other architectural differences in PLM:
Task based loop - PLM application is mostly task dispatcher
Modular/library based design to enable re-usability of modules of code across different applications
PDI loading and subsystem restart is moved to XilLoader library. It was part of FSBL source code in ZU+. Subsystem bring up and power management is part of XilPM library, it was done by PMU Firmware in ZynqMP.
PLM application as such appears much smaller. Where is other code part of PLM?
Bulk of PLM’s code is in libraries like XilPLMI, XilLoader, XilPDI, XilSecure and XilPM.
Why two components: PLM and PSM Firmware? What type of code will be present in each of these?
PLM is the main component of Versal device which is responsible for boot and run time management (Platform management, Error management, Partial reconfiguration, Subsystem restart, etc) of the device.
PSM Firmware on the other hand is responsible for run time management of PS block in the Versal device. It manages the PS subsystem during run time in communication with PLM.
What is PDI?
PDI stands for Programmable Device Image which is generated by BootGen and is similar to boot image of ZU+. BootGen takes PLM, configuration (CDOs) and subsystems elfs(PSM Firmware, ATF, U-Boot, R5 apps, etc) as an input and creates PDI file which can be decoded by RCU and PPU. RCU decodes this PDI and loads PLM to PPU RAM and handsoff to PPU processor. PLM running on PPU further decodes this PDI file (which is Boot/Full PDI), and loads the partitions.
What is partial PDI and how is it different from Boot PDI?
A Boot PDI or a full PDI contains PLM, board specific bitstreams and CDOs, PSM Firmware, ATF, U-BOOT, Linux, system.dtb, applications to be run on A72 or R5. A partial PDI can contain one or more of these except PLM. A partial PDI is always loaded after a boot PDI.
Is any board specific configuration present in PLM?
Board specific code should come in form of CDOs. PLM does not have any board specific code.
What are the various hooks provided in PLM code?
XPlm_HookBeforePlmCdo, XPlm_HookAfterPlmCdo and XPlm_HookAfterBootPdi are the hooks provided in PLM code. These hook functions are provided to add any user code as needed.
What Secondary Boot modes are supported in PLM?
QSPI24, QSPI32, SD0, SD1, EMMC, SD1_LS, USB, PCIe and OSPI are the secondary boot modes supported. Please refer to UG1283 for bootgen secondary BIF attributes.
What secure features are supported in PLM?
Encryption, authentication, checksum and authentication + encryption.
SEM, STL – How these safety related libraries of PLM are different?
SEM is for detecting/correcting SEU errors at PLM startup time and in run time, SEM does the scanning on CRAM/PL and NPI for any SEU errors. SEM also does the period scanning based on the customer requirement. This is included as static library in PLM.
STL is safety test library to detect any HW failures at run time, STL also run periodically by comparing HW Register context at regular intervals. STL integration to PLM will be delivered through lounge access.
What action does PLM take when any error occurs?
If the error occurred before Boot PDI load is completed, PLM dumps the required error registers. And if the bootmode is other than JTAG and PLM_DEBUG_MODE macro in xplmi_config.h file is not enabled, PLM updates the multiboot register and performs SRST. Otherwise, PLM takes the error action as per the configuration of Error Manager.
And when partial PDI load fails, PLM prints the error code on console and memory based on the print levels enabled.
What are the different error actions by PLM Error Manager?
The supported error actions by PLM for each error as of 2021.2 are SRST, POR, Error Out, Subsystem shutdown, Subsystem restart and Register notifier.
Please refer to Error Manager section in Chapter 8 on UG1304 for more details on register notifier error action.
What PR (Partial Reconfiguration) support is present in PLM?
PR from DDR, QSPI, SBI JTAG and SMAP sources is supported in PLM.
How is Readback triggered by user? What all can be readback?
CFI data and NPI data can be readback using PLM. Readback can be triggered by user with DDR, SBI_JTAG or SMAP as sources.
Since PMC doesn’t have a watchdog timer in PMC Domain, how to realize the functionality of same?
PLM has a framework to update the PLM health status periodically by toggling the Multiplexed I/Os when external Watchdog Timer is used. User can enable WDT by using Set PLM WDT parameters CDO command and can select PMC/LPD MIO and periodicity in milli seconds. PMC MIO is preferred over LPD MIO because when LPD MIO is selected, WDT will be disabled when the PS is down. Before running the Set PLM WDT CDO command, the MIO need to be configured as GPIO in corresponding CDO (PMC/LPD).
What is the current foot print of PLM? Is there any free space available to integrate X code with PLM?
Please refer to PLM Foot Print section above for PLM foot print details and it is expected to grow in the coming releases. Users can disable the unused drivers and modules using MACROs present in xplmi_config.h and add their own code. Current compiler optimization for Application is -O0 and for BSP it is -Os.
How to enable boot time measurements in PLM?
PLM_PRINT_PERF macro which is present in xplmi_config.h file in XilPLMI library enables boot time measurements in PLM. This macro is enabled by default right now.
Design Guidelines
Please make sure to follow the below design guidelines
PMC NoC should be connected to AIE to have successful AIE zeroization.
If not connected PLM will fail with a hang while processing ai_engine_data.cdo
PMC NoC should be connected to DDR to download any PS images like uboot targeted for DDR
If not connected PLM will fail downloading DDR images
If APU need to access DDR, PS CCI ports are mandatory
IPI Requirements
PMC and PSM IPI is mandatory for PLM-PSM communication
For PS(FPD), CDO to work properly, IPI is required for PMC - PSM communication.
APU IPI is mandatory for PLM-APU communication for uboot to work
Sysmon OT temperature settings should be properly selected. (Not valid from 2020.1)
PLM default programming for OT temperature alarm is SRST. So, proper sysmon OT temperature setting should be done in Vivado to avoid any SRST at cold temperatures.
Known Issues and Workarounds
Following table lists known issues and their workarounds.
Error Code/Message | Error Code Description/Sample PLM Log | Debug Tips |
---|---|---|
PLM stalled while programming |
| Please check the Design Guidelines |
0x32B |
|
|
0x326 |
|
|
0x12C | NPI Errors occurred while loading RNPI data. Log:
| Generally NPI errors come when access to NPI blocks has issues. Please check the the design and RNPI data generated. These are mainly observed while accessing GTY memory. Make sure to use 2020.3 or latest versions of Vivado. This can also occur when DMA writes to NPI block is not 16 byte aligned. NPI_NIR_ERR_LOG_P0_INFO_1 + 0xF600_0000 gives the NPI address which generated the error. |
0x33C Minor Code: 0x7F4 | Log:
| Please check the Image ID in bif files for APU and RPU images. For a default subsystem, Id should be 0x1c000000. |
0x223E Minor code: 0x7D3 | Log:
| Topology CDO not included in PMC CDO. No prints will be visible on UART. Need to check for prints in memory. |
0x223E Minor code: 0x1 | PLM error in PM init node command while processing RCFI partition. Log:
| Check if the PL power is present or not. In vck190, PL power can be checked using below system controller commands. For PROD silicon, voltage can be applied using below commands.
|
0x223E Minor code: | Log:
| This can happen when bif does not have valid subsystem IDs. Refer the below Power Nodes and subsystem values for IDs in below file. |
0x319 | Invalid QSPI connection. Check the QSPI connection (Single Vs Parallel Vs Stacked). | There are other cases where this error code can come. If PLM finds any error, PLM does a soft reset in non-JTAG boot modes. In those cases, there can be chances where same boot image is booted again with different multiboot value. ROM checks for 512M in parallel mode, so if QSPI flash size is 256M, address wraps around to 0x0 and it boots the same image. PLM checks for multiboot value and flash size. As it is beyond flash size, PLM fails with QSPI error. To debug the issue properly, enable PLM_DEBUG_MODE to debug the system at first PLM error. |
0x203 | Exceptions received during the PLM execution. Exception Address Register (EAR), Exception Status Register (ESR) are printed on the UART terminal. Please check the EAR value to know the address when PLM failed to access for further debug. | Mostly observed with NPI DCI component access while DDR MB still in sleep. Observed in cases where GTY memory or PCSR registers are not accessible by PLM in SRST cases. |
0x109 (Not valid from 2020.2) | This occurs when any CDO command fails. Most probable reasons include:
|
|
0x106 | Error when PLMI module is not registered. Can occur when invalid CDO CMD is processed by Xilplmi. Log:
|
|
aborting, 1 pending requests...PLM stalled during programming. | If PLM has PLM_DEBUG_DETAILED debug log level enabled and the PDI is being loaded using JTAG SBI this issue might occur. This is because the default timeout of device program is targeting the generic use case of PLM_DEBUG log level, and with DEBUG_DETAILED the PLM load time drastically increases due to huge number of prints. This results in a timeout from xsdb which gives this error. | Increase the timeout with below command on xsdb when PLM_DEBUG_DETAILED log level is enabled in PLM. |
Error Code: 0x256000F4 Minor Code: 0x00F4 | During secure boot, After PL loading is done then the PLM checks for the crypto bit | Try PDI programming on the different board where the crypto engines are enabled To check whether the crypto is enabled or not |
Revision History
2023.1
List of key features added in PLM for 2023.1:
Increased stack size by 1KB
Switch to SSIT events right after initial NoC path is configured
Add macro VERSALNET_PLM
Added invalid Commands handler Logic
Added support for SSIT Single EAM Event forwarding from Secondary SLRs
Added enable additional PPKs support
Added command to set FIPS mode
Removed Triggering of SSIT ERR2 from Secondary SLR to Primary SLR
Create Secure Lockdown as a Critical Priority Task
Handle SSIT Events from PPU1 IRQ directly
Notify Other SLRs about Secure Lockdown
Versal Net EAM Updates for PPU/MPU/CPM errors
Added PLM_RSA_EXCLUDE and PLM_ECDSA_EXCLUDE
Added Temporal redundancy to tamper response condition
Added Support for new Image Store Feature
Added OSPI support for gigadevice 512M, 1G, 2G Parts
Clear End Stack before processing any CDO partition
Security Features:
Added support for provisioning of SSIT devices
Added 5 PPKs support
Added Client Support for OCP
Added client support for DME
Added attestation support Added attestation support with device keys
Added Client side support for attestation
Added Example for X.509 request and attestation
Added OCP and CERT libraries to BSP for Versal Net
Enabled OCP by default for Versal Net
Added PCR Log update event for PCR log notification
Added PCR Extend support for Secure images
Added redundancy for Key Selection
Added support for opting big/little endian for ECDSA operation by using BSP configuration
Enable additional PPKs support by default for M50
Added check for zeroes before programming additional PPKs
2022.2
List of key features added in PLM for 2022.2:
Add tri state support for mio pins
Re-organize directory structure for xilsecure in misc folder
Set the default base address for ethernet slave
Clear MIO tri-state for power control pins
Replace DEBUG_DETAILED with DEBUG_ERROR for XPPU/XMPU
Add check for overlay config object permission
Do not turn off FPD for ETH wakeup source
Disable parity retry during DDR self-refresh
Add check for pinId and paramId before accessing
Read proper GIC wake event data type from ETH slave
Added IPI example for multiboot update command
Added IPI example for Add Image Store PDI command
Enable SSIT interrupts once the boot is done to support PLM - PLM communication for SSIT devices
Added XilLoader commands to separate section in PLM linker script
Added support for Get Handoff Parameters IPI command
Added IPI example for Load PDI command
Added support to read Optional Data in slave boot modes
Updated KAT status based on CDO config for Partial PDI
Copy IHT and Optional data to PMC RAM
Removed 12K mode support. Only 4K mode will be supported for PUF operations in Versal
Added check to verify if a particular DDR is enabled or not before dumping the DDR registers
Handle security related run-times tasks during In-Place PLM update
Added CDO command for Cframe data clear check for PL secure lockdown
Modified DelayedHandoffCpus condition to handle all possible values
Updated secure chunk size from 16K to 32K
Added redundancy checks to handle glitch attacks
Removed PM_CAP_SECURE capability for PSM, DDR and TCM banks
Added support for Versal SSIT PLM - PLM communication
Added "PLM Print to Log" as a new EAM error action and set this as default error action to some of the errors
Added PLMI commands to separate section in PLM linker script
Added SSIT event for SEM error notifications
Added new SW error event for XilSem to the EAM SW errors list
Added support for storing proc commands to PMC RAM
Added support for secure lockdown for tamper events, for boot failures if HALT_BOOT_ERROR_1_0 eFuse is programmed and when TamperTrigger IPI command is generated to PLM
Fix bug in enabling SLVERR for RTC registers as Battery_Disable is a write-only bit in RTC_CONTROL register
Added support for HBM temperature monitoring in PLM
Support Begin, End and Break commands across chunk boundaries
Replace XPAR_XIPIPSU_0_DEVICE_ID macro with XPLMI_IPI_DEVICE_ID
Updated XilPdi_ReadBootHdr prototype to improve readability
Added Optional data len in Image Header Table
Add compatibility check for In-Place PLM Update
Reduce maximum number of partitions from 32 to 20 and images from 32 to 10 for Versal
Security Features:
Fixed bug in accessing RSA 3072 and 2048 bit key size for client requests
Added GMAC support
Enhanced the code for size optimization
Provided access to clear PUF key
Removed tamper related code
2022.1
List of key features added in PLM for 2022.1:
Enable SLVERR for PLM related components\
Call XPlmi_EmInit after XPlm_PmInit to fix issue related to clearing PL errors which occurred during last boot
Added RTCA initialization for MIO Flush routine RTCA registers
Added performance time stamp prints during loading and processing of partitions
Remove hardcoding of PSM RAM address for proc reserved memory
Removed checking of SSIT errors during XPlmi_SsitWaitForDmaDone and call XPmcDma_WaitForDoneTimeout function during SSIT DMA wait for done
Clear PMC_GLOBAL_SSIT_ERR register during EAM init to clear any previous errors
Removed checking of SSIT errors in SSIT synchronization commands
Moved hardware definitions to standalone folder
Added xilpuf client-server support
Enabled ssit_sync per slave
Added support for OT_CHECK command
Added PL_POR before PMC reset
Added PLM exceptions to SW Errors list
Check error mask registers after error action is enabled or disabled
Check if error action is enabled before executing the handler
Fix DMA keyhole issue when commands starts at the 32k boundary
Enhance user configurability of PLM
Error handling support for XMPU/XPPU EAM errors
Decoupled checksum functionality from xloader_secure.c
Skip MJTAG workaround image for JTAG bootmode
Reduce stack usage of some APIs by storing instances of certain large data structures in PMCRAM at 0xF2008120
Move authentication certificate to PMC RAM at 0xF2008120
Limit attempts to enable JTAG when efuse bits are set
Fixed bug in loading A72 elfs from TCM
Print DDR dump only if PLM_DEBUG_MODE is enabled
2021.2
List of key features added in PLM for 2021.2:
Support for extracting metaheader of user PDIs during run-time
Support for Winbond QSPI flash
Support for Macronix OSPI flash
Support to disable the Auth JTAG after a user provided timeout
Fix issue in clearing CFI and CFU errors
Fix secondary boot issue in SD when multiboot offset is non zero
Added support for xilnvm commands
Renaming of error node ID and event ID for better clarity
Support to configure uart during run-time
Creation of separate task for each IPI Channel
Update IRO frequency to 400Mhz for MP, HP parts
Support for registering error callback function to be called when a task missed execution
Support for handling CPM_NCR and link-down errors
Support for proc command
Display on console what IPI channels are disabled
Skip providing ack for force power-down command
Security features:
64-bit address support for XilSecure server APIs
Validation for AAD size to check if it is quad-word aligned
EXPORT CONTROL eFuse check in all crypto init functions for ZynqMP and Versal
Rename of XSecure_AesPmcDmaCfgByteSwap API with XSecure_AesPmcDmaCfgAndXfer
Update check for Size in Client XSecure_AesKekDecrypt.Added check for DecKeySrc in Client XSecure_AesKekDecrypt
Client-server support for BBRAM and eFUSE
Addition of most restrictive range checks for device temperature before programming eFuses
Removed clearing the BBRAM User Data in case of failure
Replaced magic number 0x0 with FALSE
Updated validation to check for Trim2 instead of Trim 3 for protection bit 37
Added check to see if efuse bit is already programmed before programming
2021.1
List of key features added in PLM for 2021.1:
Functional Safety certification and FMEDA support (PLM and Sec libs)
PLM Image Store updates at runtime
Multiboot support at runtime
CRC support for IPI in PLM
PLM Access controls
PLM size optimizations, Boot time estimator
Security features
EncryptOnly AAD support
ECDSA updates
XilSecure client support
2020.2
List of key features added in PLM for 2020.2:
OSPI dual stacked support
Image store support for warm restart use cases
PLM WDT support
Parallel DMA for QSPI and OSPI cases
64 bit support for OSPI, DDR(SRC), SD
Parallel DMA support for XilLoader
Secure debug basic support
Glitch detection related features
128 bit AES key support
ECDSA P-521 curve support
Madagascar: Unique id support
Boot time estimator (Secure cases)
2020.1
List of key features added in PLM for 2020.1:
Program Space Access Control (Arbitration)
Event logging, debug error codes
Error Management
SD/eMMC raw boot
Boot time estimator enhancements
Deferred Handoff
Secure features
DPA CM enable/disable
AES KEK (PUF/Obfuscated) support for PDI
Secure partial PDI
Known Answers TestsAT
DEC_ONLY checks
Revocation ID for encrypted partitions
SPK granularity in PDI
Related Links
Related content
© Copyright 2019 - 2022 Xilinx Inc. Privacy Policy