Add support for Xilinx zcu102 board rev1.1

[Jerryy959]

This PR implements support for the Xilinx zcu102 FPGA version of the code on the latest main branch, with testing performed on the Xilinx zcu102 rev1.1 to boot BootRom (using Pmod SD card).
And this PR also implements FPGA-shell for zcu102: chipsalliance/rocket-chip-fpga-shells#29

Related PRs / Issues:

• rocket-chip-fpga-shells: Add support for Xilinx zcu102 board rev1.1 chipsalliance/rocket-chip-fpga-shells#29
• Origin from: Could you please help me check my prototype for zcu102? #2109

Type of change:

• Bug fix
• New feature
• Other enhancement

Impact:

• RTL change
• Software change (RISC-V software)
• Build system change
• Other

Contributor Checklist:

• Did you set main as the base branch?
• Is this PR's title suitable for inclusion in the changelog and have you added a changelog:<topic> label?
• Did you state the type-of-change/impact?
• Did you delete any extraneous prints/debugging code?
• Did you mark the PR with a changelog: label?
• (If applicable) Did you update the conda .conda-lock.yml file if you updated the conda requirements file?
• (If applicable) Did you add documentation for the feature?
• (If applicable) Did you add a test demonstrating the PR?

• (If applicable) Did you mark the PR as Please Backport?

CI Help:
Add the following labels to modify the CI for a set of features.
Generally, a label added only affect subsequent changes to the PR (i.e. new commits, force pushing, closing/reopening).
See ci:* for full list of labels:

• ci:fpga-deploy - Run FPGA-based E2E testing
• ci:local-fpga-buildbitstream-deploy - Build local FPGA bitstreams for platforms that are released
• ci:disable - Disable CI

[Jerryy959]

Current demo effect:
After writing the bitstream to board with vivado, I can see the last line of output in UART2 is "BOOT", this code locates at fpga/src/main/resources/zcu102/sdboot/sd.c:334 .

Then the board stopped and could not continue.

What might have happened?
If you have any idea, i would test it on my board immediately and return feedbacks here, thanks.
@jerryz123

[jerryz123]

Would you be willing to set up UART+TSI-based bringup instead-of/in-addition-to SDBOOT? We don't really use SDBOOT anymore because it is difficult to debug.

The nexysvideo and arty100t boards have UART+TSI based bringup.

UART-TSI loads the binary onto the prototype over a standard USB-UART cable, and maintains FESVR for the prototype as well.

[jerryz123]

@Jerryy959 can you describe what you are trying to do with these FPGA boards? Specifically:

a) Do you require SD-card based bringup? I'm inclined to remove this entirely.... its nearly impossible to test and debug, and adds significant complexity to the entire process.
b) Do you require the FMC pins? I notice these are mapped in your design.

[Jerryy959]

Thanks for reply! @jerryz123

To answer your question:

1. I don't necessarily need an SD card bringup, if there is another method to finish it. Another question is, if i don't use SD-card bringup, can it boot riscv-linux normally?
2. I can't tell if these FMC pins are necessary. I referred to the implementation of VCU118, and then corrected these pins based on the zcu102 manual.

[jerryz123]

I can try to modify your work into a simpler system that uses USB-UART-TSI-based bringup. This system is much more robust, but slower. It is the same mechanism used in the arty100t and nexysvideo boards.

One downside of this approach is that it takes up the USB-UART of the board. You'll need a second PMOD-USB-UART to expose the target's UART console output, such that you can interact with the target.

The other downside is that loading binaries over UART is slow. With Linux, it may take a few minutes.

[Jerryy959]

Thanks for your reply, this information is very useful to me. And i would like to cooperate to develop this function.
If the USB-UART-TSI-based bringup can be implemented normally, I would be very willing to accept and test it on my board.