cnrv / fpga-rocket-chip

Wrapper for Rocket-Chip on FPGAs
Other
120 stars 26 forks source link

How to run this project on Nexys A7 #24

Closed Stalker144 closed 1 week ago

Stalker144 commented 1 year ago

Since I cannot get a Nexy4DDR board, I tried to implement this project on the Nexys A7 board. I checked the constrain file of these two boards,and they are almost same. But when I implement this project on the Nesys A7, the output is like below: ����������������j�L =�������������Ԥ�� "Js:$z{�sV�6H�nto �*kz��r��X

I checked the linux core, it can run on the spike with its dts.

What do you think lead to this output?

NeutrinoLiu commented 1 year ago

Serial connection garbled characters, usually caused by wrong wire connection or wrong baud rate.

Stalker144 commented 1 year ago

Thanks for your reply. I have checked the wire, it is brand new and works good. The baud rate is also using the 115200 as requested in this project. Since there is a comment on the makefile of the repo says this project is using a wrong baud rate, what should I do to correct it?

NeutrinoLiu commented 1 year ago

Thanks for your reply. I have checked the wire, it is brand new and works good. The baud rate is also using the 115200 as requested in this project. Since there is a comment on the makefile of the repo says this project is using a wrong baud rate, what should I do to correct it?

i am not sure whether it is caused by baud rate configuration. basically during bootloader stage, serial baud rate is configured here Sorry I have been detached from this project for a while, so there are little i could help with, especially on a not-tested platform.

I would suggest you post the full record of your console output since the power on of your device and any modification you have made to the original project, so that others might help with the issue.

wsong83 commented 1 year ago

Nexys A7 (the 100T variant) should be identical to Nexys4DDR, at least according to Digilent. However, we do not have one at hand and can not verify. I agree with NeutrinoLiu that this looks like a baud rate mismatch. With all the information available, I am afraid it would be difficult for us to directly tell what goes wrong, as it should work out of the box.

Basically, the baud rate on host pc side should be 115200 (8-bit data, 1-bit odd parity). The odd parity here can cause havic as well. I would suggest you to try different combinations of different baud rates and parity combinations to see whether you can bump with a correct configuration. At least it would be easy to try on your pc side.

If this goes out of luck, then you need to debug with the FPGA. You need to verify that the clock for UART is indeed 50MHz. (Basically, this would then require you to be able to skillfully play around with Vivado.)

Stalker144 commented 1 year ago

Thank you for your advices. I have discovered that the baud rate of 15200, along with the 8n1 configuration, is correct. The previous issue was caused by resetting the CPU. However, the rocket-chip is currently running very slowly and becomes unresponsive when attempting to output the running details. It takes approximately 5 minutes for any output to be generated after the FPGA has finished loading, and then it gets stuck at that point for the next 5 minutes. Subsequently, no further output is produced for the following hour. The whole output likes this:

20230214) #6 SMP Wed Jul 5 17:15:28 EDT 2023 [ 0.000000] Maes [ 0.000000] node 0: [mem 0x0000000080000000-0x0000000 v0.1 [ 0.000000] remote fence extension is not available in:off, heap free:off [ 0.000000] Memory: 114672K/1

Is the slow boot normal? And what do you think about this imcomplete output?

wsong83 commented 1 year ago

A normal boot should take less than a couple of minutes. So it does not look right. Have you strictly follow the instructions for compiling the kernel? Before trying any new ones, you need to try the exact kernel version compiled by the exact cross-compiler version. A new kenerl compiled by a new compiler may not run on an rather old Rocket.

Stalker144 commented 1 year ago

Thanks for your reply. Yes, you are right. When I roll backe the version of the toolchain and linux kernel, it works. And the whole project can be transfered to the Nexys A7 without any modification. If the project is built by the lastest toolchain version(23.07.09), the ISA should extend zicsr and zifencei because some instrcutions are moved out of rv32/64i into these two extensions. Finally, When I input command via the console, the input characters sometimes missed. And the system also stucked for several seconds sometimes. Is this common?

wsong83 commented 1 year ago

No, this is uncommon. It still smell like something unstable with the UART connection, although I have no clue about any potential cause.

Stalker144 commented 1 year ago

I regenerated the whole project again with given version of the tools. It works well. The busybox is booted in 2 mins and I can run some riscv program on the board. However, the board sometimes blocked the keyboard input of the serial. To input data to the board, the serial software should close the Flow Control.

wsong83 commented 1 year ago

This is probably because the UART is still polled by the driver. If it is replaced with a interrupt-based driver, the response time shoudl be improved. However, I am afraid we do not have the time and man power to do the change any more.

Stalker144 commented 11 months ago

I bypassed the block problem by using putty to receive the io. I alos found another problem, the Rocket-chip used in this repository doesn't support ROCC.

wsong83 commented 10 months ago

The RoCC interface is pretty old and become absolete. I believe it has been removed form the Rocket-Chip (the upstream repo) for quite some time. We have not touched this part.