John J
-
Posts
53 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Posts posted by John J
-
-
-
-
I have two 3EG boards and a 5EV board. They are both current revision boards and were bought in late 2021 and early 2023.
I am testing booting multi-core bare metal apps from QSPI on the 3EG boards. The FSBL fails on just one of the 3EG boards. It also boots on a 5EV board. All boards function properly via JTAG boot. The FSBL output of the 3EG boards is shown below.
This is failure output. (The bare metal project uses all 6 cores.)Xilinx Zynq MP First Stage Boot Loader Release 2022.1 Oct 30 2023 - 16:08:38 MultiBootOffset: 0x0 Reset Mode : System Reset Platform: Silicon (4.0), Running on A53-0 (64-bit) Processor, Device Name: XCZU3EG Digilent Genesys ZU board-specific init QSPI 32 bit Boot Mode FlashID=0x9D 0x60 0x19 XFsbl_SpkVer: XFSBL_ERROR_INVALID_EFUSE_SELECT Failure at boot header authentication Boot Device Initialization failed 0x74 Fsbl Error Status: 0x0 Xilinx Zynq MP First Stage Boot Loader Release 2022.1 Oct 30 2023 - 16:08:38 MultiBootOffset: 0x400 Reset Mode : System Reset Platform: Silicon (4.0), Running on A53-0 (64-bit) Processor, Device Name: XCZU3EG Digilent Genesys ZU board-specific init QSPI 32 bit Boot Mode FlashID=0x9D 0x60 0x19 XFSBL_ERROR_QSPI_LENGTH Device Copy Failed Boot Device Initialization failed 0x19 Fsbl Error Status: 0x0 Xilinx Zynq MP First Stage Boot Loader Release 2022.1 Oct 30 2023 - 16:08:38 MultiBootOffset: 0x800 Reset Mode : System Reset Platform: Silicon (4.0), Running on A53-0 (64-bit) Processor, Device Name: XCZU3EG Digilent Genesys ZU board-specific init QSPI 32 bit Boot Mode FlashID=0x9D 0x60 0x19 XFSBL_ERROR_QSPI_LENGTH Device Copy Failed Boot Device Initialization failed 0x19 Fsbl Error Status: 0x0 Xilinx Zynq MP First Stage Boot Loader Release 2022.1 Oct 30 2023 - 16:08:38 MultiBootOffset: 0xC00 Reset Mode : System Reset Platform: Silicon (4.0), Running on A53-0 (64-bit) Processor, Device Name: XCZU3EG Digilent Genesys ZU board-specific init QSPI 32 bit Boot Mode FlashID=0x9D 0x60 0x19 XFSBL_ERROR_QSPI_LENGTH Device Copy Failed Boot Device Initialization failed 0x19 Fsbl Error Status: 0x0 Xilinx Zynq MP First Stage Boot Loader Release 2022.1 Oct 30 2023 - 16:08:38 MultiBootOffset: 0x1000 Reset Mode : System Reset Platform: Silicon (4.0), Running on A53-0 (64-bit) Processor, Device Name: XCZU3EG Digilent Genesys ZU board-specific init QSPI 32 bit Boot Mode FlashID=0x9D 0x60 0x19 XFSBL_ERROR_QSPI_LENGTH Device Copy Failed Boot Device Initialization failed 0x19 Fsbl Error Status: 0x0 Xilinx Zynq MP First Stage Boot Loader Release 2022.1 Oct 30 2023 - 16:08:38 MultiBootOffset: 0x1400 Reset Mode : System Reset Platform: Silicon (4.0), Running on A53-0 (64-bit) Processor, Device Name: XCZU3EG Digilent Genesys ZU board-specific init QSPI 32 bit Boot Mode FlashID=0x9D 0x60 0x19 XFSBL_ERROR_QSPI_LENGTH Device Copy Failed Boot Device Initialization failed 0x19 Fsbl Error Status: 0x0 Xilinx Zynq MP First Stage Boot Loader Release 2022.1 Oct 30 2023 - 16:08:38 MultiBootOffset: 0x1800 Reset Mode : System Reset Platform: Silicon (4.0), Running on A53-0 (64-bit) Processor, Device Name: XCZU3EG Digilent Genesys ZU board-specific init QSPI 32 bit Boot Mode FlashID=0x9D 0x60 0x19 XFSBL_ERROR_QSPI_LENGTH Device Copy Failed Boot Device Initialization failed 0x19 Fsbl Error Status: 0x0 Xilinx Zynq MP First Stage Boot Loader Release 2022.1 Oct 30 2023 - 16:08:38 MultiBootOffset: 0x1C00 Reset Mode : System Reset Platform: Silicon (4.0), Running on A53-0 (64-bit) Processor, Device Name: XCZU3EG Digilent Genesys ZU board-specific init QSPI 32 bit Boot Mode FlashID=0x9D 0x60 0x19 XFSBL_ERROR_QSPI_LENGTH Device Copy Failed Boot Device Initialization failed 0x19 Fsbl Error Status: 0x0
This is the working output:
Xilinx Zynq MP First Stage Boot Loader Release 2022.1 Oct 31 2023 - 13:29:16 MultiBootOffset: 0x0 Reset Mode : System Reset Platform: Silicon (4.0), Running on A53-0 (64-bit) Processor, Device Name: XCZU3EG Digilent Genesys ZU board-specific init QSPI 32 bit Boot Mode FlashID=0x9D 0x60 0x19 Non authenticated Bitstream download to start now PL Configuration done successfully Initializing TCM ECC Initializing TCM ECC PMU-FW is not running, certain applications may not be supported. Protection configuration applied PL Configuration done successfully Exit from FSBL ... [App output not shown]
What is going on with the failing board?
-
Hi @thinkthinkthink.
- For flashing process only, you need to generate an FSBL ELF using the generic Xilinx code using any XSA that is valid for the Genesys-ZU and that has the QSPI enabled. You can just create an FSBL project using the template in Vitis and build it to generate an ELF that can be booted for flashing only. It probably fails DDR initialization on the Genesys-ZU, but that doesn't matter for the flashing process.
- This ELF should be specified as the "Init File" in the "Program Flash" dialog.
- You then just need to specify the proper Project and Image File and leave the rest at default.
- You should be able to flash any application code that currently can be run using the debugger in Vitis by specifying the projects BOOT.BIN file.
- The FSBL code in the project's BOOT.BIN should have the Digient FSBL source files and the psu_init.c/psu_init.h from your current XSA file.
I know this is brief, but I tried to provide the information that is specific to the procedure for the Genesys-ZU boards and not go into details about how to use Vitis.
JJJ
-
By the way: The the tag you mentioned above in the HelloWorld repo currently can't be cloned without a GitHub account, as the submodules are referenced by SSH URLs. This is not the first time this has been an issue in this repo.
-
Thank you for your response, and I do hope a solution is found to the issue you have described. I would like to know when that update is available.
It would also be helpful to know what this "wrong FSBL BSP optimization flag bug" that the demo instructions are referring to is. I wasn't easily able to find anything that sounds like what is being referred to in the demo instructions in either the Digilent or Xilinx forums.
Can you give me a pointer to the description of this "bug"?
Thank you.
-
@Luigee discovered that the QSPI flash can be programmed reliably using the default Xilinx FSBL from the Vitis templates, but fails with the Digilent provided Genesys-ZU FSBL.
I tried replacing the xfsbl_qspi.* files in the Digilent FSBL with the current Xilinx provided files, but programming still fails.
This does make me wonder what else in the Digilent provided FSBL may have issues. The Digilent FSBL is required to initialize the DDR properly.
The workaround is to generate an FSBL ELF file with the Xilinx provided files just for programming. This works, but it is another thing to keep track of.
-
I have done more research on this issue. Any help would be appreciated.
Info:
- Vitis versions used: 2020.1, 2022.1 and 2023.1
- Vitis is running under Ubuntu 18.04 and 22.04
- There is no difference in the failure modes between the Vitis/Ubuntu versions is used
- This has been tested in the Vitis GUI and with the program_flash command with the same results.
- Boards tested: Two Genesys-ZU 3EG boards and one Genesys-ZU 5EV board all are Rev D.
- Two boards fail with the error @Luigee listed above.
- The third board sometimes works, but less than half of the time. It has never failed with the error that occurs on the other boards. It usually fails with a single bit error on verify.
Please let us know if there is anything else that we ca try to make this work, as we have used the same flash design on our custom boards.
Thank you for your help.
-
Hi @Ionut
I have started with both the Genesys FSBL 2020.1 and 2022.1 from the following location.
https://github.com/Digilent/embeddedsw/tree/genesys-zu-22.1/lib/sw_apps/zynqmp_fsbl/src
The purpose of assigning 1/2 GB to each core is to give the cores unique RAM for the core's own code and data. I'm just letting the linker automatically allocate the space for each section, as is the case for the two memory blocks in the Digilent Hello World app, here. Since I am letting the linker allocate the memory within the 1/2 GB memory block, I shouldn't have any possibility of overwriting anything within the block. Right?
I was just looking for verification that my approach was valid.
Thank you for your help.
JJJ
-
We are currently developing a 6 core bare metal project on a Genesys ZU board. We get some odd results after modifying the linker script DDR configuration to accommodate all cores. (I'm ignoring OCM, ATCM and BTCM for this question.)
Is there any reason the idea of assigning a 1/2 GB of DDR to each core as below would cause issues?
psu_ddr_0_MEM_0 : ORIGIN = 0x000000000, LENGTH = 0x020000000 psu_ddr_0_MEM_1 : ORIGIN = 0x020000000, LENGTH = 0x020000000 psu_ddr_0_MEM_2 : ORIGIN = 0x040000000, LENGTH = 0x020000000 psu_ddr_0_MEM_3 : ORIGIN = 0x060000000, LENGTH = 0x01FF00000 psu_ddr_1_MEM_0 : ORIGIN = 0x800000000, LENGTH = 0x020000000 psu_ddr_1_MEM_1 : ORIGIN = 0x820000000, LENGTH = 0x020000000 psu_ddr_1_MEM_2 : ORIGIN = 0x840000000, LENGTH = 0x020000000 psu_ddr_1_MEM_3 : ORIGIN = 0x860000000, LENGTH = 0x020000000R5#0 app, psu_ddr_0_MEM_0 R5#1 app, psu_ddr_0_MEM_1 A53#0 app, psu_ddr_1_MEM_0 A53#1 app, psu_ddr_1_MEM_1 A53#2 app, psu_ddr_1_MEM_2 A53#3 app, psu_ddr_1_MEM_3Thank you for your help.
-
We have a multi-core bare metal project that works consistently after power has been applied to the Genesys ZU 3EG board. This applies to both running/debugging in Vitis 2022.1 and using an XSCT run script.
If we run the multi-core project again, without cycling the power on the Genesys ZU board, the application fails to receive consistent serial data on it's AXI UART Lite ports using interrupts.
After the FSBL has been run once, if we disable the use of the FSBL for any follow on runs, the application receives the correct data.
On the other hand, if we just run single cores, the individual applications work fine with the FSBL always enabled.
Why would a multi-core project fail due to running with the FSBL after a previous run, even with a system reset between runs?
-
-
(This question has been posted at Xilinx, but I'm posing it in this forum in case someone has run into the same issue here.)
The FreeRTOS example that Xilinx provides does not run on our Zynq UltraScale+. We have enabled the appropriate timers in Vivado, but the interrupt handler is never called in our applications running on a FreeRTOS domain. Are there any other configuration options that are required to make this work?
Does anyone have an example of using interrupts with FreeRTOS on an UltraScale+.
We would like to see a working example using a UART, but any device that we can easily generate an interrupt from would helpful.
Thank you for your help!
We were using the following example.
-
Thanks @elodg.
I will have to try this under 2022.1 and 2022.2, as I have not tried either yet.
I appreciate the update.
-
In both the 3EG and 5EV board presets, drive pullup and speed for data bit 4 of the SD card are configured differently than the other 7 bits. Is this correct?
I realize that all bits may not be treated identically on the interface, but thought I'd ask.
preset.xml: <user_parameter name="CONFIG.PSU_MIO_39_PULLUPDOWN" value="disable"/>
preset.xml: <user_parameter name="CONFIG.PSU_MIO_39_DRIVE_STRENGTH" value="4"/>
preset.xml: <user_parameter name="CONFIG.PSU_MIO_39_POLARITY" value="Default"/>
preset.xml: <user_parameter name="CONFIG.PSU_MIO_39_INPUT_TYPE" value="cmos"/>
preset.xml: <user_parameter name="CONFIG.PSU_MIO_39_SLEW" value="slow"/>
preset.xml: <user_parameter name="CONFIG.PSU_MIO_39_DIRECTION" value="inout"/>
preset.xml: <user_parameter name="CONFIG.PSU_MIO_40_PULLUPDOWN" value="pullup"/>
preset.xml: <user_parameter name="CONFIG.PSU_MIO_40_DRIVE_STRENGTH" value="12"/>
preset.xml: <user_parameter name="CONFIG.PSU_MIO_40_POLARITY" value="Default"/>
preset.xml: <user_parameter name="CONFIG.PSU_MIO_40_INPUT_TYPE" value="cmos"/>
preset.xml: <user_parameter name="CONFIG.PSU_MIO_40_SLEW" value="fast"/>
preset.xml: <user_parameter name="CONFIG.PSU_MIO_40_DIRECTION" value="inout"/>
-
Hi @elogd,
At that time, I was using the FSBL included in the 5EV Hello World Project that was current at the time. I was not able to determine if Vitis was using the correct FSBL or one of it's own.
I have not investigated this further and have switched to using 2022.1 and testing 2022.2 with the Digilent 5EV FSBL that was updated in August. It may no longer be an issue, as I think I was able to program using 2022.1. I'm not positive about that.
JJJ
-
Has anyone experienced this, or is this just me?
-
Under Ubuntu, if one user has previously accessed a Genesys-ZU board's JTAG interface, a second user is not able to access the port until the system is rebooted.
I have tried resetting the port multiple ways without success.
Is there any way to allow multiple users to utilize the same board with a Digilent FTDI JTAG interface under Linux without rebooting?
Thank you for your help.
-
Hi @elodg.
I'm currently on to other tasks, but will get back to this in a couple of weeks. I believe that I know what to do to make it work.
I'll let you know how it works when I get back to it.
Thank you.
John J
-
Hi @jcolvin,
Can you tell me if there is something significant that I'm missing in the process of using UART1?
Essentially, I just have been enabling UART1 as EMIO in my Vivado design, mapping the pins in my constraints, creating a Hello World Vitis project based on the Vivado design and substituting your main() code.
Is there anything else that should be done?
Thank you.
-
The code above still fails on my 3EG and 5EV boards.
Since my Vivado configuration for UART0 and UART1 only differ by the output pins (see below), and I'm using the working main() provided above, I wonder if I'm missing something in the Vitis project. I even looked through the *zynq _ultra_ps*.xci file to find any base configuration differences, but nothing looks different.
My process is to create the XSA and then create a Vitis Hello World workspace based on the XSA. Then I just replace the hello world C file with the main() source above.
Is there something that needs to be done to make UART1 work in the Vitis project outside of using the main() listed above?
Thank you for your help.
This is my UART configurations in the block diagram.
"PSU__CRL_APB__UART0_REF_CTRL__ACT_FREQMHZ": { "value": "100.000000" }, "PSU__CRL_APB__UART0_REF_CTRL__FREQMHZ": { "value": "100" }, "PSU__CRL_APB__UART0_REF_CTRL__SRCSEL": { "value": "IOPLL" }, "PSU__IRQ_P2F_UART0__INT": { "value": "0" }, "PSU__UART0__BAUD_RATE": { "value": "115200" }, "PSU__UART0__MODEM__ENABLE": { "value": "0" }, "PSU__UART0__PERIPHERAL__ENABLE": { "value": "1" }, "PSU__UART0__PERIPHERAL__IO": { "value": "MIO 18 .. 19" }, "UART0_BOARD_INTERFACE": { "value": "custom" }, LPD;UART0;FF000000;FF00FFFF;1 "PSU__CRL_APB__UART1_REF_CTRL__ACT_FREQMHZ": { "value": "100.000000" }, "PSU__CRL_APB__UART1_REF_CTRL__FREQMHZ": { "value": "100" }, "PSU__CRL_APB__UART1_REF_CTRL__SRCSEL": { "value": "IOPLL" }, "PSU__IRQ_P2F_UART1__INT": { "value": "0" }, "PSU__UART1__BAUD_RATE": { "value": "115200" }, "PSU__UART1__MODEM__ENABLE": { "value": "0" }, "PSU__UART1__PERIPHERAL__ENABLE": { "value": "1" }, "PSU__UART1__PERIPHERAL__IO": { "value": "EMIO" }, "UART1_BOARD_INTERFACE": { "value": "custom" }, LPD;UART1;FF010000;FF01FFFF;1 "PSU__UART0_LOOP_UART1__ENABLE": { "value": "0" }, -
Hi @elogd.
You are correct about me confusing the terms for PMU vs Platform MCU. It was my mistake. That never had an affect on my project. I just got confused about JColvin's comment.
I took a look at the clock configuration, and both UARTs look identical to me. Are there other options elsewhere in the Zynq configuration?
I am trying to set up the OOB project to see if there is something missing in the configuration, but I am having issues with the instructions appearing to not match the project. I will keep trying.
Thank you for your help.
-
Hi @JColvin.
That is what I thought about the headers, but the secret is the renaming of the AXI GPIO interfaces. Got it. Thanks.
My UART1 fails the test in your code, so I assume that I'm missing something in Vivado.
Xilinx Zynq MP First Stage Boot Loader Release 2020.1 Aug 29 2022 - 19:45:30 Reset Mode : System Reset Platform: Silicon (4.0), Running on A53-0 (64-bit) Processor, Device Name: XCZU3EG Digilent Genesys ZU board-specific init In JTAG Boot Mode PMU-FW is not running, certain applications may not be supported. Protection configuration applied PL Configuration done successfully Exit from FSBL Entered function main SelfTest Uart0: 0, a zero indicates no errors SelfTest Uart1: 1054, a zero indicates no errorsMy constraints are:
set_property -dict { PACKAGE_PIN AG14 IOSTANDARD LVCMOS33 } [get_ports { UART_1_0_txd }]; #
set_property -dict { PACKAGE_PIN AH14 IOSTANDARD LVCMOS33 PULLUP TRUE } [get_ports { UART_1_0_rxd }]; #My diagram is below.
What is missing?
Thank you for your help.
-
Hi @BogdanVanca
The FSBL code that I have been using was from 3eg/master. I did see that the 5ev/master code had been updated, but I didn't see much in the commit messages that stated what had actually changed. I'll have to look at the differences, when I get a chance. Please update the master/3eg branch.
I was not able to run the Digilent checkout.tcl script. The domain's BSP is missing the required FSBL libraries. I could have added them in, but I just used my script.
xsct% Specified template name Zynq MP FSBL is not valid for configuration. Reason: These libraries which FSBL requires are missing in Board Support Package: xilffs xilsecure xilpm. List of valid names are Dhrystone, Memory Tests, Peripheral Tests, Image Selector, Empty Application(C), Zynq MP DRAM tests, Hello World.My 5EV and 3EG boards both have the HX424A14IB/4 DDR4 modules.
The 5ev/master FSBL code appears to work for both the 5EV and 3EG boards using my script without the extra debug output.
Thank you for your help.
With two Genesys-ZU 3EG boards, one boots from QSPI the other fails in the FSBL
in FPGA
Posted · Edited by John J
I have tried using the same compiled binary file with the two 3EG boards and the same Vivado+computer to program all three boards. I have also tried a second computer, a different Vivado version and other HW/SW projects. In all cases there is just one board that does not run the executables correctly, but passed the verification test.
The QSPI x2 mode using an appropriately modified hardware configuration for the "Init File" made no difference.
I'm programming with the method that my colleague found in that same post you just mentioned. Without using that method, the flash won't even properly verify on any board.
I did not try the x2 mode with the Digilent FSBL, but so far all of my attempts point to an issue with one particular board.
We also have another 5EV at a different facility that my colleague was using to come up with the programming method listed in the other post, and it was working fine back then too.
Thank you for your response.