| *** tpb has joined #litex | 00:00 | |
| *** lf has quit IRC | 00:22 | |
| *** lf has joined #litex | 00:22 | |
| *** FFY00 has quit IRC | 01:16 | |
| *** FFY00 has joined #litex | 02:22 | |
| *** Degi_ has joined #litex | 03:48 | |
| *** Degi has quit IRC | 03:49 | |
| *** Degi_ is now known as Degi | 03:49 | |
| *** CarlFK has joined #litex | 04:14 | |
| *** key2 has quit IRC | 04:57 | |
| *** key2 has joined #litex | 04:57 | |
| *** Bertl_oO is now known as Bertl_zZ | 05:06 | |
| *** futarisIRCcloud has joined #litex | 05:18 | |
| *** cr1901_modern has quit IRC | 05:19 | |
| *** cr1901_modern has joined #litex | 05:44 | |
| *** CarlFK has quit IRC | 06:04 | |
| *** CarlFK has joined #litex | 06:23 | |
| *** CarlFK has quit IRC | 06:41 | |
| *** FFY00 has quit IRC | 06:41 | |
| *** futarisIRCcloud has quit IRC | 07:28 | |
| *** hansfbaier has joined #litex | 08:51 | |
| *** lkcl has quit IRC | 09:10 | |
| *** lkcl has joined #litex | 09:22 | |
| *** hansfbaier has quit IRC | 10:43 | |
| *** hansfbaier has joined #litex | 10:45 | |
| *** shorne has joined #litex | 11:51 | |
| shorne | Hello, I am looking at the linux kernel litex_mmc driver, https://github.com/litex-hub/linux/blob/litex-rocket-rebase/drivers/mmc/host/litex_mmc.c#L281 | 11:54 |
|---|---|---|
| shorne | I noticed the performance on mor1kx arty is slow ~1.6mb/sec | 11:55 |
| shorne | I notice for the dma transfer we use: sg_copy_to_buffer(), which will slow things down, the alternative is to use dma channel's | 11:57 |
| shorne | I haven't implemented this before but I will look into to see how it will help, just want to mention it to get any feedback | 11:58 |
| shorne | I am not sure if there is a "real" dma engine with multiple programmable channels that can handle scatter gather | 12:11 |
| _florent_ | Hi | 12:20 |
| _florent_ | nickoe: would you mind creating an issue in litex with your notes/questions? this will be easier to answer | 12:21 |
| _florent_ | shorne: we don't currently have scatter gather for the SDCard's DMA | 12:22 |
| _florent_ | but if you think this is useful, I could have a look. It seems that currently the SDCard is a lot slower in Linux than with the BIOS, we should probably try to understand that first since the limitations seems to come from the software. | 12:25 |
| *** Bertl_zZ is now known as Bertl | 12:50 | |
| *** lkcl has quit IRC | 12:57 | |
| *** lkcl has joined #litex | 13:09 | |
| *** hansfbaier has quit IRC | 13:39 | |
| somlo | _florent_, shorne: after having stared at the Linux litesdcard driver for a loooong time, I can't find anything it's doing significantly different from what the LiteX bios does in terms of accessing the card, other than maybe the timing of the requests (although even disabling interrupts on a single-core soc around litex_request() doesn't seem to make a difference) | 13:40 |
| somlo | likely I'm missing something, but the litesdcard FSMs are timing out left and right when driven by the Linux driver, and seem happy and healthy when driven by the bios... | 13:43 |
| *** mikeK_de1soc has joined #litex | 14:00 | |
| *** FFY00 has joined #litex | 14:03 | |
| somlo | _florent_, shorne: https://github.com/enjoy-digital/litex/pull/820 should ensure that 1. we never timeout during sdcardboot (even on weird CPU configurations such as Rocket :) and 2. don't run into command timeouts with the LiteSDCard FSMs in single-block (cmd17-only) mode on the Linux driver | 14:36 |
| somlo | This should help stabilize the current linux driver for now at no extra penalty for any other sdcard use (larger timeout values don't actually slow down the sdcard FSMs when things work *well*, they just avoid unnecessary errors and retries in linux) | 14:38 |
| somlo | I'm still trying to get to the bottom of why enabling cmd18 multi-block breaks horribly even with the larger timeouts | 14:38 |
| somlo | and will open a separate issue once I have my ducks in a row (have to remember everything I tried and write down a coherent report) | 14:39 |
| _florent_ | thanks @somlo, the PR looks fine, I'm going to merge it. For the issue with the Linux driver, I could do some capture of the SDCard signals with an external logic analyzer to try to understand the difference between the BIOS and Linux driver. | 14:43 |
| somlo | _florent_: thanks, that could be helpful! I've been studying the migen sources (and doing remedial learning on streams, as you are aware) | 14:52 |
| somlo | I'm slow almost by definition -- anything I need to touch I need to learn from scratch, first :) | 14:52 |
| _florent_ | That's a good approach that I also generally try to apply when time allows it :) (and your feedback while learning is very valuable). | 14:56 |
| _florent_ | somlo: when in Linux, can you tell me how you reproduce the timeouts easily? I could try on Arty with Linux-on-LiteX-VexRiscv | 14:57 |
| somlo | _florent_: https://github.com/litex-hub/linux/blob/litex-rebase/drivers/mmc/host/litex_mmc.c#L415 | 14:59 |
| somlo | change max_blk_count to 2 | 14:59 |
| somlo | that will enable cmd-18 for reads | 15:00 |
| somlo | I tried to document my understanding of how the mmc subsystem figures out everything else around that setting in the surrounding comments | 15:01 |
| somlo | scatter/gather is off by default (as it should be, for now) | 15:02 |
| *** futarisIRCcloud has joined #litex | 16:13 | |
| tmbinc | _florent_: for programming the sds1104xe.bit, is setting the scope's jumper to "JTAG", then using openocd's "zynqpl_program"/"pld load" the right approach? (I've always used Xilinx tools before on Zynq) | 17:00 |
| nickoe | _florent_: Ok, I can try to do that. | 17:01 |
| mithro | _florent_: Do the Ibex pythondata packages look okay? https://github.com/enjoy-digital/litex/issues/695 ? | 17:28 |
| *** shoragan has joined #litex | 17:28 | |
| *** mikeK_de1soc has quit IRC | 17:47 | |
| *** Bertl is now known as Bertl_oO | 18:36 | |
| *** mikeK_de1soc has joined #litex | 19:17 | |
| mikeK_de1soc | _florent_: I was just wondering, Is the LiteVideo Currently working? I would like to use it for te DE1-SoC board. Thanks! | 19:34 |
| shorne | _florent_: I think the reason the sdcard is slower in linux is because of sg_copy_to_buffer(), I can't easily prove it now, I'llhave to think thow to profile the code in the driver. | 21:01 |
| shorne | In the bios: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/liblitesdcard/sdcard.c#L503-L510, the read/write can transfer the user buffer directly to the sdcard | 21:02 |
| shorne | to/from the sdcard | 21:02 |
| shorne | in linux the driver gets a bunch of blocks in the scatter gather list, it then has to, in software, copy those into a dma buffer (with sg_copy_to_buffer) before sending to the sdcard (similar for reading). | 21:04 |
| shorne | that extra copy slows it down. is my assumption. With a dma engine the hardware could handle the sg lists directly via queuing multiple small dma transactions. | 21:11 |
| shorne | Thats what I gather from my investigatiion last mogjt reading the kernel code and some dma controller specs | 21:20 |
| shorne | Just found this, page 2 explains it pretty clearly https://www.intel.co.jp/content/dam/altera-www/global/ja_JP/pdfs/literature/hb/nios2/qts_qii55003.pdf | 21:20 |
| _florent_ | tmbinc: if you generated the bistream with the target from litex-boards, you can also use --load (it uses VivadoProgrammer) | 21:31 |
| _florent_ | tmbinc: I could provide you some test bistreams if you want to check your hardware (tomorrow) | 21:32 |
| _florent_ | mithro: thanks for the pythondata repos, I'll have a closer look tomorrow and do the integration | 21:33 |
| _florent_ | shorne: thanks interesting, do you know what's the general queue depth of usual scatter gather for similar cases? Implementing it should not be too complicated if you think this can be useful (just adding a FIFO for the queue) | 21:37 |
| shorne | _florent_: I am trying to figure that out too at the moment, I know they talk about having 32/64 channels, but I think that is for each device connected, the queue depth is separate | 21:38 |
| mikeK_de1soc | _florent_: Do you have an example of how to implement the liteVideo submodule? | 21:38 |
| tmbinc | _florent_: thanks - I've (now) noticed --load, and I'll check what Vivado does differently than my openocd setup. In neither case I could get UDP traffic working, maybe I should route the serial port to some physical pins first | 21:43 |
| tmbinc | (I didn't use --load but used hardware manager manually since I need a Xilinx Virtual Cable setup) | 21:44 |
| shorne | _florent_: it looks like some dma engines the command queue is even 1, and the queue is maintained per channel in the kernel side (readin r-car dma controller driver). | 21:56 |
| shorne | I can't find docs for that, I found docs for this https://www.nxp.com/docs/en/application-note/AN4522.pdf | 21:56 |
| somlo | _florent_, shorne: I think it's a bit worse than just lack of SG support -- the command timeout happens here in the litesdcard core: https://github.com/enjoy-digital/litesdcard/blob/master/litesdcard/core.py#L142 | 21:57 |
| somlo | which is before any data transfer comes into play | 21:57 |
| shorne | I will read more, maybe I can try programming a 1-channel dma engine for sdcard | 21:57 |
| shorne | I see | 21:57 |
| shorne | I didn't notice the timeouts | 21:58 |
| shorne | I will see if that is happening for me too | 21:58 |
| shorne | Got to go | 21:58 |
| somlo | so while I agree SG will probably make it faster in the end, I'd like to understand why simply increasing the command, data, (and sure, DMA) timeouts in the linux driver to as huge as we can *still* won't make the errors go away :) | 21:58 |
| somlo | I.e., I get a 2 (timeout) here: https://github.com/litex-hub/linux/blob/litex-rebase/drivers/mmc/host/litex_mmc.c#L125 | 22:01 |
| somlo | when I enable >1 max_blk_count in `probe` | 22:02 |
| somlo | shorne: (for when you get back :) -- I think there's two problems: performance in linux, and an actual bona-fide *bug* | 22:04 |
| somlo | my first instinct to make it go faster was to allow multi-block transfers (e.g., cmd-18 for reads) by increasing max_blk_count | 22:04 |
| somlo | which *should* work, but triggers the weird timeouts I've been running into (i.e., the bug) :) | 22:04 |
| somlo | I think SG should help, but IMHO we should get the linux driver to work with multi-block transfers (18 for reads, 25 for writes) | 22:06 |
| somlo | * first :) | 22:06 |
| somlo | and also IRQ support :) | 22:08 |
| _florent_ | mikeK_de1soc: here is an example on Xilinx FPGAs: https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/soc_linux.py#L148-L180 | 22:13 |
| mikeK_de1soc | _florent_: Many Thanks! | 22:13 |
| _florent_ | you can find other examples in litex-buildenv, in the video targets: https://github.com/timvideos/litex-buildenv/blob/master/targets/atlys/video.py | 22:14 |
| mikeK_de1soc | OK great! BTW got the DE1-SoC Led chaser to work! https://youtu.be/bgpP9cWTnJQ | 22:16 |
| _florent_ | tmbinc: were you pinging the board at 192.168.1.50? I could generate/test a bistream and then send if to you. | 22:16 |
| _florent_ | somlo: yes sure, we first need to get rid of the timeout issue before looking for performance | 22:18 |
| mikeK_de1soc | _florent_: tim's buildenv, does not seem to have the Altera DE1 or DE10 boards in his repo, is it worth starting? | 22:22 |
| tmbinc | _florent_: Got it working - Ethernet only started working after I unplug it once, both Vivado->xvcd as well as openocd work for programming | 22:25 |
| _florent_ | tmbinc: do you know/remember if there was something specific to be able to use the LCD of the sds1104xe? I remember doing a very quick test last year but haven't got it working (also haven't spend too much time understanding), is is just vga? with the pins from https://github.com/360nosc0pe/siglent_hardware/blob/master/sds1104xe/fpga_pinout.txt#L13-L48 | 22:27 |
| tmbinc | _florent_: I'll port over the stuff I had (will probably look rough :) regarding the DAC analog MUX and the other components to configure the frontend. I don't remember exactly but I remember we've been using PS SPI for PLL setup, I need to check if this can be done from PL side as well | 22:28 |
| tmbinc | _florent_: LCD was done by G33KatWork or q3k, I need to check | 22:28 |
| tmbinc | (it already worked when I started on it) | 22:29 |
| _florent_ | tmbinc: ok good you got it working. So now basically you'll be able to control the SoC over UDP with litex_server | 22:29 |
| tmbinc | yep - very nice! (Never worked on an ethernet-enabled litex device, so this is more friendly than I imagined :) | 22:30 |
| _florent_ | just need to start the server with litex_server --udp and then execute your scripts to control your DAC registers | 22:30 |
| _florent_ | A brief overview: https://github.com/enjoy-digital/litex/wiki/Use-Host-Bridge-to-control-debug-a-SoC | 22:30 |
| tmbinc | Thanks | 22:31 |
| _florent_ | if you need to look at signals, you can also use Litescope over the bridge: https://github.com/enjoy-digital/litex/wiki/Use-LiteScope-To-Debug-A-SoC | 22:31 |
| tmbinc | I need to adapt/rewrite https://github.com/360nosc0pe/fpga/blob/master/py/lxwrap/offsetdac.py | 22:32 |
| mikeK_de1soc | MAn,, that is insane! | 22:32 |
| mikeK_de1soc | Drool..... I really want to get my DE1-SoC Video working... still learning... | 22:33 |
| _florent_ | tmbinc: looking at your code, I think you should be able to integrate it without modification (or maybe only minors) | 22:34 |
| _florent_ | in your SoC: | 22:35 |
| _florent_ | from offsetdac import OffsetDac | 22:35 |
| _florent_ | self.submodules.offset_dac = OffsetDac() | 22:35 |
| tmbinc | Is AutoCSR still a thing? My migen knowledge is... from 2014 | 22:35 |
| _florent_ | self.add_csr("offset_dac") | 22:35 |
| _florent_ | should do it | 22:35 |
| _florent_ | yes | 22:36 |
| _florent_ | I have to go, I could help more tomorrow if you have trouble integrating your old code | 22:37 |
| tmbinc | My duty cycle working on this will be small unfortunately but I'll see how far I get | 22:37 |
| tmbinc | Thanks for your help already! | 22:37 |
| somlo | _florent_, shorne: https://github.com/enjoy-digital/litesdcard/issues/22 | 22:49 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!