_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://freenode.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
Degi_ has joined #litex
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
CarlFK has quit [Quit: Leaving.]
scanakci has quit [Quit: Connection closed for inactivity]
HoloIRCUser1 has joined #litex
HoloIRCUser2 has joined #litex
HoloIRCUser has quit [Ping timeout: 246 seconds]
HoloIRCUser1 has quit [Ping timeout: 256 seconds]
proteusguy has quit [Ping timeout: 258 seconds]
<sajattack[m]> is that writable sd card filesystem?
<sajattack[m]> or read-only?
proteusguy has joined #litex
<somlo> sajattack[m]: it didn't occur to me to try writing to it -- will do that tomorrow :)
<somlo> *should* be r/w though...
<sajattack[m]> nice!
<Finde> that looks great somlo ! nice one
<somlo> thanks! it's unmodified LiteX gateware, just had to hack around a few "impedance mismatches" in the linux drivers (cleanup in progress)
darren099 has joined #litex
_whitelogger has joined #litex
guan has quit [*.net *.split]
rohitksingh has quit [*.net *.split]
abeljj[m] has quit [*.net *.split]
awygle has quit [*.net *.split]
st-gourichon-f has quit [*.net *.split]
palmer_ has quit [*.net *.split]
rohitksingh has joined #litex
abeljj[m] has joined #litex
guan has joined #litex
palmer_ has joined #litex
awygle has joined #litex
st-gourichon-f has joined #litex
<_florent_> somlo: great! That will be very useful, i could also test it with Vexriscv once you'll share your linux driver changes
<daveshah> _florent_: has anyone ever tested litedram with DDR4 RDIMMs
<daveshah> I am hoping to get LiteX up and running on an Alveo U250 (similar to VCU1525 and various other Ultrascale+ boards)
<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
<daveshah> I think an extra command is needed to configure/disable the register chip PLL
<_florent_> daveshah: no i haven't tested DDR4 RDIMMs, but getting it working should indeed be possible with some extra initialization commands
<daveshah> Great, that's one more thing to add to my lockdown list :)
<daveshah> The extra commands didn't look too bad at a glance
<tpb> Title: GitHub - gsomlo/linux at litex-devel-next (at github.com)
<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
<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 :)
HoloIRCUser has joined #litex
HoloIRCUser2 has quit [Ping timeout: 260 seconds]
HoloIRCUser1 has joined #litex
HoloIRCUser has quit [Ping timeout: 240 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<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
<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)
HoloIRCUser has joined #litex
HoloIRCUser1 has quit [Ping timeout: 258 seconds]
HoloIRCUser2 has joined #litex
HoloIRCUser has quit [Ping timeout: 256 seconds]
CarlFK has joined #litex
rohitksingh has quit [Ping timeout: 240 seconds]
scanakci has joined #litex
rohitksingh has joined #litex
<somlo> _florent_: for spi, what if `t->len` isn't an exact multiple of `t->bits_per_word`? Pad with 0s?
<_florent_> somlo: is bits_per_word the hardware configuration and len the software configuration for the xfer?
<somlo> yes, let's say you have a transmission of 10 bytes but your bits-per-word is 32 (4 bytes)
<somlo> what do you do for the last chunk? <something><something>00? (i.e. pad to 4 bytes for the less-significant missing portion)?
<somlo> If it requires digging around, I can do it, I was just wondering if you knew off the top of your head :)
<_florent_> ok, then yes you need to add padding the the LSBs yes
<_florent_> so in the software, do a << of bits_per_word - len
<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
<_florent_> just curious, have you been able to do some write tests with the MMC SPI?
<somlo> I can write to the sdcard, but haven't measured write speed or anything
CarlFK has quit [Quit: Leaving.]
<_florent_> ok good if that's working, that was my question, first make it work, then make it fast :)
<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
<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
<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.
<somlo> scanakci: glad you asked: http://mirror.ini.cmu.edu/benchrv64.tar
<somlo> I statically compiled coremark, linpack, and nbench for rv64gc
<somlo> scanakci: here's some numbers to compare against (from a pre-print paper I'm working on): https://imgur.com/a/IR9U2pb
<tpb> Title: Imgur: The magic of the Internet (at imgur.com)
CarlFK has joined #litex
<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
<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 :)
<somlo> and just discard the least significant bytes on rx via MOSI in the same situation
CarlFK has quit [Ping timeout: 256 seconds]
<scanakci> thanks somlo.
<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 :)
<scanakci> Great work on sd card file system. I agree with you related to a specific branch for kernel modifications to support LiteX.
<scanakci> Those changes are definitely making people's life easier when porting new cores.
<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 :)
<tpb> Title: GitHub - litex-hub/linux: Linux kernel source tree (at github.com)
<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
<tpb> Title: linux-on-litex-vexriscv/buildroot/board/litex_vexriscv/patches/linux at master · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com)
<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)
<somlo> (and hopefully didn't *break* them on 32 bits, since I'm not set up to test on vexriscv) :)
<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...
CarlFK has joined #litex
HoloIRCUser has joined #litex
HoloIRCUser1 has joined #litex
HoloIRCUser has quit [Ping timeout: 240 seconds]
HoloIRCUser2 has quit [Ping timeout: 260 seconds]
futarisIRCcloud has joined #litex
<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
<zyp> switching from 115.2kbaud to 3Mbaud halved the transfer time, so I assume it's currently dominated by latency, not throughput
<zyp> would other bridges have lower latency?
<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
<zyp> but I don't really want to spend the time trying if I'm unlikely to see any improvement