Sunday, 2020-04-19

*** tpb has joined #litex00:00
*** Degi_ has joined #litex00:16
*** Degi has quit IRC00:19
*** Degi_ is now known as Degi00:19
*** CarlFK has quit IRC01:54
*** scanakci has quit IRC02:14
somlo\o/ http://www.contrib.andrew.cmu.edu/~somlo/BTCP/litex-spi-mmc.mp402:28
*** HoloIRCUser1 has joined #litex02:32
*** HoloIRCUser2 has joined #litex02:32
*** HoloIRCUser has quit IRC02:34
*** HoloIRCUser1 has quit IRC02:36
*** proteusguy has quit IRC02:42
sajattack[m]is that writable sd card filesystem?02:49
sajattack[m]or read-only?02:52
*** proteusguy has joined #litex02:56
somlosajattack[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:11
sajattack[m]nice!03:16
Findethat looks great somlo ! nice one03:22
somlothanks! it's unmodified LiteX gateware, just had to hack around a few "impedance mismatches" in the linux drivers (cleanup in progress)03:33
*** darren099 has joined #litex05:07
*** _whitelogger has quit IRC06:09
*** _whitelogger has joined #litex06:11
*** guan has quit IRC06:13
*** rohitksingh has quit IRC06:13
*** abeljj[m] has quit IRC06:13
*** awygle has quit IRC06:13
*** st-gourichon-f has quit IRC06:13
*** palmer_ has quit IRC06:13
*** guan has joined #litex06:15
*** rohitksingh has joined #litex06:15
*** abeljj[m] has joined #litex06:15
*** awygle has joined #litex06:15
*** st-gourichon-f has joined #litex06:15
*** palmer_ has joined #litex06:15
_florent_somlo: great! That will be very useful, i could also test it with Vexriscv once you'll share your linux driver changes08:15
daveshah_florent_: has anyone ever tested litedram with DDR4 RDIMMs08:22
daveshahI am hoping to get LiteX up and running on an Alveo U250 (similar to VCU1525 and various other Ultrascale+ boards)08:22
daveshahand the memory it comes with is RDIMMs, although I could replace them with regular ones it would be nice to have it working as is08:23
daveshahI think an extra command is needed to configure/disable the register chip PLL08:23
_florent_daveshah: no i haven't tested DDR4 RDIMMs, but getting it working should indeed be possible with some extra initialization commands08:33
daveshahGreat, that's one more thing to add to my lockdown list :)08:34
daveshahThe extra commands didn't look too bad at a glance08:34
somlo_florent_: https://github.com/gsomlo/linux/tree/litex-devel-next12:49
tpbTitle: GitHub - gsomlo/linux at litex-devel-next (at github.com)12:49
somloI'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 6412:50
somloalso, 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 :)12:51
*** HoloIRCUser has joined #litex12:56
*** HoloIRCUser2 has quit IRC13:00
*** HoloIRCUser1 has joined #litex13:10
*** HoloIRCUser has quit IRC13:12
*** futarisIRCcloud has quit IRC13:44
somlomore detailed set of current `spi_litespi.c` linux driver issues at https://github.com/litex-hub/linux-on-litex-vexriscv/issues/122#issuecomment-61613907313:51
tpbTitle: 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)13:51
*** HoloIRCUser has joined #litex15:51
*** HoloIRCUser1 has quit IRC15:54
*** HoloIRCUser2 has joined #litex16:04
*** HoloIRCUser has quit IRC16:07
*** CarlFK has joined #litex18:22
*** rohitksingh has quit IRC19:43
*** scanakci has joined #litex20:53
*** rohitksingh has joined #litex21:50
somlo_florent_: for spi, what if `t->len` isn't an exact multiple of `t->bits_per_word`? Pad with 0s?21:55
_florent_somlo: is bits_per_word the hardware configuration and len the software configuration for the xfer?21:57
somloyes, let's say you have a transmission of 10 bytes but your bits-per-word is 32 (4 bytes)21:58
somlowhat do you do for the last chunk? <something><something>00? (i.e. pad to 4 bytes for the less-significant missing portion)?21:58
somloIf it requires digging around, I can do it, I was just wondering if you knew off the top of your head :)21:59
_florent_ok, then yes you need to add padding the the LSBs yes22:00
_florent_so in the software, do a << of bits_per_word - len22:01
somlothanks! 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 layer22:02
_florent_just curious, have you been able to do some write tests with the MMC SPI?22:02
somloI can write to the sdcard, but haven't measured write speed or anything22:02
*** CarlFK has quit IRC22:03
_florent_ok good if that's working, that was my question, first make it work, then make it fast :)22:03
somloright 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 later22:04
somlobut 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 :D22:04
scanakciIs 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:05
somloscanakci: glad you asked: http://mirror.ini.cmu.edu/benchrv64.tar22:06
somloI statically compiled coremark, linpack, and nbench for rv64gc22:08
somloscanakci: here's some numbers to compare against (from a pre-print paper I'm working on): https://imgur.com/a/IR9U2pb22:12
tpbTitle: Imgur: The magic of the Internet (at imgur.com)22:12
*** CarlFK has joined #litex22: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 MISO22:25
somloso 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:27
somloand just discard the least significant bytes on rx via MOSI in the same situation22:28
*** CarlFK has quit IRC22:29
scanakcithanks 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:30
scanakciGreat work on sd card file system. I agree with you related to a specific branch for kernel modifications to support LiteX.22:31
scanakciThose changes are definitely making people's life easier when porting new cores.22:32
somloscanakci: 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
tpbTitle: GitHub - litex-hub/linux: Linux kernel source tree (at github.com)22:33
somlosince 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/linux22:35
tpbTitle: linux-on-litex-vexriscv/buildroot/board/litex_vexriscv/patches/linux at master · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com)22:35
somloI 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:36
somlo(and hopefully didn't *break* them on 32 bits, since I'm not set up to test on vexriscv) :)22:37
somlobut 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...22:38
*** CarlFK has joined #litex22:42
*** HoloIRCUser has joined #litex22:45
*** HoloIRCUser1 has joined #litex22:46
*** HoloIRCUser has quit IRC22:49
*** HoloIRCUser2 has quit IRC22:49
*** futarisIRCcloud has joined #litex23:05
futarisIRCcloudhttps://www.usenix.org/system/files/sec20fall_ender_prepub.pdf23:06
zypdoes 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 transfer23:29
zypswitching from 115.2kbaud to 3Mbaud halved the transfer time, so I assume it's currently dominated by latency, not throughput23:30
zypwould other bridges have lower latency?23:31
zypthis is on the colorlight board, so etherbone would be an option if it could be made to work properly, another would be the valentyusb bridge23:35
zypbut I don't really want to spend the time trying if I'm unlikely to see any improvement23:36

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!