11-21-2018 07:09 AM
We have specific board using ZynqMP ultrascale XCZU4EV
When booting from QSPI24 mode, from time to time boot fails.
Following AR# 68656 FSBL doesn't print anything at this situation (I opened FSBL_DEBUG_DETAILED ) ,
So I focused on next step using jtag and boot_registers_log_revX_Y.tcl script.
Sometimes JTAG fails to connect to board in boot fail state ??? I attached two tcl outputs when jtag successfully connected.
I'm not sure how to parse tcl output response.
Attached two fails of tcl outputs, one boot OK tcl output, and FSBL boot OK output.
What can be the reason for such inconsistent behavior?
Regards
Baruch
11-26-2018 11:26 PM
We delayed the QSPI clk line, this seems to bypass the problem.
I can't use FSBL to debug, since it's not loaded, If there was away to change/debug the bootrom.
Thanks for help
11-25-2018 11:47 PM
CSU_BR_ERROR = FFD80528: 00009292
means Tamper event that is detected while in post boot
ERROR_STATUS_2 = FFD80540: 00001600
Mean PLL lock error.
Are the input ps_clk or power stable on your board?
if there is no FSBL load error from BootRom error codes and FSBL doesn't print anything with FSBL_DEBUG_DETAILED. Basically FSBL might hang in psu_init
11-26-2018 01:32 AM
Thanks for quick reply.
trying to debug this issue I found that:
from psu_init.c
if checking return value, than it takes much more time till IOPLL is locked than code does, only after three mask_poll() calling the IOPLL is locked, I don't think this is my problem but this is bad coding not to check mask_poll() return value. see below code from psu_init.c auto generated, wher mask_poll() return value is not verified.
it seems that my issues related to PMU bootrom fails to load FSBL from QSPI24, FSBL is not runing at all.
when scope probe or even the touch of my finger is places on QSPI_clk pin it always resolve this issue, if none than somtimes boot fails as mentioned.
I assume it related to timing issue, any more suggestions how to fix it? or how to debug bootrom code?
Regards
Baruch
11-26-2018 10:23 AM
You can change to QSPI device clock as described in AR69831 You can create an FSBL that has the debug symbols as described on the WIKI page
11-26-2018 11:26 PM
We delayed the QSPI clk line, this seems to bypass the problem.
I can't use FSBL to debug, since it's not loaded, If there was away to change/debug the bootrom.
Thanks for help
11-27-2018 05:58 AM
Sounds like you have some SI issues in your QSPI clock. The BootROM is not editable.
07-01-2020 03:56 PM
Hello, were you able to solve your problem?
Joe
07-01-2020 08:51 PM
As I wrote we added delay on line using capacitor.
Not sure about the values, done by our great HW engineer, this solved/bypassed the issue.
Not working there anymore.
@nimrod@xvtec.com
Regards.