levi_ has quit [Read error: Connection reset by peer]
levi_ has joined #litex
bubble_buster has quit [Ping timeout: 240 seconds]
mithro has quit [Ping timeout: 240 seconds]
bubble_buster has joined #litex
<futarisIRCcloud>
Uggh... mixing buildroots between SMP litex and linux-on-litex-vexriscv can lead to a non booting system. Don't share the dl directory between them either...
CarlFK has quit [Read error: Connection reset by peer]
<somlo>
but still not working ok on 64bit even with that, so now I am trying turning off compiler optimizations, and updating my cross-compiler toolchain :) That'll take a while
<somlo>
because interleaved output from printf on a single-cpu (single thread of control) setup is just super freaky WEIRD... :)
<somlo>
apparently FatFs overheard me make fun of its redefined return types, and now hates me with a burning passion :D
xfxf has quit [Quit: Connection closed for inactivity]
<_florent_>
somlo: yes there are still probably a few things to figure out with the FatFs integration. Are you able to get it working with a 32-bit CPU? (Vexriscv for example?)
<_florent_>
somlo: i could do more test with Rocket on this but need to finish other work first
<somlo>
trouble is, I need to know *why* that works, and adding printf statements isn't working out for me so far :)
<somlo>
but sure, I'll build it for vexriscv as well, see what happens (once I finish rebuilding the toolchain, so later tonight/tomorrow)
<_florent_>
somlo: ok thanks, i'll also have a look unless you figure it out.
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 256 seconds]
kgugala has joined #litex
kgugala__ has joined #litex
kgugala_ has quit [Read error: Connection reset by peer]
kgugala has quit [Ping timeout: 258 seconds]
HoloIRCUser has joined #litex
HoloIRCUser1 has quit [Read error: Connection reset by peer]
Skip has joined #litex
HoloIRCUser1 has joined #litex
HoloIRCUser has quit [Read error: Connection reset by peer]
smd has joined #litex
<smd>
Hi all, I got myself acorn 215 after seeing enjoy-digital's tweet and it seems I'm having some issues with running litex on it. They're similar to ones @dkozel had according to https://freenode.irclog.whitequark.org/litex/2020-03-27so I was able to build the bitstream with "./acorn_cle_215.py --build" and hopefuly load the bitstream to fpga with
<smd>
"./acorn_cle_215.py --load", but wasn't able to flash it though.Then I tried to compile kernel module(I'm on 5.4.41-1-pve kernel) and got bunch of errors @dkozel had. So I added missing includes(linux/poll.h and linux/cdev.h) and built the module and loaded it.But unfortunately for some reason nothing happened then: no new pci-e device was found,
<smd>
while I'm able to see my acorn 215 with lspci command.
<tpb>
Title: #litex on 2020-06-12 — irc logs at whitequark.org (at freenode.irclog.whitequark.org)
futarisIRCcloud has joined #litex
<zyp>
smd, what dows lspci say?
<smd>
@zyp thanks, that was the issue, I guess: had to reboot to re-enumerate pci-e devices and then litex soc appeared. So is there an easier way to reenumerate the devices than reboot?
<zyp>
yes
<zyp>
echo 1 > /sys/bus/pci/devices/…/remove
<zyp>
echo 1 > /sys/bus/pci/rescan
<zyp>
I do the first before loading the new bitstream and the second after
<smd>
Thanks!
st-gourichon-fid has quit [Ping timeout: 272 seconds]
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
<dkozel>
Hi smd I'll be doing a bunch of work on this over the weekend.
<_florent_>
somlo: thanks for sharing, i'll watch it this weekend
Skip has quit [Remote host closed the connection]
smd has quit [Remote host closed the connection]
smd has joined #litex
<smd>
@dkozel you mean litex + sqrl 215?
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 246 seconds]
<zyp>
somlo, how's that stuff going?
<somlo>
zyp: if you have lots of patience, you can actually get yosys and nextpnr to load and print out stuff to the console :)
<zyp>
on what?
<somlo>
on the trellisboard (ecp5-85k) (scroll to the end of http://www.contrib.andrew.cmu.edu/~somlo/BTCP/ for the video, there's also a link to the terminal log if you don't feel like waiting :)
<tpb>
Title: A Trustworthy, Free (Libre), Linux Capable, Self-Hosting 64bit RISC-V Computer (at www.contrib.andrew.cmu.edu)
<somlo>
you can do it on the nexys4ddr as well, but that's not "in the spirit" -- i.e. you need vivado to get the nexys4ddr bitstream, so no bonus points for being able to run some *other* toolchain :)
<zyp>
I'm still working on my ecp5+sodimm board, but I keep getting sidetracked by other stuff
<somlo>
zyp: oh, tell me about it... $DAYJOB gets in the way big time on my end as well :)
<zyp>
current state of it is this: https://bin.jvnv.net/file/tAJNw.png, what's still missing are power supplies and some signal routing, then cleanup and length matching of the ddr3 signals
<somlo>
That looks cool -- what ports do you have on the left? two ethernets and a usb? I'm not familiar enough with them to guess by just eyeballing :)
<zyp>
three usbs :)
<somlo>
oh, two As and a C?
<zyp>
no, all C, but the top one is usb2 only
<somlo>
aha
<somlo>
any PMODs (where one could hook up ethernet, microSD, etc)?
<zyp>
the one above the usb2 connector is microsd
<somlo>
ok, so all that's still tbd is ethernet (maybe via pmod)?
<somlo>
in theory there *are* ethernet usb dongles, but that'd probably burn off lots of FPGA capacity, if I were to hazard a guess (much more than just straight-up ethernet)
<zyp>
there's an unconnected 30-pin connector below the fpga, I'm planning to route all spare IO there, where it can be used for more IO with a board stacked above the usb-c connectors
<zyp>
I'm planning to start off by making a PMOD adapter for that
<somlo>
cool, hope you get the peace and quiet to work on it :)
<zyp>
for ethernet I've considered running SGMII over the backplane
<zyp>
but that's for somewhere in the distant future, first I want this board to work standalone :)
<tpearson-mobile>
Trying to use LiteX for the first time on an ECP5 Versa board. I've used the Versa on this system with openocd before without problems, but trying openocd with the .svf from LiteX gives an error
<tpearson-mobile>
Error: tdo check error at line 11Error: READ = 0x44810c01Error: WANT = 0x81112043
<daveshah>
Is it a Versa or Versa 5G
<tpearson-mobile>
Let me double check
<tpearson-mobile>
It should be the standard Versa, "LFE5UM-45F-VERSA-EVN"
<awordnot>
cool! let me know if there's any way I could contribute to the LiteX porting efforts. I just started out with LiteX but I'm starting to get the hang of things
<tpearson-mobile>
I think you're part of the Kestrel group, right?
<tpearson-mobile>
a lot of our active development is / will be taking place there
<awordnot>
I don't think so. Though I remember you mentioning something about it a while ago on #t-w
<tpearson-mobile>
ah, OK
<tpearson-mobile>
well...I think the biggest problem we have at the moment is the Microwatt core causing some kind of odd resource usage problem due to faulty RAM inference
<awordnot>
sure. You should be able to cross reference that openocd_versa_ecp5.cfg file I linked with your known-working openocd config to find the issue
<tpearson-mobile>
yep -- we've actually done some internal projects on the Versa over time using the open toolchain on our POWER boxes, this is just the first time with LiteX
<tpearson-mobile>
...which, so far, isn't having any problems running on POWER
<awordnot>
nice! I'm still waiting for my OrangeCrab ECP5 dev board to come, so I've been stuck with my Xilinx dev boards which require x86 :/
<tpearson-mobile>
ow. that's painful.
<tpearson-mobile>
even on POWER the synthesis of a large LiteX design takes a while
<tpearson-mobile>
long enough that I'm seriously considering moving it to one of the larger servers
<awordnot>
where does the bulk of the time end up being spent? In synthesis or pnr?
<tpearson-mobile>
PNR, actually
<tpearson-mobile>
sorry, was being a bit handwavy there
<awordnot>
lol no worries
<awordnot>
makes sense that pnr would take a while. Not sure how much it would benefit from a machine with more cores though
<tpearson-mobile>
"the magic stuff cranking from HDL to bitstream" == synthesis when not being precise ;)
<tpearson-mobile>
it's supposed to be parallelizable
<tpearson-mobile>
which makes sense, it's running an annealing algorithm
<awordnot>
interesting
<daveshah>
most of the time is routing which isn't annealing but is still quite easy to parallelise
<tpearson-mobile>
yeah, could be
<daveshah>
it's just not quite there yet
<tpearson-mobile>
gotcha
<daveshah>
the main part of the placer hasn't been annealing based for over a year now, but analytical and already parallelised to some extent
<tpearson-mobile>
well, have a vote (and virtual beer) from me for paralleling that least part someday :)
<tpearson-mobile>
*parallelizing
<tpearson-mobile>
interesting you mention ~ 1 year, since we've been running Arachne (and NextPNR) from around that vintage until very recently
<tpearson-mobile>
might explain my impressions of it thus far
<tpearson-mobile>
anyway, if I remember correctly most of the PAR stage can be parallelized, it's synthesis that doesn't really have a way to do that?
tpearson-mobile has quit [Remote host closed the connection]
smd has quit [Remote host closed the connection]
<daveshah>
synthesis can be parallelised by building modules in separate threads, although this misses cross-boundary optimisations
<daveshah>
one option is a hybrid, to build modules separately and then do "LTO" after flattening them
<awordnot>
daveshah: that's what Xilinx calls "Hierarchical Elaboration" right?
<awordnot>
or is that something else
st-gourichon-fid has quit [Ping timeout: 264 seconds]
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 256 seconds]
Skip has joined #litex
<dkozel>
smd: Yes. Doing some packaging and documentation for litepcie's kernel module and userspace driver. Adding an example CMake project and C++ app.
<awordnot>
I wonder why litepcie even needs its own kernel driver tbh. It looks like all its doing is exposing BARs/MSIs to userspace which can be accomplished by just using VFIO
<awordnot>
unless I'm missing something
<zyp>
I was wondering about the same the other day, it'd be neat to avoid that need
<awordnot>
I guess one benefit is being able to safely map DMA bufs without an IOMMU, but that seems like it'd be outweighed by the benefits of just using VFIO
<awordnot>
maybe I'll try writing a PoC userspace driver