Jump to content

John J

Members
  • Posts

    53
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

John J's Achievements

Frequent Visitor

Frequent Visitor (3/4)

2

Reputation

  1. 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.
  2. 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?
  3. 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
  4. 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.
  5. @Ionut, 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.
  6. @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.
  7. 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.
  8. 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
  9. 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 = 0x020000000 R5#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_3 Thank you for your help.
  10. 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?
  11. Has anyone gotten any basic interrupt code to work using FreeRTOS on the Genesys ZU board?
  12. (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. https://github.com/Xilinx/embeddedsw/blob/master/ThirdParty/bsp/freertos10_xilinx/examples/freertos_intr_example.c
  13. 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.
×
×
  • Create New...