02-10-2021 02:00 AM - edited 02-10-2021 05:08 AM
Zynq ultrascale system.
The watchdog apparently works and we end up with reset as expected except no bit in the reset_reason register (0xFF5E0220) is set after the watchdog trigger reset, we read value 0. Reset by other sources like RESET_CTRL, ps_por and ps_srst will set bit in reset_reason register as expected.
RegRead -b 0xFD4D0000 0x000001c3 RegRead -b 0xFD4D0004 0x000011e1
configapp -app pmufw define-compiler-symbols ENABLE_RECOVERY configapp -app pmufw define-compiler-symbols ENABLE_ESCALATION configapp -app pmufw define-compiler-symbols ENABLE_RECOVERY_RESET_SYSTEM
I dont find anything in TRM about no reset reason bit to be expected by SWDT1.
We use Xilinx-2018.3/SDK
02-11-2021 12:01 PM
Hi @Viking ,
Are you reading register through application? or directly from xsct console? Let me investigate more on this behavior looking at the previous known issues.
02-16-2021 01:45 AM
04-22-2021 05:45 AM - edited 04-22-2021 05:45 AM
Hi @Viking , typically when you use WDT timeout to trigger reset of system, the PMU subsystem manages the reset.
Please set the 13th bit (FPD_SWDT) of 0xFFD8056C (ERROR_SRST_EN_1) and check 0xFFD8053 (ERROR_STATUS_1) from FSBL after reset.
Also, look for Reset Reason in U-boot, it should show as PMU in your case.
Reset reason: PMU
05-20-2021 06:06 AM
Hi @debrajr! Thank you so much for your information, sorry for the late response. When I touch these registers (0xFFD8056C and 0xFFD80530) in U-boot the result is immediate system reset. This seems to be consistent for the complete PMU, since even a read of 0xFFD80000 (PMU_GLOBAL) results in system reset. Maybe this PMU issue is masking the expected watchdog reset and reset reason? I will review TRF and software developer guide but appreciate further advice.
05-21-2021 12:27 AM
I added some detailed debug output for PMU and get this during watchdog reset in QNX:
EM: FPD Watchdog Timer Error (Error ID: 18) Escalating to system level reset Ps Only Reset Err: #1 l2$ state#2 Err: #1 ocm0 state#2 Err: #1 ocm1 state#2 Err: #1 ocm2 state#2 Err: #1 ocm3 state#2 Err: #1 tcm0a state#2 Err: #1 tcm0b state#2 Err: #1 tcm1a state#2 Err: #1 tcm1b state#2 Err: #1 ttc1 state#1 Err: #1 ttc2 state#1 Err: #1 ttc3 state#1 Err: #1 gpupp0 state#0 Err: #1 gpupp1 state#0 Err: #1 uart0 state#1 Err: #1 uart1 state#1 Err: #1 spi0 state#1 Err: #1 i2c0 state#1 Err: #1 i2c1 state#1 Err: #1 sd0 state#1 Err: #1 eth1 state#1 Err: #1 eth2 state#1 Err: #1 eth3 state#1 Err: #1 adma state#1 Err: #1 gdma state#1 Err: #1 qspi state#1 Err: #1 gpio state#1 Err: #1 ddr state#2 Err: #1 ipi_apu state#1 Err: #1 ipi_rpu0 state#1 Err: #1 ipi_rpu1 state#1 Err: #1 pcie state#1 Err: #1 Avnet modifying SDHCI0 and SDHCI1 registers for UltraZed SOM Xilinx Zynq MP First Stage Boot Loader Release 2018.3 May 20 2021 - 15:45:17 PMU Firmware 2018.3 May 20 2021 15:54:16 PMU_ROM Version: xpbr-v8.1.0-0 EM: Enabling XMPU/XPPU interrupts EM Module (MOD-0): Initialized. DAP_WAKE (MOD-3): Initialized. LEGACY PWR UP/DN/ISO (MOD-4): Initialized. XPFW: Calling ROM PWRUP Handler..Done
I included some of the output during start-up which also include detailed PMU debug messages.
06-03-2021 11:53 AM
Hi @Viking ,
The way to access secure registers by U-Boot or Linux is using the firmware/power management drivers that use the ATF to communicate with the PMU firmware for several features. The Power Management API provides MMIO operations that allows to perform register read/write operations but for security reasons those operations are not provided to the userspace as it would allow to anybody to access to secure registers.
In U-Boot you can write you can use the zynqmp_mmio_read function in the boot code or a driver to perform the read operation. If the goal is to perform the operation from the U-Boot prompt you would need to create a new user command or a driver.
Also please refer the below wiki page for the restart solution.
Check the Healthy Bit Scheme, to avoid escalation.