UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
701 Views
Registered: ‎12-20-2017

Custom ultrascale board: Multiple copies of the FSBL banner

Jump to solution

We are trying to get our recently-minted production board working.  The latest issue is that a simple "Hello World" boot image flashed on the QSPI shows the first characters of the FSBL banner message four times, with a nonsense character in between.  So, something like:

Xilinx Zynq MP First S.Xilinx Zynq MP First S.Xilinx Zynq MP First S.Xilinx Zynq MP First S.

(with a dot shown where the garbage ascii character would be)

When I run this same program over JTAG, it appears to work correctly, showing the full two-line FSBL banner.

Given that this partial message gets printed four times, I'm wondering if one of two things might be happening:

1) Is it being run once by each processor?  How could that be?

2) Is it being run with some kind of error handling or error condition that causes it to run again and again, up to four times.

We do not have the power-on-reset button circuitry wired correctly, btw.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Explorer
Explorer
433 Views
Registered: ‎12-20-2017

Re: Custom ultrascale board: Multiple copies of the FSBL banner

Jump to solution

@denist, yes, this is a hardware issue.  The FSBL debug symbol gave more info, and we could see that our program wasn't getting loaded into DRAM, so it was executing garbage at address 0, and that caused an exception, which invoked the FSBL's synchronous interrupt handler.  

Thank for your help.  I'll close this as resolved.

6 Replies
Xilinx Employee
Xilinx Employee
662 Views
Registered: ‎10-11-2011

Re: Custom ultrascale board: Multiple copies of the FSBL banner

Jump to solution

Be sure you have the DETAILED DEBUG enabled in your FSBL. I think you should see more than the banner there.

Most likely the WDT is kicking in because an FSBL step failed.

The DETAILED DEBUG will tell you more before resetting.

Explorer
Explorer
566 Views
Registered: ‎12-20-2017

Re: Custom ultrascale board: Multiple copies of the FSBL banner

Jump to solution

Thank you for your reply.

I enabled debugging in the FSBL, and got a slightly different telling of the story:

 

Xilinx Zynq MP First Stage Boot Loader
Release 2017.2   Feb  5 2019  -  19:16:24
Reset Mode      :       System Reset
Platform: Silicon (4.0), Cluster ID 0x80000000
Running on A53-0 (64-bit) Processor, Device Name: XCZU9EG
Processor Initialization Done
================= In Stage 2 ============
QSPI 32 bit Boot Mode
QSPI is in Dual Parallel connection
FlashID=0x20 0xBB 0x20
MICRON 512M Bits
Multiboot Reg : 0x0
QSPI Reading Src 0x44, Dest FFFDF948, Length 4
.QSPI Read Src 0x22, Dest FFFDF948, Length 4
QSPI Reading Src 0x98, Dest FFFDF944, Length 4
.QSPI Read Src 0x4C, Dest FFFDF944, Length 4
Image Header Table Offset 0x8C0
QSPI Reading Src 0x8C0, Dest FFFDB150, Length 40
.QSPI Read Src 0x460, Dest FFFDB150, Length 40
*****Image Header Table Details********
Boot Gen Ver: 0x1020000
No of Partitions: 0x2
Partition Header Address: 0x440
Partition Present Device: 0x0
QSPI Reading Src 0x1100, Dest FFFDB190, Length 40
.QSPI Read Src 0x880, Dest FFFDB190, Length 40
QSPI Reading Src 0x1140, Dest FFFDB1D0, Length 40
.QSPI Read Src 0x8A0, Dest FFFDB1D0, Length 40
Initialization Success
======= In Stage 3, Partition No:1 =======
UnEncrypted data Length: 0x2412
Data word offset: 0x2412
Total Data word length: 0x2412
Destination Load Address: 0x0
Execution Address: 0x0
Data word offset: 0x7B00
Partition Attributes: 0x116
QSPI Reading Src 0x1EC00, Dest 0, Length 9048
.QSPI Read Src 0xF600, Dest 0, Length 9048
Partition 1 Load Success
All Partitions Loaded
================= In Stage 4 ============
Protection configuration applied
Running Cpu Handoff address: 0x0, Exec State: 0
Exit from FSBL
XFSBL_ERROR_UNDEFINED_EXCEPTION
Fsbl Error Status: 0xXFSBL_ERROR_UNDEFINED_EXCEPTION
Fsbl Error Status: 0xXFSBL_ERROR_UNDEFINED_EXCEPTION
Fsbl Error Status: 0xXFSBL_ERROR_UNDEFINED_EXCEPTION
Fsbl Error Status: 0xXFSBL_ERROR_UNDEFINED_EXCEPTION
Fsbl Error Status: 0xXFSBL_ERROR_UNDEFINED_EXCEPTION
Fsbl Error Status: 0xXFSBL_ERROR_UNDEFINED_EXCEPTION
Fsbl Error Status: 0xXFSBL_ERROR_UNDEFINED_EXCEPTION
Fsbl Error Status: 0xXFSBL_ERROR_UNDEFINED_EXCEPTION
Fsbl Error Status: 0xXFSBL_ERROR_UNDEFINED_EXCEPTION
Fsbl Error Status: 0x

FSBL appears to run fine.  The problem is when we transfer to the application, it gets an error.  Then, when it tried to print the error in it's printf()-style statement, that causes another error, which happens recursively.

 

I've experimented enough to know that the printf()-style statement can handle character-only strings... it's the %x format code that crashes things.

Any ideas?

 

0 Kudos
Xilinx Employee
Xilinx Employee
504 Views
Registered: ‎10-11-2011

Re: Custom ultrascale board: Multiple copies of the FSBL banner

Jump to solution

Does it fail with a simple "hello world" ?

I really would like to see your .bif file and the linker script of your application.

0 Kudos
Explorer
Explorer
491 Views
Registered: ‎12-20-2017

Re: Custom ultrascale board: Multiple copies of the FSBL banner

Jump to solution


The problem appears only when we load the program into DDR.  We notice that the FSBL (or the Tcl script, depending on whether it's running in the SDK) tries to load the program at address 0, but when we read it, we see all zeros.

When I modify the hello world linker script to run in on-chip-memory, it works fine.

So now I think I might have a DDR problem.

 

 

0 Kudos
Xilinx Employee
Xilinx Employee
444 Views
Registered: ‎10-11-2011

Re: Custom ultrascale board: Multiple copies of the FSBL banner

Jump to solution

Was this a DDR issue at the end?

0 Kudos
Highlighted
Explorer
Explorer
434 Views
Registered: ‎12-20-2017

Re: Custom ultrascale board: Multiple copies of the FSBL banner

Jump to solution

@denist, yes, this is a hardware issue.  The FSBL debug symbol gave more info, and we could see that our program wasn't getting loaded into DRAM, so it was executing garbage at address 0, and that caused an exception, which invoked the FSBL's synchronous interrupt handler.  

Thank for your help.  I'll close this as resolved.