13:18 <somlo> _florent_: with the latest everything, I can boot from spi-sdcard; With "regular" litesdcard, I'm getting the progress bar to complete (slowly), then things hang after "Liftoff!"

13:18 <somlo> so I'm wondering if the boot.bin blob gets somehow corrupted in transit

13:28 <_florent_> somlo: i also need to do more tests with litesdcard, that's indeed probably broken currently

13:30 <_florent_> somlo: but i haven't speed too much time on it since i'm also thinking about revisiting litesdcard a bit to simplify it, make it more software assisted and only do the critical things (blocks transfers) in the gateware

13:48 <somlo> ok, I won't worry too much about litesdcard for now, then :)

13:53 <_florent_> somlo: the current issue with LiteSDCard is that the clocking is complicated and it use a lot of resource (due to the way the control interface is done)

13:57 <_florent_> somlo: initially LiteSDCard was used in standalone to write/read streams of blocks, so decided of the current architecture

13:58 <_florent_> somlo: but while working on the SPI mode recently, i realized we should probably simplify LiteSDCard to use less resource and have more in common with the SPI mode

13:58 <_florent_> somlo: but we'll see...

13:59 <_florent_> somlo: have you been able to do some speedtests with the SPI SDCard with Linux?

14:12 <somlo> _florent_: I did some very informal measurement of how long it took to transfer a file to/from the card from within linux

14:13 <somlo> I don't remember if I wrote it down at the time, should be simple to recreate

14:29 <_florent_> somlo: i'm asking this just to be able to compare with the speed with the bios

14:32 <somlo> _florent_: I'm rebuilding a bitstream for the nexys4ddr with spi-mode sdcard support (already have a kernel and bbl that's good for it). I'll re-run the tests and post here in 20-30 minutes

14:32 <_florent_> somlo: if that's low compare to the speed with the bios (> 1MB/s on reads) we could try to see how block accesses are done with the driver and see if we can optimize it.

14:53 <somlo> _florent_: took me about 9m to `cat` a 12.5MB file to /dev/null

14:53 <somlo> that's read

14:54 <somlo> I can try to figure out a way to measure writes as well, but it'll probably have to include the time `umount` takes to flush things to actual sdcard once the file creation is reported as "complete"

14:54 <_florent_> somlo: that's slow...

14:54 <somlo> yeah, much slower than the bios

14:55 <_florent_> somlo: with the bios it would be 9s :)

14:55 <somlo> I know, I booted from it :)

14:56 <_florent_> somlo: can you provide a link to the driver?

14:56 <futarisIRCcloud> Where's the linux driver?

14:57 <somlo> https://github.com/litex-hub/linux/blob/litex-rocket-rebase/drivers/spi/spi-litespi.c

14:57 <tpb> Title: linux/spi-litespi.c at litex-rocket-rebase · litex-hub/linux · GitHub (at github.com)

15:00 <somlo> with the remark that mmc_spi (which runs unmodified from its upstream original on top of litespi) forces transfers to 8bpw

15:11 <_florent_> doing 32bpw improves speed a bit, but not that much

15:17 <somlo> _florent_: you mean in the bios? Because in linux doing anything besides 8 simply doesn't work in my experience

15:20 <_florent_> somlo: yes i switched to 32 for block xfers in the bios: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/liblitesdcard/spisdcard.c#L146

15:20 <tpb> Title: litex/spisdcard.c at master · enjoy-digital/litex · GitHub (at github.com)

15:21 <_florent_> somlo: it's a bit better (haven't measured) but not by a 60x ratio, it's more 20/30%

15:26 <_florent_> somlo: can you share the dts you are using for the mmc_spi?

15:28 <somlo> https://github.com/gsomlo/riscv-pk/blob/gls-litex-devel/machine/litex_rocket.dts

15:28 <tpb> Title: riscv-pk/litex_rocket.dts at gls-litex-devel · gsomlo/riscv-pk · GitHub (at github.com)

15:32 <_florent_> thanks