Remote ZynqMP UltraScale reboot after program QSPI

[JimmiMarquart]

Hi,

TL;DR: I can program_flash the QSPI on the board, now how do I reboot the board after programming?

I have a build server that builds and flashes a ZynqMP board (specifically a Trenz TE0820 SoM 3cg_1e_2gb on a Trenz TE0703 carrier) using the Vivado 2018.3 utility program_flash, which works fine.  But after the flashing, the board is in a limbo state, and I have to manually press the reset button on carrier board, after which the board boots up fine and starts application on APU0.

I tried using the GLOBAL_RESET, RESET_CTRL and RST_FPD_APU regs, but these seem only to work when the application is running. However this is not the case right after a program_flash of the QSPI.

Is there an automated way to make the device reboot after program_flash has finished? I assume something like the POR_B pin.

BR
Jimmi

[JH]

Hi,
you can press boot from flash memory on Vivado HW Manager to force SW reboot (important that's not a power On reboot, so it depends also on the currently running system if this works!). Any power on reboot over SW is not implemented.

TE0820 and TE0703 has CPLD, so you can develop your own procedure to force power on reboot over SoC, also PMU allows some to control some IOs on some events...so theoretical there are mechanism available to do what you link to have. But you must develop it by yourself.

br
John

[JimmiMarquart]

hmm, i might have been to focused on XSDK.

I tried using vivado, however it does not seem to respond well. In the tcl-console in Vivado i run:

Code: [Select]

exec program_flash -f BOOT.bin -fsbl <path>/test_board/prebuilt/software/3cg_1e_2gb/zynqmp_fsbl_flash.elf -flash_type qspi-x8-dual_parallel
This successfully writes to QSPI, and the UART displays:

--------------------------------------------------------------------------------
Xilinx Zynq MP First Stage Boot Loader to write QSPI Flash (TE modified)
Release 2018.3   Oct 28 2019  -  17:41:38
PMU-FW is not running, certain applications may not be supported.

Now we are in the "limbo-state" and i run

Code: [Select]

get_hw_devicesand i get back xczu3_0 and arm_dap_1 I guess its fine if I can reset one of the cores for a start (assuming I should have xczu3_0 and xczu3_1) hence running

Code: [Select]

boot_hw_device xczu3_0And the results give me:

INFO: [Labtoolstcl 44-664] Will wait up to 180 seconds for booting to complete.
WARNING: [Xicom 50-184] Defaulting to hardware boot mode: QSPI32.
INFO: [Labtools 27-2278] Zynq reset successful

Which seems fine, however I never see the application boot up, and print to UART.
I also tried with the prebuilt from Trenz (TE::pr_program_flash_binfile -swapp hello_te0820).

However if i press the power-on-reset button on the carrierboard (and wait for it to boot up), and run

Code: [Select]

boot_hw_device xczu3_0 I see the application boot, and print to UART. Hence like previously, it seems only to work, when the device actually have been booted.

I dont know whether itis  worth mentioning that our boot.bin consists of fsbl.elf, pmufw.elf, bitstream.bit, bl31.elf, uboot.elf, apu0.elf and apu1.elf. Where apu0 is for APU0 and apu1 is for APU1.

[JH]

Hi,
you see the Xilinx message

INFO: [Labtoolstcl 44-664] Will wait up to 180 seconds for booting to complete.
WARNING: [Xicom 50-184] Defaulting to hardware boot mode: QSPI32.
INFO: [Labtools 27-2278] Zynq reset successful

The problem is that you make a soft reset and if this works depends on the running system and when you configure Flash with vivado, Xilinx starts some small uboot in the background. On some Vivado versions, soft reboots after flash programming works and on other it doesn't work....so it always depends on the design and the register setup on the previous running design...

You find basic information how ZynqMP works here:
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
https://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascale-registers.html
but there is much more available...

br
John

[JimmiMarquart]

Hi,

okay, that is not really what I hoped for.
The TE0820 will go straight into production, hence I have no influence on the previous design.
Hence I will either have to develop some kind of reset on our own carrier-board, or have a programmable power supply which will make a power cycle.

Thanks anyway.
BR
Jimmi