cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
x_abacadaba
Observer
Observer
494 Views
Registered: ‎12-21-2017

PMUFW Error Manager and Vivado PS settings

I'm using Vivado 2018.3 with a Zynq Ultrascale+.  I'm attempting to enable the PMUFW Error Manager using the "ENABLE_EM" flag.  I've verified that when I enable that flag, it does compile in that section of code by purposefully placing errant code in there and viewing a compile error.  Anyway, I've followed the guidance of this page here:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841724/PMU+Firmware#PMUFirmware-ErrorHandlinginPMUFW
Here are my flag settings:

 

-DENABLE_SCHEDULER -DENABLE_EM -DENABLE_WDT -DENABLE_NODE_IDLING -DIDLE_PERIPHERALS -DREMOVE_GPIO_FROM_NODE_RESET_INFO -DXPFW_DEBUG_ERROR -DDEBUG_MODE

 


In my ARM Trusted Firmware build I also have:

 

EXTRA_OEMAKE_append = " ZYNQMP_WARM_RESTART=1"

 


In Vivado I've enabled both the SWDT 0, SWDT 1, and the CSU.

When I boot linux, and run the error injection test described in the PMUFW confluence page linked above, I don't see the code that is gated by the ENABLE_EM macro execute.  So I'm wondering is there (a) a flag that I missed, (b) some configuration option that I need to setup in the PS config in Vivado, or (c) something else???  I did notice that the SWDT 0, SWDT 1, and CSU/PMU WDT have interrupts that can be enabled, though it isn't entirely clear to me whether or not those tie into the Error Manager functionality.

Thanks.

ps-config.png
0 Kudos
4 Replies
denist
Xilinx Employee
Xilinx Employee
429 Views
Registered: ‎10-11-2011

The Wiki page should have everything you need. I am not aware of any other define needed for the PMUFW.

One question, Did you verify the PMUFW never gets inside the code inside the ENABLE_EM macro?

What kind of error are you inject (please provide steps or code) and what kind of action is the PMUFW configure to execute upon receiving that error?

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
x_abacadaba
Observer
Observer
425 Views
Registered: ‎12-21-2017

I'm following the instructions on the Wiki page for an OCM_ECC error, (so this):

# Enable ECC_UE interrupt in OCM_IEN
mwr -force 0xFF96000C [expr 1 << 7 ]
 
# Write to Fault Injection Data 0 Register OCM_FI_D0
# Errors will be injected in the bits which are set, here its bit0, bit1
mwr -force 0xFF96004C 3
 
# Enable ECC and Fault Injection
mwr -force 0xFF960014 1
 
# Clear the Count Register : OCM_FI_CNTR
mwr -force 0xFF960074 0
# Now write data to OCM for the fault to be injected
# Since OCM does a RMW for 32-bit transactions, it should trigger error here
mwr -force 0xFFFE0000 0x1234
 
# Read back to trigger error again
mrd -force 0xFFFE0000


I also added this code to the error handling at line 301 in xpfw_error_manager.c , just to see if the error handler is getting triggered:

 

	...
        for (Index = 1U; Index < EM_ERR_ID_MAX; Index++) {
		if (ErrorTable[Index].Type == ErrorType) {
			/* check if this error is triggered */
			if ((ErrRegVal & ErrorTable[Index].RegMask) != 0U) {
				/* Logging the error */
				ErrorLog[ErrorType] = ErrorLog[ErrorType] |
						(ErrRegVal & ErrorTable[Index].RegMask);

// MY CODE STARTS HERE
                u32 regval = 0;
				XPfw_Printf(DEBUG_ERROR,"PMU EM handled an error: %d\n", Index);
				regval = XPfw_Read32(PMU_GLOBAL_PERS_GLOB_GEN_STORAGE2);
				regval |= ((u32)ErrRegVal);
				XPfw_Write32(PMU_GLOBAL_PERS_GLOB_GEN_STORAGE2, regval);
...

 

I never see the print statment and pggs2 is always zero.  I've verified that the code is in fact compiled in by purposefully putting an error in the code and making sure the compiler catches it.

I will try to add a print statement in XPfw_EmInit to verify that the PMUFW executes code within ENABLE_EM.  I'll verify that in a follow up.  I'll go back through and make sure that I've not missed anything in the wiki as well.

0 Kudos
denist
Xilinx Employee
Xilinx Employee
337 Views
Registered: ‎10-11-2011

Maybe you can check from the application that triggers the error if the relative error_status bit is getting set.

I know it's not what you want, but it could be a debugging step to go directly to the register to see if the error is indeed triggered.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
x_abacadaba
Observer
Observer
325 Views
Registered: ‎12-21-2017

I've made some progress on this.  It seems like I can get my added code to execute by modifying the handler types to change them to "EM_ACTION_CUSTOM".  Which I think makes sense based on the example.  Perhaps I misinterpreted the code, but I expected the area where I added code to execute regardless of what type of error I set it to (even if it is set to EM_ACTION_PSERR for example) .  If I set it to any of the other types it doesn't appear to go through my code block.  So I'm going to go revisit my interpretation of the code.  Since I've been able to get EM_ACTION_CUSTOM to work, I think I may be able to get the functionality that I need going forward.

One thing I noticed is that on the confluence page it shows that ENABLE_SCHEDULER is enabled by default, but when I look at the default config it has:
#define ENABLE_SCHEDULER_VAL (0U)
Perhaps that gets set somewhere else by default?

Thanks for your replies.  I should be able to make forward progress now.  I think it would be nice if the confluence page had an example BD PS configuration to go along with the explanation.  I think that may have been one of my biggest issues.  I had to do many builds with different configurations of the SWDT0, SWDT1 and the CSU and PMU configuration setting in the interrupts before I got this to work, and I'm still not certain whether or not I have them correct for the behavior that I'd like to achieve (I may have unnecessary settings etc.).