VCU118 hangs at loading Linux from SD Card
Hi everyone, I tried to get this project worked on VCU118.
I tried to implement the workaround solution in https://github.com/PrincetonUniversity/openpiton/issues/65 but it still does not work. I also tried to modify the clock divider on sd card and modify the VADJ.
The system always get stuck at
sd initialized!
initializing SD...
sd initialized!
copying block 0 of 1 blocks (0 %)
Is there anything else that I need to check? Thank you very much.
Sorry, this issue is redundant.
This is the first week of our teaching quarter so I wasn't keeping up. Did you figure it out?
Yes, it seems like the connection is not stable all the time, we need to reset the CPU several times until it can read data from SD card.
That is frustrating. Unfortunately we don't have a vcu118 of our own. Ultimately I think Xilinx's decision to deprioritise low speed I/O on ultrascale+ seems to make this kind of issue inevitable. I do wonder whether further reducing the SD frequency might help?
I will try reducing SD frequency and let you you the result asap. By the way, currently I also want to try the solution booting without SD card mentioned in https://groups.google.com/g/openpiton/c/STQLcZMDOeI/m/wZUfb2z3AgAJ as a work around solution.
Hi @Jbalkind,
I tried to reduce the clock frequency for SD but the result still remains the same. I tried booting Linux by pitonstream and it works fine. However, in both cases (loading from SD card and by pitonstream), I could only get few information printed out the console and the program could never boot up successfully. I also tried the ariane image on the website as well as rebuilding one myself.
I wonder if you have any experience about this situation.
Thank you, Khoa. screen.txt
I would recommend against using UART for Linux boot. It's pretty likely that there could be a data corruption over the course of loading the whole bitstream. Perhaps you could try JTAG? There is a bscane2 config in the RTL that you could set up and try loading the kernel image using openocd and gdb. It's a lot faster and more reliable than UART.
Thank you @Jbalkind ,
I will try it this week and let you know the result.
Hi @Jbalkind ,
Now, I have been trying Openocd but the result is not optimistic. I checked the schematic and the Bscane2 module is already there. I want to confirm that whether it is necessary to connect our host machine to the FPGA board via GPIO pins or we can just use the micro-USB port labeled with JTAG.
Thank you.
I believe bscane2 is on the regular JTAG chain with the micro usb
I would recommend against using UART for Linux boot. It's pretty likely that there could be a data corruption over the course of loading the whole bitstream. Perhaps you could try JTAG? There is a bscane2 config in the RTL that you could set up and try loading the kernel image using openocd and gdb. It's a lot faster and more reliable than UART.
Hello!
I have a similar issue. I would prefer to use only the UART and pitonstream instead of GDB. How can I write the bbl.bin to RAM? If I use pitonstream then uart boot should be enabled. This chooses the baremetal bootROM. So should I change this to use the linux bootrom without copying from SD card? @khoatm98 How did you managed to pitonstream the linux image?
Thanks!
hi @jimaandro Yes I can use UART for linux boost but I could take a while (~10minutes). Just use your bbl (place it at openpiton/piton/verif/diag) as a prebuild image and run pitonstream script to download the image to FPGA board. For this, you would need to comment the line that is used to copy data from SD card to RAM in bootroom source and regenerate bitstream. However, it works but i don't recommend to do it this way. You can use openOCD to donwload the image instead.
hi @jimaandro Yes I can use UART for linux boost but I could take a while (~10minutes). Just use your bbl (place it at openpiton/piton/verif/diag) as a prebuild image and run pitonstream script to download the image to FPGA board. For this, you would need to comment the line that is used to copy data from SD card to RAM in bootroom source and regenerate bitstream. However, it works but i don't recommend to do it this way. You can use openOCD to donwload the image instead.
Thanks for the reply! I will try both ways to download the bbl. So if I use pitonstream, I understand that you used the Linux Bootrom without loading from SD. So did you set uart_boot_en to 0 (if it's 1 then baremetal bootrom is used) or did you just change the verilog code to always use the Linux Bootrom and keep the uart_boot_en =1 ?
Hi @jimaandro ,
Actually you should set uart_boot_en =1 because we load the linux image in the same way as we do with baremetal image. Ahh, for this, you don't need to change the verilog file as well. Sorry for misinforming you, I just remember from now.
Hello @khoatm98
Thanks!
If you are using OpenOCD, where do you copy the bbl.bin?
I suppose 0x80000000 is the correct address, but this doesn't work for me.
And after you copy the bbl to RAM, do you just continue or do you set $pc = something and then continue ?
Hello @khoatm98 Thanks! If you are using OpenOCD, where do you copy the bbl.bin? I suppose 0x80000000 is the correct address, but this doesn't work for me. And after you copy the bbl to RAM, do you just
continueor do youset $pc = somethingand thencontinue?
Hello @khoatm98 Actually I found what I need to do in GDB. My question now is did you used the BSCAN module in the project or did you connect the JTAG pins to FPGA pins in XDC file?
Hi @jimaandro , I'm not sure, but I think if you want to use openOCD, then you need to integrate Xilin BSCAN module. I did use it since my current project does not require.
I believe bscane2 is on the regular JTAG chain with the micro usb
Hello, I have managed to connect to Debug module with jtag using openOCD. I didn't used BSCANE2 module because this is already in the design. I am using VCU128. So I hust connected the jtag pins to uart0 like rocket-chip and for trst I used a VIO for manually reset. I can download the image without any issue, but when I examine the memory I see that some instructions where written in worng position. Is this a JTAG issue?
My guess is this could just be an endianness issue. Usually when we are using PCIe-based DMA, we also end up changing the endianness of the file before performing the DMA. Can you see exactly how the bytes are misarranged? Two common issues:
- byte-in-word endianness (can be changed with --reverse-bytes=8 in objcopy)
- word-in-cacheline endianness (can be changed with --reverse-bytes=64 in objcopy then potentially also the same as 1.)