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

ZynqMP multiboot and fallback hangs at SRST

Jump to solution

Hello,

I have a ZynqMP SoC that boots linux (created using petalinux) from QSPI in non-secure mode to the A53.  Additionally we do not use the R5 processor during the boot process.  I've implemented the following:

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842403/Zynq+Ultrascale+MPSoC+Multiboot+and+Fallback

with one exception; all of the use-cases in that article describe booting FSBL on an R5 then handing off to the A53 or vice-versa, booting FSBL on an A53 then handing off to the R5.  In my particular use-case we are using the petalinux tool flow and we run everything on the A53 from boot.  I've packaged my image so that there is a copy of my BOOT.BIN in the QSPI at 0x00000000 and again at 0x04000000.  My BOOT.BIN contains bl31.elf, system.dtb, zynqmp_fsbl.elf, pmufw.elf, image.ub, and system.bit.  The rootfs is mounted on eMMC.  All of this boots correctly when not executing fallback or multiboot, and if I put a line of code early in the FSBL to change the bootmode count register to my alternate image address 0x04000000 (corresponding to a value of 0x00000800 in that register) it boots my secondary image correctly.

In the call to 'XFsbl_UpdateMultiBoot' if I comment out the line:

XFsbl_Out32(CRL_APB_RESET_CTRL, RegValue|CRL_APB_RESET_CTRL_SOFT_RESET_MASK); 

and instead return from the function, the system will load my multiboot image.  But if I leave that line in and issue the reset the system hangs.

I've also read this:

https://www.xilinx.com/support/answers/57744.html

However I'm uncertain if it is applicable to the ZynqMP family (it looks to be targetted at the Zynq 7000 series)?  Regardless I added a manual QSPI reset and the system still hangs.

I've also read this:

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841820/Zynq+UltraScale+MPSoC+Restart+solution

Does this page coupled with the 1st confluence page regarding multiboot and fallback indicate that I have to implement subsystems in order to effectively issue the SRST for multiboot/fallback to work properly?

One other interesting thing to note:  If I load my FSBL via the system debugger, modify the multiboot register, then call the XFsbl_UpdateMultiBoot function (with the SRST enabled), the system resets and when I hit 'Run' in the debugger, it will boot my second image at offset 0x04000000.  So what am I missing here?

Thanks

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Observer
Observer
478 Views
Registered: ‎12-21-2017

I found the solution.  Based on this description here:

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841820/Zynq+UltraScale+MPSoC+Restart+solution#ZynqUltraScale+MPSoCRestartsolution-PMUFirmware

and inspection of the file xpfw_config.h in the pmufw source code repository, I found that adding the following to the recipe in my petalinux project fixed the SRST hang issue:

project-spec/meta-user/recipes-bsp/pmu/pmu-firmware_%.bbappend

with the contents:

YAML_COMPILER_FLAGS_append = " -DENABLE_EM -DENABLE_ESCALATION -DCHECK_HEALTHY_BOOT"

resolved the issue.  I will be enabling the SWDT next, and likely will require the -DENABLE_RECOVERY flag once SWDT is enabled.

View solution in original post

1 Reply
Highlighted
Observer
Observer
479 Views
Registered: ‎12-21-2017

I found the solution.  Based on this description here:

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841820/Zynq+UltraScale+MPSoC+Restart+solution#ZynqUltraScale+MPSoCRestartsolution-PMUFirmware

and inspection of the file xpfw_config.h in the pmufw source code repository, I found that adding the following to the recipe in my petalinux project fixed the SRST hang issue:

project-spec/meta-user/recipes-bsp/pmu/pmu-firmware_%.bbappend

with the contents:

YAML_COMPILER_FLAGS_append = " -DENABLE_EM -DENABLE_ESCALATION -DCHECK_HEALTHY_BOOT"

resolved the issue.  I will be enabling the SWDT next, and likely will require the -DENABLE_RECOVERY flag once SWDT is enabled.

View solution in original post