Closed shirlynan closed 4 years ago
Which adapter are you using for the SD? My understanding is that the microSD slot on the board does not connect to the programmable logic.
As a result, SD doesn't have first-class support on vcu118. You have to connect an adapter to one of the PMODs and unfortunately the level shifters aren't very good so the SD specification can't be easily met. We found that the board couldn't routinely boot Linux without seeing errors, even when we reduced the SD clock significantly.
If you just need to run bare-metal benchmarks, you can make use of pitonstream
. When you build the bitfile with protosyn
you can add the additional argument --uart-dmw=ddr
and then you'll be able to stream the tests over UART to the board. This works quite well as an alternative.
Which adapter are you using for the SD? My understanding is that the microSD slot on the board does not connect to the programmable logic.
As a result, SD doesn't have first-class support on vcu118. You have to connect an adapter to one of the PMODs and unfortunately the level shifters aren't very good so the SD specification can't be easily met. We found that the board couldn't routinely boot Linux without seeing errors, even when we reduced the SD clock significantly.
If you just need to run bare-metal benchmarks, you can make use of
pitonstream
. When you build the bitfile withprotosyn
you can add the additional argument--uart-dmw=ddr
and then you'll be able to stream the tests over UART to the board. This works quite well as an alternative.
The level shifters issue is known to me. I used digilent PmodSD and also added pull-up resistors for it. However, the system still gets stuck at the same place. But it's great to know the system could ran in bare-metal mode. I would try this one first.
Thanks
Ah ok. We haven't tried it in a while (we only got access to a vcu118 at Princeton recently and still don't have the PmodSD) but the SD stuff may have been compounded with other issues that could have been better addressed since. In particular we improved some of the CDC code in the SD controller.
If it comes to it and you need Linux boot on that board, I believe Michael had more luck when he lowered the SD frequency to something like 8MHz. If that doesn't do it, we also have some in-development patches that would enable copying images from a host machine over PCIe (tested on XUPP3R so far). That would probably limit you to something like 2GB "storage" (fake disk located in memory) + 2GB RAM but would be sufficient for Linux/Debian boot, for example.
@Jbalkind
If we want to lower the frequency, where would be the best place to configure that? I've looked through the rtl but having a hard time nailing down the exact location. I'm having the same problem with the VCU118, even after fixing the PMOD SD adapter.
Edit: Just realized it's in the constraints.xdc
It's not just the constraints. You'll also need to run protosyn until the .xpr file is created and then use the Vivado GUI to reconfigure the clk_mmcm IP to change the sd_sys_clk frequency.
Ah alright, thank you for letting me know!
Please do let us know if you make more progress with this/what your modifications are if you get it working. We could change our config for vcu118 to support it!
Is BSCANE for the vcu118 working? I'm not having much luck with editing the MMCM IP, it won't let me go lower than a requested out frequency of 6 MHz (it says it's at 8MHz right now from no changes). If I can get it down to 400KHz, it should work albeit slowly. I had to do the same with the sifive/freedom vcu118 for it to work.
You mean the one at the top level for JTAG debug? I think it required some changes in openocd to make that work. There's another issue on this topic either here or on the google group I think.
The MMCM operates on ratios so you may be able to reduce other clocks accordingly or set up another mmcm and have it output a slower clock? Actually, if all you want is 400KHz then that's slow enough that you could probably just use a counter to divide down something faster. Like ask for 25.6MHz and increment a 7 bit counter, using the top bit of the counter as the clock.
@Jbalkind Yeah, I saw the other topic but I was also having the same issues with openocd. It detects the processor but hits a DTM version error.
I went back to the SD clocks though.
In the vcu118 contraints, it has the fast clock and slow clock generation and I believe it uses the same method you mentioned. The fast takes the 8MHz sd_sys_clk from the mmcm and divides it by 2 to provide the 4MHz clock that I see over a logic analyzer hooked up to the PMOD adapter. The slow takes the 8MHz sd_sys_clk and divides by 200 to give the 40KHz slow clock that I can verify.
I figured that I could change those values to get the 1MHz fast clock, and 400KHz slow clock that I need, but even after changing them to multiple different values, I see same speeds he logic analyzer: 4MHz and 40KHz. Even doing a report_clocks, the correct periods and waveforms are reported for fast and slow with my changes.
They show as changed in the contraints file for the project when I open it in Vivado, but any idea why they would still stay at the same speeds? I believe the slow clock is supposed to be between 100-400KHz, and that 40KHz might be the reason the SD card boot has issues.
Thanks again for all your help by the way.
Hi @jctullos , constraint files are only used during timing analysis and won't change how the clock is actually generated. SD clocks are generated in sd_clock_divider.v. You'll need to change the divisor there to change the clock frequency.
@leon575777642 Ahhh, that explains it. Thank you for the clarification! I'll see if the frequency changes help.
@leon575777642 @Jbalkind
So I was finally able to get the SD card boot working. I kept everything timing wise unchanged. There was a post on Xilinx forums that said to set the VADJ through the System Controller UI program to 1.2V. After changing that, and enabling the SCUI on SW16, I'm able to reliably boot from the SD card.
Thank you to both of you for the help.
Oh that is awesome! If you get a chance, would you mind making a PR adding a note about this (and the other physical changes to the SD adapter) to the readme for vcu118? Did the RTL and design stay the same otherwise, or did you have to make some changes?
Hi everyone,
I tried to get this project to work on VCU118. I used digilent PmodSD, but I have the same problem that I am trying to solve it for a long time: could not initialize sd.
Hello World!
init SPI
status: 0x0000000000000025
status: 0x0000000000000025
SPI initialized!
initializing SD...
cmd0 Failed
could not initialize sd... exiting
I tried the solution proposed by @Jbalkind which consists of lowering the frequency and it does not work for me.
I also tried the solution suggested by @jctullos but it also does not work for me. The solution is to adjust the VADJ to 1.2V through SCUI controller (xilinx script), then I try different positions of SW16 in order to try the different configuration mode:
Could you orient me please?
Did you also change the clock divider as mentioned by Ang in order to lower the frequency? Did you change the resistors on the PMOD SD as directed in the readme? As the PMOD0 port has open-drain level-shifters, you also have to replace the R1-R4 and R7-8 resistors with 470 Ohm 0201 SMD resistors on the Digilent PMOD SD adapter to make sure that signal rise times are short enough.
The problems with SD on VCU118 are mainly electrical. With the combination of the changes mentioned here we know several people have managed to get it working. It's not a very satisfying solution but that's really due to Xilinx's setup with this board.
Actually, "could not initialize sd" sounds really weird - we don't use SPI for SD. Are you using ariane-sdk main branch instead of the openpiton branch?
Hello @Jbalkind I have the same problem on Genesys2 I created the SD partitions correctly, copied the pre-compiled image into it and plug it in FPGA board. Then I programmed the FPGA using Vivado and UART got stuck on this
----------------------------------------
-- OpenPiton+Ariane Platform --
----------------------------------------
OpenPiton Version: b'3cc7bf4d'
Ariane Version: b'cbbcf356'
FPGA Board: genesys2
Build Date: Feb 22 2024 15:02:41
#X-Tiles: 1
#Y-Tiles: 1
#Cores: 1
Core Freq: 66 MHz
Network: 2dmesh_config
DRAM Size: 1024 MB
L1I Size / Assoc: 16 kB / 4
L1D Size / Assoc: 8 kB / 4
L15 Size / Assoc: 8 kB / 4
L2 Size / Assoc: 64 kB / 4
----------------------------------------
sd initialized!
initializing SD...
sd initialized!
copying block 0 of 1 blocks (0 %)
On g2 we don't usually have this problem. Could you try some different SDs? Sometimes there are cards that aren't compatible with our SD IP for some unknown reason.
On g2 we don't usually have this problem. Could you try some different SDs? Sometimes there are cards that aren't compatible with our SD IP for some unknown reason.
Hi Thanks for replying. Well I think you are right. I didn't change anything, I just reset the board many times and suddenly it worked. The problem now is that even if it completes booting, it stucks on login. It shows:
Welcome to Buildroot
buildroot login:
But I can't type anything and even if I type root
and hit enter, it doesn't login
Which application are you using for your serial terminal? Is there any chance you have it open twice? Sometimes there's weird behaviour if so. Another thing can be local key echoing may be disabled so it can be doing stuff but you don't see, though if you're hitting enter and seeing nothing that shouldn't be the case.
Also I'd suggest you try the openpiton-opensbi branch of my ariane-sdk fork to generate a fw_payload.bin. I may have removed the need to login there but I can't quite remember for sure. Either way it'll likely be newer than what you're trying.
I am using the minocom to communicate. I found that the problem was minocom settings. I disabled Hardware Flow Control
and this fixed the issue
Thank you very much!
Hi @Jbalkind , I have one concern. Can we just modify the booting script piton/design/chipset/rv64_platform/bootrom/linux/src/main.c to change it to uart for loading the linux image?
I'm not quite sure what you mean and I'm not sure why you're posting on this closed issue to ask?
Hi everyone, I tried to get this project worked on VCU118. My sd card: SanDisk microSD 16GB. But I always get the following warning when I prepared the SD card with command: sudo sgdisk --clear --new=1:2048:67583 --new=2 --typecode=1:3000 --typecode=2:8300 /dev/sdb
Found invalid GPT and valid MBR; converting MBR to GPT format in memory.
Warning! Secondary partition table overlaps the last partition by 33 blocks! You will need to delete this partition or resize it in another utility. Non-GPT disk; not saving changes. Use -g to override.
And system get stuck at sd initialized! initializing SD... sd initialized! copying block 0 of 1 blocks (0 %)
Is anything wrong with this SD card? Should I change it? But to which one? Could you please give me some advice? Must I use SD boot if I just want to run some benchmarks on my board? Is there any other choices?
Thanks