This post was last edited by cruelfox on 2023-7-22 17:40
(Continued from the previous Zynq Learning Notes (1) Mining Board Small Test FPGA Development Process )
The development of the Zynq PS part involves cross-compiling the program running on the ARM Cortex-A9 CPU, that is, the program running on the Zynq. This part of the work is not done by Vivado, but requires another set of software tools: Xilinx SDK.
SDK development software also needs Zynq configuration information, that is, the PS clock, DDR, and peripherals set in the Vivado project. According to the tutorial, after the Vivado project is completed, use the Export function to export the hardware information to the SDK.
When exporting, you can choose to include the bit file, which is the configuration code stream of the FPGA part. The reason is that Zynq startup is dominated by the PS part, and the PS needs to be responsible for the initialization of the PL (FPGA), unlike a simple FPGA that can be automatically loaded as long as the bit is burned into the external flash. The exported file suffix is .hdf
The SDK's IDE is Eclipse-style and its operation is similar to that of common MCUs.
When creating a new project in the SDK, I have to select the target hardware platform, and I have to use my own board instead of the listed hardware, so I click the New button next to it.
Then you will need to use the hardware information exported from Vivado. Click Browse to select the .hdf file generated previously. The software will automatically give it a name (it may be long, you can modify it yourself).
Going back to the previous dialog box, you will see that the target hardware platform has become newly created.
First give the new software project a name (for example, I use demo0), the SDK will also create a BSP: demo0_bsp
Click Next to see some project templates for selection. As a novice, it is necessary to see how to write a project. You can choose the simplest Hello World. Here, select Memory Tests to test whether the DDR configuration works.
After confirmation, the SDK will automatically create and compile the project, and you can see the source files and other contents in the Project Explorer.
This looks a bit similar to the arm-none-eabi toolchain used to develop MCUs. The compilation result is also an elf file. Select the erf file, right-click the mouse to pop up a menu, and then select Debug or Run to run. Of course, it is also similar to the MCU development environment, provided that the debugger is connected. Here, the Xilinx downloader needs to be connected to the JTAG of the Zynq.
I have connected the mining board and confirmed that the FPGA can download the bit file, but I still encounter problems when selecting Debug or Run in the SDK:
This seems to be a debugger failure. The PS part of the mining board is already running Linux and may not be reset by JTAG.
As far as I know, there are several modes for Zynq booting. So preventing the Linux on the mining board from booting may be a solution to this problem. From the circuit diagram, the mining board uses NAND flash booting mode, so changing the pull-up of the PS MIO[4] pin to pull-down can switch to JTAG boot mode to prevent the board from booting by itself.
The boot mode on the mining board is not wired properly. There are both pull-up and pull-down resistors. You can directly solder the resistors without flying wires.
Remove the R2578 resistor in the red box in the photo and solder it to the R2585 position next to it. Then the mining board will not boot from NAND.
After changing the startup mode, select Run in SDK and successfully see the information printed out by the serial port:
The Memtest program provided as a template runs in the on-chip SRAM of the Zynq7010. This can be confirmed by the lscript.ld script:
To analyze how the program runs, you can try to disassemble the demo0.elf file. Use arm-xilinx-eabi-objdump –d in the SDK directory to disassemble it and you can see all the code parts.
For example, at address 0 is the interrupt vector table:
You can also find where the main function is:
The initialization part of the whole program still seems to have more code than the STM32 MCU. However, if you think about it, it can be used as an MCU board with a main frequency of 667MHz, 256MB DDR RAM, and you can also use Verilog to write peripherals to play with it, there are many areas for you to play with.