<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
<shorne>
I guess the soc.py is missing something like self.irq.add(name, use_loc_if_exists=True)
<shorne>
ok, I can confirm in my output digilent_arty.v, the sdirq_irq wire is dangling and not connected to anything
<shorne>
it looks like magically adding the "self.irq.add(name, use_loc_if_exists=True)" works
<shorne>
maybe not
kgugala_ has quit [Read error: Connection reset by peer]
kgugala has joined #litex
<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.
<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?
<shorne>
ok, I think I got it working, I will send a patch maybe its wrong
<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
<somlo>
s/was/is/ :)
<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 :-)
<Melkhior>
(Litex was able so self-host both Perl and Python to install from/to NFS and the toolchain/swap on the micro-sd)
<shorne>
Melkhior: I wanted sd support for swap too. Its running now and seems to be working fine (with the interrupt code).
<Melkhior>
Excellent thanks :-)
<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
<Melkhior>
@shorne Only one core I suppose ? (I think only VexRiscv has SMP support in Litex) ? Which frequency ?
<Melkhior>
On VexRiscv-SMP my one issue with ethernet is that interrupts are always handled by core 0:
<tpb>
Title: irqbalance(1) - Linux man page (at linux.die.net)
<shorne>
or you can se the affinity to move the irqs
<Melkhior>
@shorne Darn I forgot about irqbalance
<shorne>
echo 2 >/proc/irq/2/smp_affinity
<Melkhior>
Will have to try that, thanks
<shorne>
to manually move
<Melkhior>
It's really about distributing rather than moving
<shorne>
yeah
<Melkhior>
though I could probably pin the userland processes to non-zero cores
<Melkhior>
not as if I could compile with all 4 of them - not enough memory
<Melkhior>
BTW, on my SoC reading from the sd-card seems much faster
<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.
<shorne>
oh yeah, me too
<Melkhior>
a ~ 2MiB file that was definitely not in memory reads in about 0.8s
<shorne>
but my numbers are ~500 kB/s writes, ~750 kB/s reads
<shorne>
not sure about page cache, I think I was avoiding it
<Melkhior>
sorry I wasn't clear - I don't have your patch yet
<Melkhior>
but the baseline pre-irq is already much faster than your baseline
<shorne>
before the recent sd-card fixups both under 100 kB/s, and reads/writes were corrupt
<Melkhior>
i seem to be around 1.5-2 MiB/s for pure reading (cat'ing into /dev/null) large file
<Melkhior>
yes, I'm post-fixup, pre-irq
<shorne>
I understood that, those ~500/750 kB/s numbers I mentioned are the pre-irq numbers I was seeing to
<Melkhior>
so if you see a lot lower than that, maybe you're CPU-bound/memory-bound somehow already ?
<Melkhior>
OK
<shorne>
ok, I am a bit off
<shorne>
pre-irq:
<shorne>
~ 618 kB/s write
<shorne>
~ 775 kB/s read
<shorne>
irq:
<shorne>
~ 541 kB/s write
<shorne>
~ 790 kB/s read
<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:-( )
<shorne>
they are close, it might just be jitter
<Melkhior>
could be yes
<Melkhior>
another hour, another conf call :-)
<shorne>
enjoy, Japan was on holidy today :)
<Melkhior>
bye thanks will try irqbalance and see what it does to NFS
<shorne>
time for bed
<geertu>
shorne: Enjoy Golden Week under lockdown ;-)
Bertl_zZ is now known as Bertl
rj has quit [Ping timeout: 240 seconds]
RaivisR has joined #litex
<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?
rj has joined #litex
<gatecat>
RaivisR: ECP5 doesn't need any special primitive for differential inputs
<gatecat>
just a regular one with a suitable IO standard
<RaivisR>
so as long as input standard is differential it will work
<gatecat>
yeah
<RaivisR>
thanks
<gatecat>
(e.g. LVDS)
<RaivisR>
that´s what I have
<RaivisR>
still trying to get litex run on ecp5_vip, but having trouble with external DDR3
<RaivisR>
do sys and sys2x for ecp5ddrpy have to be derived from the same external clock and have their phase in sync?
<gatecat>
yes, iirc sys should be divided down from sys2x
<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
<gatecat>
I'd recommend trying a lower clock frequency rather than multiple clock inputs
<RaivisR>
how low DDR3 can go? I have no experience with that
<gatecat>
50MHz should be fine with the current LiteX setup
<RaivisR>
ok, thanks, will keep learning and trying
pauluzs has joined #litex
pauluzs has quit [Quit: Connection closed]
pauluzs has joined #litex
pauluzs has quit [Client Quit]
pauluzs has joined #litex
pauluzs has quit [Quit: Leaving.]
<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?
pauluzs has joined #litex
Bertl is now known as Bertl_oO
<_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
<_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
pftbest has quit [Remote host closed the connection]
pftbest_ has joined #litex
<acathla>
I'll make a simple target for the board...
pftbest_ has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest_ has joined #litex
<acathla>
_florent_, it works! I probably had a missing ASyncResetSynchroniser.
<acathla>
Can I contribute to litex-boards? How can I add that Lattice board to the list?
RaivisR has quit [Ping timeout: 260 seconds]
pftbest_ has quit [Remote host closed the connection]
<geertu>
acathla: Fork the litex-boards repo, add support for your bord, and send a pull request
<_florent_>
it just lacks a SDCard, but adding one should be possible on the HDMI/SBUS connector...
<nickoe>
nice
<nickoe>
_florent_: How do I get the "port" to the ram, for use with LiteDRAMDMAReader()?
<geertu>
_florent_: Cool! Thanks to litescope, you no longer need a real scope, so found a new use for it? ;^)
<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",....
<nickoe>
or, maybe I need to enable --with-sdram?
<nickoe>
What memory is used if not using --with-sdram?
rj has quit [Ping timeout: 240 seconds]
jhu has joined #litex
<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?
<jhu>
if there
<nickoe>
I have not seen any, but I won't call my self an expert :D
FFY00_ has quit [Ping timeout: 250 seconds]
FFY00_ has joined #litex
rj has joined #litex
<nickoe>
I think I got it added eventually, but .... hmmm
<nickoe>
I just don't understand all the signals in the fifo thing
<nickoe>
Ok, so it appears to fill the fifo of the default 16 bytes in four "bursts"