News:

Attention: For security reasons,please choose a user name *different* from your login name.
Also make sure to choose a secure password and change it regularly.

Main Menu

2019.2

Started by bentho, June 14, 2020, 11:41:52 AM

Previous topic - Next topic

bentho

Hello,

I started to have a look at your latest distribution for Vivado/Vitis 2019.2 together with the ZynqBerry TE0726-3M.
As I understood from some previously posted questions and from the Wiki documentation,
--> https://wiki.trenz-electronic.de/display/PD/TE0726+Zynqberry+Demo1#TE0726ZynqberryDemo1-DesignFlow
, there should be a zynqmp_fsbl_flash.elf available among the binaries. This one is supposed to solve some issues with the QSPI clocking as I understood.
The zynqmp_fsbl_flash.elf just isn't there in the 2019.2 bundle of files. In the library _binaries_TE0726-03M/res_elf I can find fsbl_flash.elf.

Does fsbl_flash.elf. have the same functionality as zynqmp_fsbl_flash.elf ?

I tried programming my ZynqBerry using the GUI in Vivado 2019.2 but I still get this programming failure,

[Xicom 50-100] The current boot mode is QSPI.
If flash programming fails, configure device for JTAG boot mode and try again.

Which fsbl version am I supposed to use for QSPI flash programming?

I was previously working with 2017.1 and didn't have to specify the fsbl at flash programming.

Regards
Benny

bentho

Hello,

I will be more specific in my description of the problem. I am running Vivado/Vitis 2019.2 under Ubuntu 18.04.4. LTS
My previous question is about using the Vivado GUI for programming the onboard 128 Mbit QSPI flash memory.
I have downloaded 2019.2 version of zynqberrydemo1 and I run the _create_linux_setup.sh shell script to create the project.
The ZynqBerry board I am using is the TE0726-03M

I use the the following binary image file, _binaries_TE0726-03M/boot_linux/BOOT.bin
I use the following FSBL for programming the flah memory, _binaries_TE0726-03M/res_elf/fsbl_flash.elf

When I open the programming GUI in Vivado I need to give reference to both those files.

The error message I get is,

[Xicom 50-100] The current boot mode is QSPI.
If flash programming fails, configure device for JTAG boot mode and try again.

From what I understood Trenz has provided a workaround for this problem, should be solved by the FSBL?
Am I using the correct version of FSBL?

Just to be more sure, I tried to perform the same programming operation from a Windows 10 installation of Vivado 2019.2 and I get the same error.

It would be great if anyone here could give me a hint on what I am doimg wrong?

Regards
Benny

bentho

I was able to program the same ZynqBerry board, using the same usb-cable but on another Ubuntu laptop using Vivado 2017.1 (without specifying FSBL) using the BOOT.BIN file from 2019.2 bundle of project files.  (The RPI-cam came on nicely after booting)
After programming the Berry on 2017.1 then all of a sudden I was able to program the QSPI flash memory also on the 2019.2.
This behavior was the same for two of those Berry boards I've previously used.
I opened a brand new package with the ZynqBerry and that one I could program under 2019.2 directly without problem.

I have now clue what is going on here :)
Maybe some of you have experienced something similar?

Regards
Benny

JH

Hi,

Quotezynqmp_fsbl_flash.elf
was a copy past mistake.


Quote
I have now clue what is going on here :)
Maybe some of you have experienced something similar?

Programming with 19.2 depends on QSPI Flash content now:
https://wiki.trenz-electronic.de/display/PD/TE0726+Zynqberry+Demo1#TE0726ZynqberryDemo1-ReleaseNotesandKnowIssues
In case there is a bootable file in the QSPI flash you must use normal fsbl, in case qspi flash is empty, you must use special FSBL for QSPI programming.

       
  • up to Vivado 2017.2 no additional FSBL was need
  • with Vivado 2017.3 up to Vivado 2018.2, special FSBL was need
  • with Vivado 2019.x(I didn't test 19.1), it depends on QSPI content
  • I didn't test 20.1 maybe Xilinx has fixed it maybe not...

br

John


bentho

Thank you John!

Then it makes sence. I was trying to browse lots of documentation but I missed those lines.
Anyway, Xilinx should provide a nicer solution for GUI programming in future.
I can't even understand why it's called FSBL since it is only handling some basic configuration of the PS to be able to program the QSPI.

FSBL for loading bitfiles and second boot loader is a different ball game in my thinking.

Regards
Benny

JH

Hi,
FSBL configures whole PS normally.

For QSPI programming Xillinx need QSPI interface and bank voltages setup. On older vivado (17.2 and older), Xilinx has provide such a configuration for all parts, only in case you use 2 QSPI, you must use own FSBL. I think they changed it to get it more uniform, but they didn't thinking about the problems customer has, in case boot mode is not JTAG (which was not need until 17.2). With the special FSBL, we could this fix this issue easily. But the new problem where it depends on content(since 19.x), is really a bug of Vivado(I didn't find any way to fix it at the moment, because it doesn't depend on FSBL itself and only 7 Series seems to be influenced).

I hope Xilinx will get a grip on JTAG again, but unfortunately I am not so sure... :-(

br
John