02:28 <somlo> \o/ http://www.contrib.andrew.cmu.edu/~somlo/BTCP/litex-spi-mmc.mp4

02:49 <sajattack[m]> is that writable sd card filesystem?

02:52 <sajattack[m]> or read-only?

03:11 <somlo> sajattack[m]: it didn't occur to me to try writing to it -- will do that tomorrow :)

03:11 <somlo> *should* be r/w though...

03:16 <sajattack[m]> nice!

03:22 <Finde> that looks great somlo ! nice one

03:33 <somlo> thanks! it's unmodified LiteX gateware, just had to hack around a few "impedance mismatches" in the linux drivers (cleanup in progress)

08:15 <_florent_> somlo: great! That will be very useful, i could also test it with Vexriscv once you'll share your linux driver changes

08:22 <daveshah> _florent_: has anyone ever tested litedram with DDR4 RDIMMs

08:22 <daveshah> I am hoping to get LiteX up and running on an Alveo U250 (similar to VCU1525 and various other Ultrascale+ boards)

08:23 <daveshah> and the memory it comes with is RDIMMs, although I could replace them with regular ones it would be nice to have it working as is

08:23 <daveshah> I think an extra command is needed to configure/disable the register chip PLL

08:33 <_florent_> daveshah: no i haven't tested DDR4 RDIMMs, but getting it working should indeed be possible with some extra initialization commands

08:34 <daveshah> Great, that's one more thing to add to my lockdown list :)

08:34 <daveshah> The extra commands didn't look too bad at a glance

12:49 <somlo> _florent_: https://github.com/gsomlo/linux/tree/litex-devel-next

12:49 <tpb> Title: GitHub - gsomlo/linux at litex-devel-next (at github.com)

12:50 <somlo> I'm still cleaning up the litespi driver, but this should be OK to test with -- I'm particularly curious if the soc controller, ethernet, and spi still work on 32-bits, now that I've made them "flexible" for 64

12:51 <somlo> also, I wonder if it might be time to create a litex-hub/linux fork with a few branches carrying litex specific kernel patches, and maybe even a litex-hub/linux-on-litex-rocket :)

13:51 <somlo> more detailed set of current `spi_litespi.c` linux driver issues at https://github.com/litex-hub/linux-on-litex-vexriscv/issues/122#issuecomment-616139073

13:51 <tpb> Title: Making soc_controller (and all kernel drivers) work on all widths and alignments · Issue #122 · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com)

21:55 <somlo> _florent_: for spi, what if `t->len` isn't an exact multiple of `t->bits_per_word`? Pad with 0s?

21:57 <_florent_> somlo: is bits_per_word the hardware configuration and len the software configuration for the xfer?

21:58 <somlo> yes, let's say you have a transmission of 10 bytes but your bits-per-word is 32 (4 bytes)

21:58 <somlo> what do you do for the last chunk? <something><something>00? (i.e. pad to 4 bytes for the less-significant missing portion)?

22:00 <somlo> If it requires digging around, I can do it, I was just wondering if you knew off the top of your head :)

22:00 <_florent_> ok, then yes you need to add padding the the LSBs yes

22:01 <_florent_> so in the software, do a << of bits_per_word - len

22:02 <somlo> thanks! I still need to figure out if that's something the layer above does before adding a new transmission to the queue, or something I have to watch out for at the spi host layer

22:02 <_florent_> just curious, have you been able to do some write tests with the MMC SPI?

22:02 <somlo> I can write to the sdcard, but haven't measured write speed or anything

22:03 <_florent_> ok good if that's working, that was my question, first make it work, then make it fast :)

22:04 <somlo> right now I just want to get the litespi driver to behave exactly the way the original antmicro one was intended to behave, except also work smoothly on 64bits; I'll worry about performance later

22:04 <somlo> but yes, it does both read and write to the card -- I should really just prioritize booting Fedora on trellis at this point, but I have a bit of OCD and want everything to be perfect before I can move on :D

22:05 <scanakci> Is there already available setup in LiteX that will allow me to compare BlackParrot with other core (e.g., Rocket) in terms of performance? Maybe some tests, benchmarks? I am curious how BP is performing compared to Rocket and will probably look into that once I finalize boot-up on FPGA.

22:06 <somlo> scanakci: glad you asked: http://mirror.ini.cmu.edu/benchrv64.tar

22:08 <somlo> I statically compiled coremark, linpack, and nbench for rv64gc

22:12 <somlo> scanakci: here's some numbers to compare against (from a pre-print paper I'm working on): https://imgur.com/a/IR9U2pb

22:12 <tpb> Title: Imgur: The magic of the Internet (at imgur.com)

22:25 <somlo> _florent_: I was going to replace memcpy() with `reg <<= 8; reg |= next_byte` before writing a larger-than-8-bit MOSI, and the reverse operation for receiving and MISO

22:27 <somlo> so if I run out of `next_byte` elements (end of `t->len`) before filling it with the full number of `bpw`, I just keep shifting :)

22:28 <somlo> and just discard the least significant bytes on rx via MOSI in the same situation

22:30 <scanakci> thanks somlo.

22:30 <somlo> _florent_: (because memcpy-ing to &large_reg from t->tx_buf will only work on one CPU endianness, and not the other -- can't tell which one off the top of my head :)

22:31 <scanakci> Great work on sd card file system. I agree with you related to a specific branch for kernel modifications to support LiteX.

22:32 <scanakci> Those changes are definitely making people's life easier when porting new cores.

22:33 <somlo> scanakci: you're welcome! And _florent_ has already prepared https://github.com/litex-hub/linux (thanks, _florent_!), now all I need is to find some time next week to upload everything there to make it official :)

22:33 <tpb> Title: GitHub - litex-hub/linux: Linux kernel source tree (at github.com)

22:35 <somlo> since my current tree at github.com/gsomlo/linux/tree/litex-devel-next starts with the 16 existing patches from https://github.com/litex-hub/linux-on-litex-vexriscv/tree/master/buildroot/board/litex_vexriscv/patches/linux

22:35 <tpb> Title: linux-on-litex-vexriscv/buildroot/board/litex_vexriscv/patches/linux at master · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com)

22:36 <somlo> I wanted to start by adding the proper commit log entries and "signed-off-by" from the authors of those patches; my stuff goes on top of that (I only changed the litex_soc, liteeth, and litespi drivers to work on both 32 and 64 bits)

22:37 <somlo> (and hopefully didn't *break* them on 32 bits, since I'm not set up to test on vexriscv) :)

22:38 <somlo> but if I can hide from $DAYJOB for a few hours this upcoming week, I should be able to clean all that up and put it into the official litex-hub repo...

23:06 <futarisIRCcloud> https://www.usenix.org/system/files/sec20fall_ender_prepub.pdf

23:29 <zyp> does anybody happen to have any numbers on wishbone bridge performance? I'm currently using litescope with the uart bridge and I'm getting impatient every time I make a capture, waiting for it to transfer

23:30 <zyp> switching from 115.2kbaud to 3Mbaud halved the transfer time, so I assume it's currently dominated by latency, not throughput

23:31 <zyp> would other bridges have lower latency?

23:35 <zyp> this is on the colorlight board, so etherbone would be an option if it could be made to work properly, another would be the valentyusb bridge

23:36 <zyp> but I don't really want to spend the time trying if I'm unlikely to see any improvement