06-26-2019 12:47 AM
I am trying to boot a ZCU102 via JTAG. I have used the OSL flow to generate an FSBL, the PMUFW, the U-BOOT and the BL31. Everything seems to go fine until I run the kernel. It starts but hangs when bringing up the sercondary CPUs. Seems to be related to the PMU freezing when I want to boot using JTAG - I can see the PMU debug messages:
PMUFW: PmRequestWakeup: (NODE_APU_1, REQUEST_ACK_BLOCKING, 1, 4294877432, 0)
PMUFW: PmProcTrForcePwrdnToActive: FORCED_PWRDN->ACTIVE NODE_APU_1
I have tried with v2018.2, v2018.3. I have also tried with XSDK and Yocto rocko, sumo, thud. No combination works. Either PMUFW, FSBL, and U-BOOT do not agree, or the boot process hangs.
Can the ZCU102, or any other Zynq Ultrascale+ MPSoC be brouhgt up using JTAG? And if so, how?
Thanks for any help with this. Cheers,
06-27-2019 08:12 AM
After some debugging, I found out that, using exactly the same files (PMUFW, FSBL, BL31, U-BOOT), FSBL does not do the same things in SD boot mode as it does in JTAG boot mode. There must be a bug in FSBL, that prevents it from setting up the PMU in the right way.
Surprisingly, laoding the FSBL a second time, it first goes through the same steps as the first time, but then at hand off, runs the FSBL a second time! During the second run FSBL encounters errors and goes through the error stage, but when booting, eveything works FINE !!!!
There msut be an error in the FSBL !!!!
Is there anybody out there who could help?
07-02-2019 09:03 PM
Can you please give a try by disconnecting from xsdb before you boot the kernel. I mean exit from xsdb before executing boot command at u-boot.
If this didnt solve your issue, please share you jtag image loading sequence.
07-03-2019 12:32 AM
07-03-2019 01:13 AM
Just as an additional information: in the situation that I have described in my reply to your questions, where the ZCU102 hangs when brining up the secondary CPUs, when I then run the script again, I get the FSBL messages as in the attached console output file. The FSBL actually runs twice and finishes in the error stage, but when U-Boots boots the OS then, the secondary CPUs can be brought up OK and everything is running fine. To me, this is a clear sign that the whole problem is related to the FSBL. But how and what needs changing I have not the slightest clue ...
07-17-2019 05:31 AM
BTW, can you try using same version of images? I mean use all images from same Xilinx released version(2018.01 or 2019.01) because, from your log i can see that you are using FSBL from 2019.01 but u-boot/ATF/Linux from 2018.01.
07-18-2019 06:04 AM
Thank you very much for looking into this.
I have repeated the same procedure with ATF, UBOOT, and LINUX built with xilinx v2019.1. It does not change a dot. I append the console output. Please let me know what else to test. Can the FSBL made more verbose? Can we aactually see what the PMU FW does?
07-18-2019 01:12 PM
Could you try loading the bitstream after atf? There is an example tcl script in UG1137, Chapter 10 (page 158)
07-19-2019 04:42 AM
Thanks for your suggestion. I think I have found out how it works now. It is not the loading of the bitstring. Actually it doesn't matter if you load it first or last. But when you pointed me to UG1137, version 10 (!), p. 158, I realised that I still had the psu_ps_pl_isolation_removal, psu_ps_pl_reset_config statements in my TCL script. They were required with earlier versions of the FSBL. But I have the impression that with the newer version (I am running 2019.1) they are actually counter productive.
In short, it does work now: FSBL, PMUFW, U-BOOT, and ATF(BL31) from version 2019.1 and the TCL script from UG1137, version 10, p. 158 do work and I can boot the ZCU102 using JTAG.
Thank you all very much for your help. Cheers,