| *** tpb has joined #litex | 00:00 | |
| *** Degi_ has joined #litex | 00:16 | |
| *** Degi has quit IRC | 00:19 | |
| *** Degi_ is now known as Degi | 00:19 | |
| *** CarlFK has quit IRC | 01:54 | |
| *** scanakci has quit IRC | 02:14 | |
| somlo | \o/ http://www.contrib.andrew.cmu.edu/~somlo/BTCP/litex-spi-mmc.mp4 | 02:28 |
|---|---|---|
| *** HoloIRCUser1 has joined #litex | 02:32 | |
| *** HoloIRCUser2 has joined #litex | 02:32 | |
| *** HoloIRCUser has quit IRC | 02:34 | |
| *** HoloIRCUser1 has quit IRC | 02:36 | |
| *** proteusguy has quit IRC | 02:42 | |
| sajattack[m] | is that writable sd card filesystem? | 02:49 |
| sajattack[m] | or read-only? | 02:52 |
| *** proteusguy has joined #litex | 02:56 | |
| 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:11 |
| sajattack[m] | nice! | 03:16 |
| Finde | that looks great somlo ! nice one | 03:22 |
| somlo | thanks! 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 #litex | 05:07 | |
| *** _whitelogger has quit IRC | 06:09 | |
| *** _whitelogger has joined #litex | 06:11 | |
| *** guan has quit IRC | 06:13 | |
| *** rohitksingh has quit IRC | 06:13 | |
| *** abeljj[m] has quit IRC | 06:13 | |
| *** awygle has quit IRC | 06:13 | |
| *** st-gourichon-f has quit IRC | 06:13 | |
| *** palmer_ has quit IRC | 06:13 | |
| *** guan has joined #litex | 06:15 | |
| *** rohitksingh has joined #litex | 06:15 | |
| *** abeljj[m] has joined #litex | 06:15 | |
| *** awygle has joined #litex | 06:15 | |
| *** st-gourichon-f has joined #litex | 06:15 | |
| *** palmer_ has joined #litex | 06: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:15 |
| 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:22 |
| 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:23 |
| _florent_ | daveshah: no i haven't tested DDR4 RDIMMs, but getting it working should indeed be possible with some extra initialization commands | 08:33 |
| 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 | 08:34 |
| 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:49 |
| 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:50 |
| 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 :) | 12:51 |
| *** HoloIRCUser has joined #litex | 12:56 | |
| *** HoloIRCUser2 has quit IRC | 13:00 | |
| *** HoloIRCUser1 has joined #litex | 13:10 | |
| *** HoloIRCUser has quit IRC | 13:12 | |
| *** futarisIRCcloud has quit IRC | 13:44 | |
| 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) | 13:51 |
| *** HoloIRCUser has joined #litex | 15:51 | |
| *** HoloIRCUser1 has quit IRC | 15:54 | |
| *** HoloIRCUser2 has joined #litex | 16:04 | |
| *** HoloIRCUser has quit IRC | 16:07 | |
| *** CarlFK has joined #litex | 18:22 | |
| *** rohitksingh has quit IRC | 19:43 | |
| *** scanakci has joined #litex | 20:53 | |
| *** rohitksingh has joined #litex | 21: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 |
| 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)? | 21:58 |
| somlo | If 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 yes | 22:00 |
| _florent_ | so in the software, do a << of bits_per_word - len | 22:01 |
| 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:02 |
| *** CarlFK has quit IRC | 22:03 | |
| _florent_ | ok good if that's working, that was my question, first make it work, then make it fast :) | 22:03 |
| 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:04 |
| 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:05 |
| somlo | scanakci: glad you asked: http://mirror.ini.cmu.edu/benchrv64.tar | 22:06 |
| somlo | I statically compiled coremark, linpack, and nbench for rv64gc | 22:08 |
| 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:12 |
| *** CarlFK has joined #litex | 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:25 |
| 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:27 |
| somlo | and just discard the least significant bytes on rx via MOSI in the same situation | 22:28 |
| *** CarlFK has quit IRC | 22:29 | |
| 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:30 |
| scanakci | Great work on sd card file system. I agree with you related to a specific branch for kernel modifications to support LiteX. | 22:31 |
| scanakci | Those changes are definitely making people's life easier when porting new cores. | 22:32 |
| 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:33 |
| 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:35 |
| 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:36 |
| somlo | (and hopefully didn't *break* them on 32 bits, since I'm not set up to test on vexriscv) :) | 22:37 |
| 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... | 22:38 |
| *** CarlFK has joined #litex | 22:42 | |
| *** HoloIRCUser has joined #litex | 22:45 | |
| *** HoloIRCUser1 has joined #litex | 22:46 | |
| *** HoloIRCUser has quit IRC | 22:49 | |
| *** HoloIRCUser2 has quit IRC | 22:49 | |
| *** futarisIRCcloud has joined #litex | 23:05 | |
| futarisIRCcloud | https://www.usenix.org/system/files/sec20fall_ender_prepub.pdf | 23:06 |
| 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:29 |
| zyp | switching from 115.2kbaud to 3Mbaud halved the transfer time, so I assume it's currently dominated by latency, not throughput | 23:30 |
| zyp | would other bridges have lower latency? | 23:31 |
| 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:35 |
| zyp | but I don't really want to spend the time trying if I'm unlikely to see any improvement | 23:36 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!