Thursday, 2021-04-29

*** tpb has joined #litex00:00
*** lkcl has quit IRC00:13
*** Degi_ has joined #litex00:24
*** Degi has quit IRC00:25
*** Degi_ is now known as Degi00:25
*** lkcl has joined #litex00:26
*** kgugala_ has joined #litex04:39
*** kgugala has quit IRC04:40
*** kgugala has joined #litex04:41
*** kgugala_ has quit IRC04:43
*** cr1901_modern has quit IRC05:07
*** cr1901_modern has joined #litex05:08
*** pauluzs has joined #litex05:08
*** Bertl_oO is now known as Bertl_zZ05:16
*** kgugala_ has joined #litex05:50
*** kgugala has quit IRC05:52
shornehello,  I am trying to use paulumack's sdcard IRQ patches from here: https://github.com/litex-hub/linux/pull/806:31
shorneTo 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.json06:33
shorneI guess the soc.py is missing something like self.irq.add(name, use_loc_if_exists=True)06:34
shorneok, I can confirm in my output digilent_arty.v, the sdirq_irq wire is  dangling and not connected to anything06:56
shorneit looks like magically adding the "self.irq.add(name, use_loc_if_exists=True)" works07:01
shornemaybe not07:03
*** kgugala_ has quit IRC07:14
*** kgugala has joined #litex07:14
shorneI 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
shornehowever, 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
shorneok, I think I got it working, I will send a patch maybe its wrong08:15
shornecreated a PR, https://github.com/enjoy-digital/litex/pull/90108:23
*** Melkhior has joined #litex09:23
*** pauluzs has quit IRC09:25
somloshorne: cool, I had tried the "self.irq.add()" part too, without luck... I'll try your version later today when I get out of work10:18
shornesomlo: it does seem to work as I commented on the linux/litex-rebase PR10:47
shornethis one: https://github.com/litex-hub/linux/pull/810:58
somloshorne: yeah, my plan was to grab those and add them to litex-rebase as well, as soon as your litex PR 901 lands10:59
somlos/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
shorneMelkhior: I wanted sd support for swap too. Its running now and seems to be working fine (with the interrupt code).11:37
MelkhiorExcellent thanks :-)11:38
shorneThough, my benchmarks show using interrupts in the driver results is slightly lower IO throughput, it may be my board/mor1kx limiting the performance though11:39
Melkhior@shorne Only one core I suppose ? (I think only VexRiscv has SMP support in Litex) ? Which frequency ?11:43
MelkhiorOn VexRiscv-SMP my one issue with ethernet is that interrupts are always handled by core 0:11:43
Melkhior(dolbeau)buildroot:~> cat /proc/interrupts11:43
Melkhior           CPU0       CPU1       CPU2       CPU311:43
Melkhior  2:     821252          0          0          0  SiFive PLIC   2  eth011:43
Melkhior  3:          3          0          0          0  SiFive PLIC   3  f0005000.ps2kbd11:43
MelkhiorBut it won't affect you if you have just one core.11:43
shorneI have just one core, I haven't setup SMP on litex yet11:44
shorneI guess you can get irq balancing by using the user space irqbalance daemon, https://linux.die.net/man/1/irqbalance11:46
tpbTitle: irqbalance(1) - Linux man page (at linux.die.net)11:46
shorneor you can se the affinity to move the irqs11:47
Melkhior@shorne Darn I forgot about irqbalance11:50
shorneecho 2 >/proc/irq/2/smp_affinity11:50
MelkhiorWill have to try that, thanks11:50
shorneto manually move11:50
MelkhiorIt's really about distributing rather than moving11:50
shorneyeah11:50
Melkhiorthough I could probably pin the userland processes to non-zero cores11:50
Melkhiornot as if I could compile with all 4 of them - not enough memory11:50
MelkhiorBTW, on my SoC reading from the sd-card seems much faster11:53
shorneMelkhior: 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
shorneoh yeah, me too11:54
Melkhiora ~ 2MiB file that was definitely not in memory reads in about 0.8s11:54
shornebut my numbers are ~500 kB/s writes,  ~750 kB/s reads11:55
shornenot sure about page cache, I think I was avoiding it11:55
Melkhiorsorry I wasn't clear - I don't have your patch yet11:56
Melkhiorbut the baseline pre-irq is already much faster than your baseline11:56
shornebefore the recent sd-card fixups both under 100 kB/s, and reads/writes were corrupt11:57
Melkhiori seem to be around 1.5-2 MiB/s for pure reading (cat'ing into /dev/null) large file11:57
Melkhioryes, I'm post-fixup, pre-irq11:57
shorneI understood that, those ~500/750 kB/s numbers I mentioned are the pre-irq numbers I was seeing to11:58
Melkhiorso if you see a lot lower than that, maybe you're CPU-bound/memory-bound somehow already ?11:58
MelkhiorOK11:58
shorneok, I am a bit off11:59
shornepre-irq:11:59
shorne ~ 618 kB/s write11:59
shorne ~ 775 kB/s read11:59
shorneirq:12:00
shorne ~ 541 kB/s write12:00
shorne ~ 790 kB/s read12:00
Melkhiori'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
shornethey are close, it might just be jitter12:00
Melkhiorcould be yes12:00
Melkhioranother hour, another conf call :-)12:01
shorneenjoy, Japan was on holidy today :)12:01
Melkhiorbye thanks will try irqbalance and see what it does to NFS12:01
shornetime for bed12:01
geertushorne: Enjoy Golden Week under lockdown ;-)12:11
*** Bertl_zZ is now known as Bertl12:28
*** rj has quit IRC13:22
*** RaivisR has joined #litex13:25
RaivisRgood 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 #litex13:59
gatecatRaivisR: ECP5 doesn't need any special primitive for differential inputs14:03
gatecatjust a regular one with a suitable IO standard14:03
RaivisRso as long as input standard is differential it will work14:04
gatecatyeah14:07
RaivisRthanks14:07
gatecat(e.g. LVDS)14:07
RaivisRthat´s what I have14:07
RaivisRstill trying to get litex run on ecp5_vip, but having trouble with external DDR314:08
RaivisRdo sys and sys2x for ecp5ddrpy have to be derived from the same external clock and have their phase in sync?14:12
gatecatyes, iirc sys should be divided down from sys2x14:12
gatecathttps://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/lattice_versa_ecp5.py#L68-L7314:13
RaivisRthat 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 them14:14
gatecatI'd recommend trying a lower clock frequency rather than multiple clock inputs14:16
RaivisRhow low DDR3 can go? I have no experience with that14:17
gatecat50MHz should be fine with the current LiteX setup14:19
RaivisRok, thanks, will keep learning and trying14:31
*** pauluzs has joined #litex14:40
*** pauluzs has quit IRC14:48
*** pauluzs has joined #litex14:51
*** pauluzs has joined #litex14:51
*** pauluzs has quit IRC15:21
acathlaI 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 #litex15:29
*** Bertl is now known as Bertl_oO15: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, ECPIX515: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 bus15:38
*** pftbest has quit IRC15:56
*** pftbest_ has joined #litex15:59
acathlaI'll make a simple target for the board...16:16
*** pftbest_ has quit IRC16:47
*** pftbest has joined #litex16:48
*** pftbest has quit IRC16:50
*** pftbest has joined #litex16:54
*** pftbest_ has joined #litex16:54
acathla_florent_, it works! I probably had a missing ASyncResetSynchroniser.16:58
acathlaCan I contribute to litex-boards? How can I add that Lattice board to the list?16:59
*** RaivisR has quit IRC17:33
*** pftbest_ has quit IRC17:35
geertuacathla: Fork the litex-boards repo, add support for your bord, and send a pull request17:39
geertus/bord/board/17:39
*** pftbest has joined #litex17: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
nickoenice18: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
nickoeIf 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
nickoeor, maybe I need to enable --with-sdram?18:26
nickoeWhat memory is used if not using --with-sdram?18:27
*** rj has quit IRC18:33
*** jhu has joined #litex18:39
jhuHi, 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
jhuif there18:40
nickoeI have not seen any, but I won't call my self an expert :D18:46
*** FFY00_ has quit IRC19:05
*** FFY00_ has joined #litex19:06
*** rj has joined #litex19:10
nickoeI think I got it added eventually, but .... hmmm19:21
nickoeI just don't understand all the signals in the fifo thing19:23
nickoeOk, so it appears to fill the fifo of the default 16 bytes in four "bursts"19:26
nickoeSo I got this code now https://github.com/nickoe/litex-boards/blob/6f4cccb34624e248ca9296ff02737b5af7b8ca89/litex_boards/targets/mars_ax3_sim_litex.py19:32
nickoewhen 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.txt19:39
nickoezyp: What does this do? https://gist.github.com/zyp/0b5e5f1ebcc7307d0bb5a5f8c738f9cf19:48
nickoeIs that USB implemented via some gateware and an interface to poke memory on the target?19:49
nickoeI wonder how to empty that fifo, should I wiggle a signal?19:55
zypnickoe, yeah, it's a usb-wishbone-bridge, except axi-lite instead of wishbone20:43
nickoezyp: ok.. not that I have really understood the differences between the different axi's20:44
zypthey are all memory buses20:45
nickoezyp: Do you happen to know anything about LiteDRAMDMAReader()?20:45
zypI've looked at it, but never used it20:45
nickoeIt appears to have a fifo, and it gets full, but I don't really see my data anywhere in the trace20:46
zypwhat are you trying to do?20:48
nickoeread 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
nickoeright now it looks like https://i.snipboard.io/shQSFG.jpg20:50
zypthe mydma_source_source_ready signal is stuck low20:53
zypthat's flow control for the dma data source20:54
zypyou see valid goes high, so it got data for you, but you're never accepting it20:54
nickoeso I need to pull up mydma_source_source_ready ?20:54
nickoeThis is my code https://github.com/nickoe/litex-boards/blob/6f4cccb34624e248ca9296ff02737b5af7b8ca89/litex_boards/targets/mars_ax3_sim_litex.py#L177-L26020:55
nickoebased on the stuff from bist.py20:55
nickoein litedram20:55
zypyeah, you'll want to do dma.source.ready.eq(1) somewhere20:55
zype.g. right next to dma.sink.valid.eq(1)20:55
nickoeok, now it certainly seem to run more!20:58
nickoebut I don't appear to get anything on  dma.source.data.eq(self.output_sig),21:01
zypthat's the wrong way around21:01
zypyou want self.output_sig.eq(dma.source.data)21:02
nickoemmm, right, but that does not appear to change the traces21:02
zyphow does your code look now?21:03
zypalso, how does the traces look now?21:03
nickoehttps://i.snipboard.io/CEryHB.jpg21:03
nickoezyp: I changed this, https://github.com/nickoe/litex-boards/commit/28a4816dae78f01e3c4217aef092e7a2570540e721:05
zyphow much memory do you have?21:08
nickoemmm21:08
nickoe                size                    = kwargs.get("max_sdram_size", 0x40000000),21:08
nickoe?21:08
zypnope21:09
nickoemm, where can I see it? It is a simulation.21:09
zypokay, you've got 64M21:10
zyphence why you've got a 26-bit address21:11
zypare you sure the DMA address makes sense?21:11
nickoeNo! I am new to this :D21:11
nickoeI use this command whe running21:12
nickoezyp: but the addres when read from the demo app works21:12
nickoesee https://dpaste.com/FM4W2A8SW.txt21:12
zypyeah, looks fine21:12
nickoeeven if I change the address from 0x41000000 to 0x40000000, the same address as the demo.bin I don't see anything on the output_sig21:13
nickoeDoes the address need to be offset?21:13
zypthe dma address is just the offset into the dram, not the whole 32-bit address21:14
nickoehttps://dpaste.com/7B9PUMEMA.txt21:14
zypbut since it's mapped at 0x40000000 it works out the same when the top six bits are stripped off by the assignment21:14
nickoeThere could very well be some signal that I may be missing or something I have forgot because I didn't know about it :S21:18
nickoeBut 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
nickoeanyway, my goal was to see my data in the trace, and then I can start to stuff that into some AXI stream or something21:20
zypit is already in a steram21:20
zypstream*21:20
zypyou're picking it out of a stream, doesn't make sense to do that just to stuff it back in :)21:21
zypand you don't have to think about axi streams, plain litex streams are pretty much the same21:22
nickoeBut I guess I must see some data here before I move on21:23
nickoeif just ...21:30
nickoe... I could realize how21:31
*** rj has quit IRC21:47
*** rj has joined #litex21:47
*** pftbest has quit IRC22:02
*** pftbest has joined #litex22:02
*** lf has quit IRC23:19
*** lf has joined #litex23:20

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