BootROM support in the Arty A7 FPGA Prototyping flow

[hadirkhan10]

Impact: rtl | software

Description

Adding a support to attach a BootROM would allow the users to run their programs without using the JTAG interface initially. Just like the Freedom project integrates the BootROM which jumps to the SPI Flash address. What is a motivating example for changing the behavior? This would help new users trying to run the chip on the FPGA to verify the working behavior of the RTL without jumping into the intricate details of the JTAG and an additional hardware to actually connect the debug hardware with the FPGA.

[jamesdunn]

Hello Hadir,

Thanks for bringing this up. I agree that having a BootROM is the most important next Arty feature, as it would allow untethered testing. I had originally planned to include support in the release, but ran into some issues creating QSPI binders for the flash module that held it up. I'm going to start working on that again and will link this issue to the PR when it's ready. Feel free to take a look at how you might implement flash module support as well—it would be a good exercise in how to extend these FPGA harnesses for new IOs.

Best, James

[hadirkhan10]

Thanks @jamesdunn for looking into this matter. Yes, I was looking at the flash implementation on freedom and was thinking of doing a mimic on the Chipyard, however, I didn't get the flow of how the flash is being programmed. Doing a make mcs and burning it on the fpga runs a default blinking program, however, I was unable to find from where that blinking program came? How was it compiled? How the SPI Flash of Arty was programmed? The boot ROM code just jumps to the SPI Flash base address which confirms that the program was stored in the flash. Could not get answer to these questions after looking the Makefile as well. Any help on that part would help me a lot.

[jamesdunn]

I have a draft of support for the QSPI flash chip in the branch arty-spi-flash.

To generate a memory image for the flash chip, you can run make SUB_PROJECT=arty mcs in the fpga directory. This generates generated-src/[long_name]/obj/[long_name].mcs, which can then be flashed from Vivado per the same instructions as page 7 of the SiFive Arty Getting Started Guide.

To upload a program to the flash memory, I use the freedom-e-sdk. For example, to upload an assembly test, I plug in the Olimex adapter and run: make PROGRAM=test-coreip TARGET=freedom-e310-arty CONFIGURATION=debug upload

The bootrom should jump to the program at the SPI flash base address when the core is reset, and you can then debug the program with OpenOCD and gdb.

Please give it a try and let me know how it goes. I'll leave this issue open until the branch gets upstreamed.

One catch is that I have encountered an unrelated bug with the UART interface between the core and the FTDI serial-to-USB adapter, where I get junk characters in a screen console when any program prints something. I am investigating this separately, but for now prints to the console do not work.

[alexdlukens]

I believe I have found an error in the UART HarnessBinder for the Arty. When comparing the implementation of the HarnessBinder to the ArtyShell.scala file located under fpga-shells/src/main/scala/shell/xilinx/ (connectUart function is at the very bottom of the file), I noticed that the IOBUF mapping was switched for the HarnessBinder. Upon changing the HarnessBinder to match the configuration in ArtyShell.scala, I was able to receive serial console output at baud rate = 57600. Are you able to replicate this behavior on your machine?

HarnessBinder implementation before changes

When running an example program from freedom-e-sdk, my arty board seems to get stuck in an "early trap vector" function, but running the command j _start in GDB made the program output as expected.

Thank you for your work on this branch.

[jamesdunn]

Thanks, Alex! That was indeed a mistake on my part—I got mixed up with the signal naming for the harness-level IOs.

I've made that fix in the most recent commit on the arty-spi-flash branch, and will include it in the PR to master.

That's great news that you were able to get console output. For some reason when I upload the hello program from freedom-e-sdk to flash and open a console with minicom -D /dev/ttyUSB1 -b 57600 -8, I get the question mark character for unrepresentable ascii. This may be an issue with my FTDI driver or some other system configuration.

I'll also take a look at the early trap vector behavior you describe.

Best, James

[JACKLIAO0]

I have download .mcs file to Arty Board and successfully run hello program, but when i upload a new program via freedom-e-sdk, it always have error like that:

Error: Debug Module did not become active. dmcontrol=0x0 Warn : target riscv.cpu examination failed Info : starting gdb server for riscv.cpu on 3333 Info : Listening on port 3333 for gdb connections Error: Target not examined yet

is there anyone have the same question with me ?

Hope for you reply,Thanks

[jerryz123]

We don't support interoperability with freedom-sdk.