07-25-2019 02:32 PM - edited 07-25-2019 02:34 PM
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)
In Xilinx SDK 2018.3 I have created 4 projects,
For the FSBL project, I have modified the compiler Symbols according to https://www.xilinx.com/support/answers/69754.html
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:
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.
07-29-2019 06:38 AM
Have you seen AR69754?
07-29-2019 10:06 AM
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?
07-29-2019 12:10 PM
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
08-28-2019 01:46 PM - edited 08-28-2019 01:48 PM
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.