cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
mboechat
Visitor
Visitor
728 Views
Registered: ‎04-30-2019

ZU+ FSBL fails to access BRAM on "cold" start

I hope someone can help me figure out why the FSBL is successful only after the board has been running for a while.

I am developing on the UltrazedEG board and it's carrier (IOCC) -> http://zedboard.org/product/ultrazed-EG. It has a Zync Ultrascale+ XCZU3EG-SFVA625.

My goal is to test the DDR, so I can't use it as program memory.The program has to run from the SD card, so I can't use the OCM either, since it is reserved by the bootloader.

I have modified the out-of the box setup by adding a 256KB BRAM at address 0x8000_0000 in vivado 2018.3 (plus a few other irrelevant changes)

aj_blockDiagram.png

In Xilinx SDK 2018.3 I have created 4 projects,

  • The Hardware Platform Specification (importing the .HDF file from Vivado after generating Bitstream)
  • The Board Support Package
  • The FSBL based on the template
  • One Hello World program (to keep this question simple, will be replaced with DDR testing code)

For the FSBL project, I have modified the compiler Symbols according to https://www.xilinx.com/support/answers/69754.html

aj_compilerSymbols.png

And I have modified the bsp's page table (MMUTableL2) accordingly (fsbl_bsp>psu_cortexa53_0>libsrc>standalone_v6.8>src>translation_table.S)

 

.rept	0x0200			/* 0x8000_0000 - 0xBFFF_FFFF */
.8byte	SECT + Memory		/* 1GB lower PL  changed Device -> Memory */
.set	SECT, SECT+0x200000
.endr

 

I have also enabled more verbose debug messages from the FSBL in xfsbl_config.h

 

#define FSBL_DEBUG_DETAILED_VAL (1U)

 

I have modified the linker script for the Hello world program to generate two .elf files, one targeted to the DDR, one targeted to BRAM. I then use the bootgen GUI in the SDK (select Hello World project > Xilinx > Create Boot Image) to generate two .bin files that can be loaded on the SD card, for comparison.

When loading to the DDR, it works every time, when loading to the BRAM it has a weird behavior:

  • If the board has been off for more than ~2 minutes, it fails. A subsequent boot quickly after will fail too.
  • If the board has been on for more than ~30 seconds, it succeeds. Subsequent boots succeed too, until the board is left off for a while.

Deeper investigation shows me that the FSBL hangs at the very first access attempt to the BRAM done by f_read() function called by Xfsbl_SdCopy() in xfsbl_sd.c

I have tried many changes to the FSBL like adding a delay after the Bitstream is loaded (even a 40s delay!), adding extra check that the PL is ready, etc... but nothing I did changed the behavior described above.

I have attached a copy of the FSBL debug messages as well.

If you have any idea of what's going on, please tell me, I have exhausted ideas on my end.

0 Kudos
Reply
4 Replies
glena
Moderator
Moderator
701 Views
Registered: ‎03-19-2014

Have you seen AR69754

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Reply
mboechat
Visitor
Visitor
689 Views
Registered: ‎04-30-2019

Hi Glena,

Thanks for the pointer, I actually linked that document in my initial question, it's a very good reference, but unfortunately it did not solve my problem.

Further investigation seems to point to the following observation: BRAM access hangs if the bistream is loaded in the PL when chip temperature is < 35°C. Temerature of the chip does not seem to matter when loading the code to the BRAM, or at any other point in the process.

I feel compelled to tell you that I also posted my question on element14's forums (not sure if a link to that post violates the forum's policy?). They suggest that there is a loose ball on the init path. I have not yet confirmed this on a different assembly.

Is there any other path of investigation you can suggest?

0 Kudos
Reply
glena
Moderator
Moderator
677 Views
Registered: ‎03-19-2014

Maybe check in the FSBL to make sure the PL is done before trying to access the BRAM?  This would be in xfsbl_partition_load.c

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Reply
mboechat
Visitor
Visitor
579 Views
Registered: ‎04-30-2019

Seems that the issue is related to the board I have. I could not get my FAE to provide a second identical board to test if it is a manufacturing issue on the one I have, or a systemic problem with the UltraZed-EG SOM. All I can report is that our custom board has arrived, and even at -16C it runs code out of the BRAM without skipping a beat.

0 Kudos
Reply