*** tpb has joined #litex | 00:00 | |
*** lkcl has quit IRC | 00:13 | |
*** Degi_ has joined #litex | 00:24 | |
*** Degi has quit IRC | 00:25 | |
*** Degi_ is now known as Degi | 00:25 | |
*** lkcl has joined #litex | 00:26 | |
*** kgugala_ has joined #litex | 04:39 | |
*** kgugala has quit IRC | 04:40 | |
*** kgugala has joined #litex | 04:41 | |
*** kgugala_ has quit IRC | 04:43 | |
*** cr1901_modern has quit IRC | 05:07 | |
*** cr1901_modern has joined #litex | 05:08 | |
*** pauluzs has joined #litex | 05:08 | |
*** Bertl_oO is now known as Bertl_zZ | 05:16 | |
*** kgugala_ has joined #litex | 05:50 | |
*** kgugala has quit IRC | 05:52 | |
shorne | hello, I am trying to use paulumack's sdcard IRQ patches from here: https://github.com/litex-hub/linux/pull/8 | 06:31 |
---|---|---|
shorne | To do that I am updating the dts generator: litex/tools/litex_json2dts.py, to define the sdirq details, but I am not seeing the interrupt number in the output csr.json | 06:33 |
shorne | I guess the soc.py is missing something like self.irq.add(name, use_loc_if_exists=True) | 06:34 |
shorne | ok, I can confirm in my output digilent_arty.v, the sdirq_irq wire is dangling and not connected to anything | 06:56 |
shorne | it looks like magically adding the "self.irq.add(name, use_loc_if_exists=True)" works | 07:01 |
shorne | maybe not | 07:03 |
*** kgugala_ has quit IRC | 07:14 | |
*** kgugala has joined #litex | 07:14 | |
shorne | I kind of see how this works, in LiteXSoC we do self.irq.add, at the end the module.ev.irq will get wired to the cpu interrupt location. | 07:49 |
shorne | however, sdcard or sdirq doesnt have module.ev, so it never gets wired to the cpu irq bus, I wonder what paulusmack is doing? | 07:50 |
shorne | ok, I think I got it working, I will send a patch maybe its wrong | 08:15 |
shorne | created a PR, https://github.com/enjoy-digital/litex/pull/901 | 08:23 |
*** Melkhior has joined #litex | 09:23 | |
*** pauluzs has quit IRC | 09:25 | |
somlo | shorne: cool, I had tried the "self.irq.add()" part too, without luck... I'll try your version later today when I get out of work | 10:18 |
shorne | somlo: it does seem to work as I commented on the linux/litex-rebase PR | 10:47 |
shorne | this one: https://github.com/litex-hub/linux/pull/8 | 10:58 |
somlo | shorne: yeah, my plan was to grab those and add them to litex-rebase as well, as soon as your litex PR 901 lands | 10:59 |
somlo | s/was/is/ :) | 11:00 |
Melkhior | @somlo @shorne Good to improve the micro-sd support, hopefully it won't degrade the reliability - i've been running on the multi-block update including large usage of swap at time with no issue at all :-) | 11:28 |
Melkhior | (Litex was able so self-host both Perl and Python to install from/to NFS and the toolchain/swap on the micro-sd) | 11:29 |
shorne | Melkhior: I wanted sd support for swap too. Its running now and seems to be working fine (with the interrupt code). | 11:37 |
Melkhior | Excellent thanks :-) | 11:38 |
shorne | Though, my benchmarks show using interrupts in the driver results is slightly lower IO throughput, it may be my board/mor1kx limiting the performance though | 11:39 |
Melkhior | @shorne Only one core I suppose ? (I think only VexRiscv has SMP support in Litex) ? Which frequency ? | 11:43 |
Melkhior | On VexRiscv-SMP my one issue with ethernet is that interrupts are always handled by core 0: | 11:43 |
Melkhior | (dolbeau)buildroot:~> cat /proc/interrupts | 11:43 |
Melkhior | CPU0 CPU1 CPU2 CPU3 | 11:43 |
Melkhior | 2: 821252 0 0 0 SiFive PLIC 2 eth0 | 11:43 |
Melkhior | 3: 3 0 0 0 SiFive PLIC 3 f0005000.ps2kbd | 11:43 |
Melkhior | But it won't affect you if you have just one core. | 11:43 |
shorne | I have just one core, I haven't setup SMP on litex yet | 11:44 |
shorne | I guess you can get irq balancing by using the user space irqbalance daemon, https://linux.die.net/man/1/irqbalance | 11:46 |
tpb | Title: irqbalance(1) - Linux man page (at linux.die.net) | 11:46 |
shorne | or you can se the affinity to move the irqs | 11:47 |
Melkhior | @shorne Darn I forgot about irqbalance | 11:50 |
shorne | echo 2 >/proc/irq/2/smp_affinity | 11:50 |
Melkhior | Will have to try that, thanks | 11:50 |
shorne | to manually move | 11:50 |
Melkhior | It's really about distributing rather than moving | 11:50 |
shorne | yeah | 11:50 |
Melkhior | though I could probably pin the userland processes to non-zero cores | 11:50 |
Melkhior | not as if I could compile with all 4 of them - not enough memory | 11:50 |
Melkhior | BTW, on my SoC reading from the sd-card seems much faster | 11:53 |
shorne | Melkhior: yea, also thanks for suggesting SMP, maybe its time I make it work on litex. There are some SMP kernel patches I need to test. And if it helps speed up my other workloads its a doulbe win. | 11:53 |
shorne | oh yeah, me too | 11:54 |
Melkhior | a ~ 2MiB file that was definitely not in memory reads in about 0.8s | 11:54 |
shorne | but my numbers are ~500 kB/s writes, ~750 kB/s reads | 11:55 |
shorne | not sure about page cache, I think I was avoiding it | 11:55 |
Melkhior | sorry I wasn't clear - I don't have your patch yet | 11:56 |
Melkhior | but the baseline pre-irq is already much faster than your baseline | 11:56 |
shorne | before the recent sd-card fixups both under 100 kB/s, and reads/writes were corrupt | 11:57 |
Melkhior | i seem to be around 1.5-2 MiB/s for pure reading (cat'ing into /dev/null) large file | 11:57 |
Melkhior | yes, I'm post-fixup, pre-irq | 11:57 |
shorne | I understood that, those ~500/750 kB/s numbers I mentioned are the pre-irq numbers I was seeing to | 11:58 |
Melkhior | so if you see a lot lower than that, maybe you're CPU-bound/memory-bound somehow already ? | 11:58 |
Melkhior | OK | 11:58 |
shorne | ok, I am a bit off | 11:59 |
shorne | pre-irq: | 11:59 |
shorne | ~ 618 kB/s write | 11:59 |
shorne | ~ 775 kB/s read | 11:59 |
shorne | irq: | 12:00 |
shorne | ~ 541 kB/s write | 12:00 |
shorne | ~ 790 kB/s read | 12:00 |
Melkhior | i'll have to try the updated version, but right now my code has diverged a bit (I added a keyboard controller and was trying a hardware bitblitter for the FB when I discovered linux removed the accelerated fbcon:-( ) | 12:00 |
shorne | they are close, it might just be jitter | 12:00 |
Melkhior | could be yes | 12:00 |
Melkhior | another hour, another conf call :-) | 12:01 |
shorne | enjoy, Japan was on holidy today :) | 12:01 |
Melkhior | bye thanks will try irqbalance and see what it does to NFS | 12:01 |
shorne | time for bed | 12:01 |
geertu | shorne: Enjoy Golden Week under lockdown ;-) | 12:11 |
*** Bertl_zZ is now known as Bertl | 12:28 | |
*** rj has quit IRC | 13:22 | |
*** RaivisR has joined #litex | 13:25 | |
RaivisR | good time of day, is there any special reason why DifferentialInput for ECP5PLL is not implemented like it is for Xilinx devices? Or should I just go ahead and make it happen? | 13:38 |
*** rj has joined #litex | 13:59 | |
gatecat | RaivisR: ECP5 doesn't need any special primitive for differential inputs | 14:03 |
gatecat | just a regular one with a suitable IO standard | 14:03 |
RaivisR | so as long as input standard is differential it will work | 14:04 |
gatecat | yeah | 14:07 |
RaivisR | thanks | 14:07 |
gatecat | (e.g. LVDS) | 14:07 |
RaivisR | that´s what I have | 14:07 |
RaivisR | still trying to get litex run on ecp5_vip, but having trouble with external DDR3 | 14:08 |
RaivisR | do sys and sys2x for ecp5ddrpy have to be derived from the same external clock and have their phase in sync? | 14:12 |
gatecat | yes, iirc sys should be divided down from sys2x | 14:12 |
gatecat | https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/lattice_versa_ecp5.py#L68-L73 | 14:13 |
RaivisR | that is what I see in every sample, but on this board I have 2 external clk inputs and I can´t meet timing constraints for sys if I use any single one of them | 14:14 |
gatecat | I'd recommend trying a lower clock frequency rather than multiple clock inputs | 14:16 |
RaivisR | how low DDR3 can go? I have no experience with that | 14:17 |
gatecat | 50MHz should be fine with the current LiteX setup | 14:19 |
RaivisR | ok, thanks, will keep learning and trying | 14:31 |
*** pauluzs has joined #litex | 14:40 | |
*** pauluzs has quit IRC | 14:48 | |
*** pauluzs has joined #litex | 14:51 | |
*** pauluzs has joined #litex | 14:51 | |
*** pauluzs has quit IRC | 15:21 | |
acathla | I have a small design on an iCE40UP5k (lattice breakout board), I put a wishbone bridge to uart and it works without a CPU, with a SERV, but timeout with a vexriscv... What could do that? | 15:21 |
*** pauluzs has joined #litex | 15:29 | |
*** Bertl is now known as Bertl_oO | 15:31 | |
_florent_ | RaivisR: I would really recommend trying to use settings/sys_clk_freq close to the other ECP5/DDR3 boards we are already supporting: Versa ECP5, OrangeCrab, Trellisboard, ECPIX5 | 15:35 |
_florent_ | acathla: I don't obvious reasons, this could be related to timings or to the CPU not behaving correctly and not releasing the Wishbone bus | 15:38 |
*** pftbest has quit IRC | 15:56 | |
*** pftbest_ has joined #litex | 15:59 | |
acathla | I'll make a simple target for the board... | 16:16 |
*** pftbest_ has quit IRC | 16:47 | |
*** pftbest has joined #litex | 16:48 | |
*** pftbest has quit IRC | 16:50 | |
*** pftbest has joined #litex | 16:54 | |
*** pftbest_ has joined #litex | 16:54 | |
acathla | _florent_, it works! I probably had a missing ASyncResetSynchroniser. | 16:58 |
acathla | Can I contribute to litex-boards? How can I add that Lattice board to the list? | 16:59 |
*** RaivisR has quit IRC | 17:33 | |
*** pftbest_ has quit IRC | 17:35 | |
geertu | acathla: Fork the litex-boards repo, add support for your bord, and send a pull request | 17:39 |
geertu | s/bord/board/ | 17:39 |
*** pftbest has joined #litex | 17:50 | |
_florent_ | nice hardware to test the recent LiteX/Linux progress: https://twitter.com/enjoy_digital/status/1387820615973982208 :) | 17:59 |
_florent_ | it just lacks a SDCard, but adding one should be possible on the HDMI/SBUS connector... | 18:01 |
nickoe | nice | 18:02 |
nickoe | _florent_: How do I get the "port" to the ram, for use with LiteDRAMDMAReader()? | 18:17 |
geertu | _florent_: Cool! Thanks to litescope, you no longer need a real scope, so found a new use for it? ;^) | 18:22 |
nickoe | If I try self.sdram.crossbar.get_port(mode="read", data_width=8) then I get AttributeError: 'SimSoC' object has no attribute 'sdram' even though I hvae a self.add_sdram("sdram",.... | 18:25 |
nickoe | or, maybe I need to enable --with-sdram? | 18:26 |
nickoe | What memory is used if not using --with-sdram? | 18:27 |
*** rj has quit IRC | 18:33 | |
*** jhu has joined #litex | 18:39 | |
jhu | Hi, I was wondering there were any prebuilt existing docker containers for running the Litex projects and specificaly the linux-on-litex project in a docker container with symbiflow toolchain? | 18:40 |
jhu | if there | 18:40 |
nickoe | I have not seen any, but I won't call my self an expert :D | 18:46 |
*** FFY00_ has quit IRC | 19:05 | |
*** FFY00_ has joined #litex | 19:06 | |
*** rj has joined #litex | 19:10 | |
nickoe | I think I got it added eventually, but .... hmmm | 19:21 |
nickoe | I just don't understand all the signals in the fifo thing | 19:23 |
nickoe | Ok, so it appears to fill the fifo of the default 16 bytes in four "bursts" | 19:26 |
nickoe | So I got this code now https://github.com/nickoe/litex-boards/blob/6f4cccb34624e248ca9296ff02737b5af7b8ca89/litex_boards/targets/mars_ax3_sim_litex.py | 19:32 |
nickoe | when I run the sim with my app to dump the address there is data https://dpaste.com/FM4W2A8SW.txt .. but I don't see it in my dma reader thing. https://dpaste.com/FM4W2A8SW.txt | 19:39 |
nickoe | zyp: What does this do? https://gist.github.com/zyp/0b5e5f1ebcc7307d0bb5a5f8c738f9cf | 19:48 |
nickoe | Is that USB implemented via some gateware and an interface to poke memory on the target? | 19:49 |
nickoe | I wonder how to empty that fifo, should I wiggle a signal? | 19:55 |
zyp | nickoe, yeah, it's a usb-wishbone-bridge, except axi-lite instead of wishbone | 20:43 |
nickoe | zyp: ok.. not that I have really understood the differences between the different axi's | 20:44 |
zyp | they are all memory buses | 20:45 |
nickoe | zyp: Do you happen to know anything about LiteDRAMDMAReader()? | 20:45 |
zyp | I've looked at it, but never used it | 20:45 |
nickoe | It appears to have a fifo, and it gets full, but I don't really see my data anywhere in the trace | 20:46 |
zyp | what are you trying to do? | 20:48 |
nickoe | read data from SDRAM and stuff it through an AXI bus to some verilog code somene else wrote that will push some data to a DAC. | 20:49 |
nickoe | right now it looks like https://i.snipboard.io/shQSFG.jpg | 20:50 |
zyp | the mydma_source_source_ready signal is stuck low | 20:53 |
zyp | that's flow control for the dma data source | 20:54 |
zyp | you see valid goes high, so it got data for you, but you're never accepting it | 20:54 |
nickoe | so I need to pull up mydma_source_source_ready ? | 20:54 |
nickoe | This is my code https://github.com/nickoe/litex-boards/blob/6f4cccb34624e248ca9296ff02737b5af7b8ca89/litex_boards/targets/mars_ax3_sim_litex.py#L177-L260 | 20:55 |
nickoe | based on the stuff from bist.py | 20:55 |
nickoe | in litedram | 20:55 |
zyp | yeah, you'll want to do dma.source.ready.eq(1) somewhere | 20:55 |
zyp | e.g. right next to dma.sink.valid.eq(1) | 20:55 |
nickoe | ok, now it certainly seem to run more! | 20:58 |
nickoe | but I don't appear to get anything on dma.source.data.eq(self.output_sig), | 21:01 |
zyp | that's the wrong way around | 21:01 |
zyp | you want self.output_sig.eq(dma.source.data) | 21:02 |
nickoe | mmm, right, but that does not appear to change the traces | 21:02 |
zyp | how does your code look now? | 21:03 |
zyp | also, how does the traces look now? | 21:03 |
nickoe | https://i.snipboard.io/CEryHB.jpg | 21:03 |
nickoe | zyp: I changed this, https://github.com/nickoe/litex-boards/commit/28a4816dae78f01e3c4217aef092e7a2570540e7 | 21:05 |
zyp | how much memory do you have? | 21:08 |
nickoe | mmm | 21:08 |
nickoe | size = kwargs.get("max_sdram_size", 0x40000000), | 21:08 |
nickoe | ? | 21:08 |
zyp | nope | 21:09 |
nickoe | mm, where can I see it? It is a simulation. | 21:09 |
zyp | okay, you've got 64M | 21:10 |
zyp | hence why you've got a 26-bit address | 21:11 |
zyp | are you sure the DMA address makes sense? | 21:11 |
nickoe | No! I am new to this :D | 21:11 |
nickoe | I use this command whe running | 21:12 |
nickoe | zyp: but the addres when read from the demo app works | 21:12 |
nickoe | see https://dpaste.com/FM4W2A8SW.txt | 21:12 |
zyp | yeah, looks fine | 21:12 |
nickoe | even if I change the address from 0x41000000 to 0x40000000, the same address as the demo.bin I don't see anything on the output_sig | 21:13 |
nickoe | Does the address need to be offset? | 21:13 |
zyp | the dma address is just the offset into the dram, not the whole 32-bit address | 21:14 |
nickoe | https://dpaste.com/7B9PUMEMA.txt | 21:14 |
zyp | but since it's mapped at 0x40000000 it works out the same when the top six bits are stripped off by the assignment | 21:14 |
nickoe | There could very well be some signal that I may be missing or something I have forgot because I didn't know about it :S | 21:18 |
nickoe | But it is getting at bit late for me now, and I am getting quite tired, so I should probably call it a day. | 21:19 |
nickoe | anyway, my goal was to see my data in the trace, and then I can start to stuff that into some AXI stream or something | 21:20 |
zyp | it is already in a steram | 21:20 |
zyp | stream* | 21:20 |
zyp | you're picking it out of a stream, doesn't make sense to do that just to stuff it back in :) | 21:21 |
zyp | and you don't have to think about axi streams, plain litex streams are pretty much the same | 21:22 |
nickoe | But I guess I must see some data here before I move on | 21:23 |
nickoe | if just ... | 21:30 |
nickoe | ... I could realize how | 21:31 |
*** rj has quit IRC | 21:47 | |
*** rj has joined #litex | 21:47 | |
*** pftbest has quit IRC | 22:02 | |
*** pftbest has joined #litex | 22:02 | |
*** lf has quit IRC | 23:19 | |
*** lf has joined #litex | 23:20 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!