STLV-7325 Rocket sdcardboot issue

[troibe]

When trying to boot Rocketchip from the sdcard on the stlv-7325 board I get stuck on lift-off. Using Vexriscv and the stlv-7325 board I can get sdcardboot to work at 100Mhz (with l2 disabled). Using Rocketchip and the Arty A7 I can get sdcardboot to work at 50Mhz.

I tried both frequencies with the stlv-7325 and timing are met for both. This is the command that I'm using:

../litex/litex-boards/litex_boards/targets/aliexpress_stlv7325.py --build --cpu-type rocket --cpu-variant linux2d --sys-clk-freq 100e6 --with-sdcard --with-ethernet --csr-csv=csr.csv --output-dir build/aliexpress_stlv7325-100

I'm a bit confused since I can't reproduce this on any other setup. Any debugging advice would be greatly appreciated.

[enjoy-digital]

Hello @developandplay,

have you tried VexRiscv + STLV-7325 at 50MHz? Can you also check if --with-spi-sdcard is working? Otherwise, it could be interested to try to revert this: https://github.com/enjoy-digital/litesdcard/commit/809ade33137edd6db59912844b4a7ccfbe2e4e0c.

[troibe]

Seems like email response didn't work.

--with-spi-sdcard was not working either for Rocket at 50Mhz/100Mhz on the stlv-7325. I forgot to add: Using Rocket + STLV-7325 + serialboot works as expected. VexRiscv + STLV-7325 + sdcardboot is working at 50Mhz, 100Mhz, 150Mhz and 175Mhz (all with memory callibration and without l2).

Is there anything that could be specific to Rocket+STLV-7325+sdcard? Maybe something that is (not) present on the Arty board or something that vexriscv is (not) using? I will try the reverted commit next. Thanks for the advice.

[enjoy-digital]

I don't see obvious reasons it would work on Arty at 50MHz and not on the SLV7325. If you want to have a configuration as close a possible to the Arty, you could eventually try to reduce the DDR3 to only 16-bit with the PHYPadsReducer: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/xilinx_ac701.py#L71

Use PHYPadsReducer(platform.request("ddram"), [0, 1]) for 16-bit.

[troibe]

I tried reverting https://github.com/enjoy-digital/litesdcard/commit/809ade33137edd6db59912844b4a7ccfbe2e4e0c which didn't seem to make any difference.

I'll try reducing DDR3 to 16-bit width next.

I just hope it's not some stupid Vivado bug like the one for my Bachelor thesis that took a month to debug.

(It was about Vivado handling sign extension improperly but only in the toolchain for the Artix series and not in the toolchain for the Kintex series.)

[troibe]

Reducing to 16bit width didn't make any difference. I also tried the Rocket linux, linuxd and linuxq configurations without success.

@enjoy-digital I dumped the memory content and besides the last 14 lines the binary content is quite scrambled up. Lots of lines are jut set to 0xff or shifted. Any ideas on what might be causing this? Gist: https://gist.github.com/developandplay/2626a3f17641f1bdd42bdee37b65f1b5 Naxriscv 64bit is also slightly scrambled up but a lot less than Rocket. It also boots successfully from the sdcard.

[troibe]

Maybe the output that I'm getting from enabling software_debug is a bit more useful:

...
cmdevt: 00000000
cmdevt: 00000000
cmdevt: 00000000
cmdevt: 00000005
203f40ff 80003700 0001203f c0ff8000
CMD2: ALL_SEND_CID
cmdevt: 00000000
cmdevt: 00000001
03534453 4e363447 8055c695 5a014cff
CID Register: 0x035344534e3634478055c6955a014cff
Manufacturer ID: 0x353
Application ID 0x4453
Product name: N64G�
CRC: ff
Production date(m/yy): 12/20
PSN: 55c6955a
OID: SD
CMD3: SET_RELATIVE_ADDRESS 
cmdevt: 00000000
cmdevt: 00000001
36344780 55c6955a 014cff03 aaaa4520
CMD10: SEND_CID
cmdevt: 00000000
cmdevt: 00000001
03534453 4e363447 8055c695 5a014cff
CMD9: SEND_CSD
cmdevt: 00000000
cmdevt: 00000001
400e0032 db790001 dbd37f80 0a4040f9
CSD Register: 0x400e0032db790001dbd37f800a4040f9
Max data transfer rate: 64 MB/s
Max read block length: 512 bytes
Device size: 59 GB
CMD7: SELECT_CARD
cmdevt: 00000000
cmdevt: 00000001
790001db d37f800a 4040f907 00000700
CMD55: APP_CMD
cmdevt: 00000000
cmdevt: 00000001
7f800a40 40f90700 00070037 00000920
ACMD6: SET_BUS_WIDTH
cmdevt: 00000000
cmdevt: 00000001
f9070000 07003700 00092006 00000920
CMD6: SWITCH_FUNC
cmdevt: 00000000
cmdevt: 00000000
cmdevt: 00000001
00370000 09200600 00092006 00000900
dataevt: 00000001
CMD55: APP_CMD
cmdevt: 00000000
cmdevt: 00000001
20060000 09200600 00090037 00000920
CMD51: APP_SEND_SCR
cmdevt: 00000000
cmdevt: 00000001
20060000 09003700 00092033 00000920
dataevt: 00000001
CMD16: SET_BLOCKLEN
cmdevt: 00000000
cmdevt: 00000001
00370000 09203300 00092010 00000900
CMD17: READ_SINGLE_BLOCK
cmdevt: 00000000
cmdevt: 00000001
20330000 09201000 00090011 00000900
dataevt: 00000001
CMD17: READ_SINGLE_BLOCK
cmdevt: 00000000
cmdevt: 00000001
20100000 09001100 00090011 00000900
dataevt: 00000001
CMD17: READ_SINGLE_BLOCK
cmdevt: 00000000
cmdevt: 00000001
00110000 09001100 00090011 00000900
dataevt: 0000CMD17: READ_SING
cmdevt: 00000000
cmdevt: 00000001
00110000 0����������������D

[troibe]

Added some more debug information. Seems like the system crashes once it's trying to read the content of the boot.json file.

CMD17: READ_SINGLE_BLOCK 000000000000
cmdevt: 00000000
cmdevt: 00000001
20330000 09201000 00090011 00000900
dataevt: 00000001
CMD17: READ_SINGLE_BLOCK 0x0000000800
cmdevt: 00000000
cmdevt: 00000001
20100000 09001100 00090011 00000900
dataevt: 00000001
Successfully mounted sdcard.
CMD17: READ_SINGLE_BLOCK 0x00000009f8
cmdevt: 00000000
cmdevt: 00000001
00110000 09001100 00090011 00000900
dataevt: 00000001
boot.json file found.
CMD17: READ_SINGLEx0000011b70
cmd0h2�08
CMD17: �cmdevt: 00000000

If we manually read out the content at 0x0000011b70 by using the BIOS commands we get the content of the boot.json file without any issues.