cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
eanjum
Visitor
Visitor
701 Views
Registered: ‎05-16-2018

Problems in the pm_cfg_obj.c file generated from the Vitis

I am facing a problem with the permission settings in the pm_cfg.obj.c file. The details are provided below.

Environment

  1. Xilinx Vivado v2019.2
  2. Xilinx Vitis v2019.2
  3. Petalinux SDK v2019.2

Configuration

System comprises of four domains created using the Vivado PCW. The secure domains are isolated from the non-secure domains.

  1. Domain 1
    1. Secure
    2. RPU is master. Includes some other peripherals and control registers
  2. Domain 2
    1. Secure
    2. PMU is master.Includes some other peripherals and control registers
    3.  
  3. Domain 3
    1. Non-Secure
    2. APU and other masters
  4. Domain 4
    1. Non-Secure
    2. displaydma

A separate domain “displaydma” is crated for the DPDMA to allow access only from the APU master. This prevents the regions overflow in the FPD XMPU due to other masters present in the APU domain. The XSA file for the system is attached Base_Zynq_MPSoC_wrapper.zip.

The boot sequence is

R5-0 :    FSBL-> application

                 |

APU-0 :  ATF ->U-BOOT ->Petalinux

 

Problem

The pm_cfg_obj.c generated by the Vitis allows APU to perform power management operations on the RPU domain such as wakeup ,suspend , power down and reset. These operations must be prohibited as the RPU domain is isolated from APU. The pm_cfg_obj.c file is attached .

For example in the L/N 81-85 suspend & Wakeup permission are guaranteed to APU

 

 

NODE_APU, /* Master Node ID */
PM_CONFIG_IPI_PSU_CORTEXA53_0_MASK, /* IPI Mask of this master */
SUSPEND_TIMEOUT, /* Suspend timeout */
PM_CONFIG_IPI_PSU_CORTEXR5_0_MASK | PM_CONFIG_IPI_PSU_CORTEXR5_1_MASK, /* Suspend permissions */
PM_CONFIG_IPI_PSU_CORTEXR5_0_MASK | PM_CONFIG_IPI_PSU_CORTEXR5_1_MASK, /* Wake permissions */

 

 

In  the power nodes section, APU is provided forced power down permissions for RPU . See L/N 462.

 

 

NODE_RPU, /* Power node ID */
PM_CONFIG_IPI_PSU_CORTEXA53_0_MASK, /* Force power down permissions */

 

 

Similarly in the reset section of the config object file,  APU is provided reset control of the devices assigned to the RPU domain.  E.g  L/N 529

 

 

 

/**********************************************************************/
/* RESET SECTION */
XILPM_RESET_UART1, PM_CONFIG_IPI_PSU_CORTEXA53_0_MASK | PM_CONFIG_IPI_PSU_CORTEXR5_0_MASK | PM_CONFIG_IPI_PSU_CORTEXR5_1_MASK,
For RPU reset
XILPM_RESET_RPU_LS, PM_CONFIG_IPI_PSU_CORTEXA53_0_MASK | PM_CONFIG_IPI_PSU_CORTEXR5_0_MASK | PM_CONFIG_IPI_PSU_CORTEXR5_1_MASK,

 

 

In order to further accentuate this behavior, I enabled the PM firmware interfaces in Petalinux mentioned @https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842232/Zynq+UltraScale+MPSoC+Power+Management+-+Linux+Kernel#ZynqUltraScale%EF%BC%8BMPSoCPowerManagement-LinuxKernel-Debugfs and executed the power down request on the RPU cluster from the user space which succeeded.

echo pm_force_powerdown 6 > /sys/kernel/debug/zynqmp-firmware/pm

Where 6 is the node ID for RPU cluster

Same thing happens for the nodes 7 and 9 which belong to RPU-0 and RPU-1, respectively.

My question is why the generated file is assigning power control permissions of RPU domain to APU given that they are isolated (as in the XSA)?

Please note that same behavior is observed even if the FSBL runs on the A53-0, however, this was done on the Xilinx SDK 2019.1

Thanks in advance for your help!

0 Kudos
Reply
1 Reply
mmcguirk
Moderator
Moderator
560 Views
Registered: ‎08-02-2007

Hi Etsam-

       Thanks for posting this. As this needs some in-depth investigation on our end, we are going to convert this into a Service Request and will be following up with you offline.

 

Thanks,

Michael

0 Kudos
Reply