| *** tpb has joined #litex | 00:00 | |
| *** levi_ has quit IRC | 01:09 | |
| *** levi_ has joined #litex | 01:10 | |
| *** bubble_buster has quit IRC | 01:13 | |
| *** mithro has quit IRC | 01:14 | |
| *** bubble_buster has joined #litex | 01:23 | |
| 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... | 01:23 |
|---|---|---|
| *** mithro has joined #litex | 01:24 | |
| *** captain_morgan has quit IRC | 01:50 | |
| *** captain_morgan has joined #litex | 01:52 | |
| *** captain_morgan has quit IRC | 01:53 | |
| *** captain_morgan has joined #litex | 01:54 | |
| *** Degi has quit IRC | 02:29 | |
| *** Degi_ has joined #litex | 02:29 | |
| *** Degi_ is now known as Degi | 02:29 | |
| *** HoloIRCUser1 has joined #litex | 02:35 | |
| *** HoloIRCUser has quit IRC | 02:35 | |
| *** levi_ is now known as levi | 03:20 | |
| *** Skip has quit IRC | 04:36 | |
| *** futarisIRCcloud has quit IRC | 05:17 | |
| *** _whitelogger has quit IRC | 05:33 | |
| *** _whitelogger has joined #litex | 05:35 | |
| *** futarisIRCcloud has joined #litex | 05:41 | |
| *** kgugala has quit IRC | 05:49 | |
| *** kgugala has joined #litex | 05:49 | |
| *** kgugala_ has joined #litex | 05:51 | |
| *** kgugala has quit IRC | 05:53 | |
| *** kgugala has joined #litex | 06:37 | |
| *** kgugala_ has quit IRC | 06:39 | |
| *** smd has joined #litex | 07:06 | |
| *** smd has quit IRC | 07:30 | |
| *** st-gourichon-fid has quit IRC | 07:36 | |
| *** st-gourichon-fid has joined #litex | 07:43 | |
| *** smd has joined #litex | 07:48 | |
| *** smd has quit IRC | 08:12 | |
| *** HoloIRCUser has joined #litex | 08:49 | |
| *** HoloIRCUser1 has quit IRC | 08:49 | |
| _florent_ | New wiki page explaining the different options to load application code to the CPU and the simplifications in netboot/sdcardboot (now using a boot.json file): https://github.com/enjoy-digital/litex/wiki/Load-Application-Code-To-CPU | 09:22 |
| tpb | Title: Load Application Code To CPU · enjoy-digital/litex Wiki · GitHub (at github.com) | 09:22 |
| *** acathla has quit IRC | 10:17 | |
| *** acathla has joined #litex | 10:26 | |
| *** futarisIRCcloud has quit IRC | 10:37 | |
| *** HoloIRCUser1 has joined #litex | 10:55 | |
| *** HoloIRCUser has quit IRC | 10:55 | |
| somlo | _florent_: at one point I *thought* this should have been `volatile`: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/liblitesdcard/spisdcard.c#L271 | 11:49 |
| tpb | Title: litex/spisdcard.c at master · enjoy-digital/litex · GitHub (at github.com) | 11:49 |
| *** CarlFK has quit IRC | 11:50 | |
| 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 | 11:50 |
| somlo | because interleaved output from printf on a single-cpu (single thread of control) setup is just super freaky WEIRD... :) | 11:51 |
| somlo | apparently FatFs overheard me make fun of its redefined return types, and now hates me with a burning passion :D | 11:52 |
| *** xfxf has quit IRC | 12:00 | |
| _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?) | 12:04 |
| _florent_ | somlo: i could do more test with Rocket on this but need to finish other work first | 12:05 |
| somlo | _florent_: I got it working with 64bit by hardcoding a `return 0;` here: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/liblitesdcard/spisdcard.c#L273 | 12:17 |
| tpb | Title: litex/spisdcard.c at master · enjoy-digital/litex · GitHub (at github.com) | 12:17 |
| somlo | trouble is, I need to know *why* that works, and adding printf statements isn't working out for me so far :) | 12:17 |
| somlo | but sure, I'll build it for vexriscv as well, see what happens (once I finish rebuilding the toolchain, so later tonight/tomorrow) | 12:19 |
| _florent_ | somlo: ok thanks, i'll also have a look unless you figure it out. | 12:23 |
| *** kgugala_ has joined #litex | 12:27 | |
| *** kgugala has quit IRC | 12:29 | |
| *** kgugala has joined #litex | 12:36 | |
| *** kgugala__ has joined #litex | 12:37 | |
| *** kgugala_ has quit IRC | 12:37 | |
| *** kgugala has quit IRC | 12:40 | |
| *** HoloIRCUser has joined #litex | 12:57 | |
| *** HoloIRCUser1 has quit IRC | 12:57 | |
| *** Skip has joined #litex | 13:38 | |
| *** HoloIRCUser1 has joined #litex | 13:55 | |
| *** HoloIRCUser has quit IRC | 13:55 | |
| *** smd has joined #litex | 14:28 | |
| 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 | 14:34 |
| 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, | 14:34 |
| smd | while I'm able to see my acorn 215 with lspci command. | 14:34 |
| tpb | Title: #litex on 2020-06-12 — irc logs at whitequark.org (at freenode.irclog.whitequark.org) | 14:34 |
| *** futarisIRCcloud has joined #litex | 14:41 | |
| zyp | smd, what dows lspci say? | 14:43 |
| 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? | 14:51 |
| zyp | yes | 15:03 |
| zyp | echo 1 > /sys/bus/pci/devices/…/remove | 15:04 |
| zyp | echo 1 > /sys/bus/pci/rescan | 15:04 |
| zyp | I do the first before loading the new bitstream and the second after | 15:06 |
| smd | Thanks! | 15:13 |
| *** st-gourichon-fid has quit IRC | 15:16 | |
| *** st-gourichon-fid has joined #litex | 15:25 | |
| *** kgugala__ has quit IRC | 15:28 | |
| *** kgugala has joined #litex | 15:33 | |
| *** HoloIRCUser1 has quit IRC | 15:46 | |
| somlo | apparently I've been working on "supply chain security" :) https://youtu.be/5IhujGl_-K0 | 15:54 |
| *** kgugala has quit IRC | 16:15 | |
| *** kgugala has joined #litex | 16:16 | |
| dkozel | Hi smd I'll be doing a bunch of work on this over the weekend. | 16:47 |
| _florent_ | somlo: thanks for sharing, i'll watch it this weekend | 16:50 |
| *** Skip has quit IRC | 17:17 | |
| *** smd has quit IRC | 17:21 | |
| *** smd has joined #litex | 17:28 | |
| smd | @dkozel you mean litex + sqrl 215? | 17:29 |
| *** kgugala_ has joined #litex | 17:37 | |
| *** kgugala has quit IRC | 17:39 | |
| zyp | somlo, how's that stuff going? | 18:28 |
| somlo | zyp: if you have lots of patience, you can actually get yosys and nextpnr to load and print out stuff to the console :) | 18:32 |
| zyp | on what? | 18:32 |
| 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 :) | 18:34 |
| tpb | Title: A Trustworthy, Free (Libre), Linux Capable, Self-Hosting 64bit RISC-V Computer (at www.contrib.andrew.cmu.edu) | 18:34 |
| 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 :) | 18:35 |
| zyp | I'm still working on my ecp5+sodimm board, but I keep getting sidetracked by other stuff | 18:36 |
| somlo | zyp: oh, tell me about it... $DAYJOB gets in the way big time on my end as well :) | 18:37 |
| 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 | 18:40 |
| 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 :) | 18:43 |
| zyp | three usbs :) | 18:43 |
| somlo | oh, two As and a C? | 18:44 |
| zyp | no, all C, but the top one is usb2 only | 18:44 |
| somlo | aha | 18:44 |
| somlo | any PMODs (where one could hook up ethernet, microSD, etc)? | 18:45 |
| zyp | the one above the usb2 connector is microsd | 18:45 |
| somlo | ok, so all that's still tbd is ethernet (maybe via pmod)? | 18:46 |
| 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) | 18:47 |
| 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 | 18:47 |
| zyp | I'm planning to start off by making a PMOD adapter for that | 18:47 |
| somlo | cool, hope you get the peace and quiet to work on it :) | 18:48 |
| zyp | https://bin.jvnv.net/file/1lgyF.png <- I'm designing this thing to fit in a subrack enclosure with a custom backplane | 18:49 |
| *** tpearson-mobile has joined #litex | 18:49 | |
| zyp | for ethernet I've considered running SGMII over the backplane | 18:49 |
| zyp | but that's for somewhere in the distant future, first I want this board to work standalone :) | 18:50 |
| 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 | 18:50 |
| tpearson-mobile | Error: tdo check error at line 11Error: READ = 0x44810c01Error: WANT = 0x81112043 | 18:50 |
| daveshah | Is it a Versa or Versa 5G | 18:50 |
| tpearson-mobile | Let me double check | 18:50 |
| tpearson-mobile | It should be the standard Versa, "LFE5UM-45F-VERSA-EVN" | 18:51 |
| daveshah | also check the jumper as mentioned here: https://github.com/SymbiFlow/prjtrellis/tree/master/examples/versa5g | 18:51 |
| tpb | Title: prjtrellis/examples/versa5g at master · SymbiFlow/prjtrellis · GitHub (at github.com) | 18:51 |
| daveshah | if it is a standard versa you will need to change the device in the LiteX file | 18:52 |
| tpearson-mobile | Ah, OK...the .py file used to build? | 18:52 |
| daveshah | yeah, I can't remember the best place to change it, it might even be an option somewhere now | 18:53 |
| awordnot | oh hey tpearson-mobile | 18:53 |
| awordnot | this is probably what you're looking for: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/prog/openocd_versa_ecp5.cfg | 18:53 |
| tpb | Title: litex-boards/openocd_versa_ecp5.cfg at master · litex-hub/litex-boards · GitHub (at github.com) | 18:53 |
| tpearson-mobile | awordnot: hey! small world | 18:53 |
| awordnot | and https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/versa_ecp5.py#L228 | 18:53 |
| tpb | Title: litex-boards/versa_ecp5.py at master · litex-hub/litex-boards · GitHub (at github.com) | 18:53 |
| awordnot | yep :D | 18:53 |
| tpearson-mobile | awordnot: you might like some of the stuff in https://gitlab.raptorengineering.com/raptor-engineering-public/lpc-spi-bridge-fpga | 18:53 |
| tpb | Title: Raptor Engineering Public Development / lpc-spi-bridge-fpga · GitLab (at gitlab.raptorengineering.com) | 18:53 |
| tpearson-mobile | you can IPL an entire POWER system without a BMC with that logic....though sadly it's a bit too large for the iCE40 now | 18:54 |
| tpearson-mobile | working on getting those cores into LiteX, hence why I'm here :) | 18:54 |
| awordnot | tpearson-mobile: wow awesome. what about FSI? I guess you could use the kernel bitbanging driver | 18:54 |
| tpearson-mobile | There's a real OpenFSI core in there too | 18:55 |
| tpearson-mobile | master / slave | 18:55 |
| awordnot | awesome! | 18:55 |
| tpearson-mobile | https://twitter.com/RaptorEng/status/1269571842475536389?s=20 / https://twitter.com/RaptorEng/status/1270489397784387587?s=20 FWIW | 18:55 |
| 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 | 18:56 |
| tpearson-mobile | I think you're part of the Kestrel group, right? | 18:56 |
| tpearson-mobile | a lot of our active development is / will be taking place there | 18:57 |
| awordnot | I don't think so. Though I remember you mentioning something about it a while ago on #t-w | 18:57 |
| tpearson-mobile | ah, OK | 18:57 |
| 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 | 18:57 |
| tpearson-mobile | https://github.com/enjoy-digital/litex/issues/245#issuecomment-643392928 | 18:58 |
| tpb | Title: Import the microwatt PowerPC core · Issue #245 · enjoy-digital/litex · GitHub (at github.com) | 18:58 |
| *** tcal has joined #litex | 18:58 | |
| tpearson-mobile | that and so far as I know Linux support still needs to be merged in from upstream Microwatt (MMU / supervisor mode) | 18:58 |
| tpearson-mobile | no idea if either one of those tasks is of interest? :) | 18:59 |
| awordnot | not sure if I could do much about that yosys BRAM inference bug, but I could take a look at the Linux stuff | 18:59 |
| tpearson-mobile | sure | 18:59 |
| tpearson-mobile | My current plan is to hack in a *16K RAM primitive to just bypass the problem | 19:00 |
| tpearson-mobile | since the dev board and our final target system are both ECP5 it's reasonable enough to do | 19:00 |
| awordnot | yeah seems reasonable. Do you have LiteDRAM working? | 19:00 |
| tpearson-mobile | so far as I know it works, but I need to fix this programming bug before I can verifyu | 19:00 |
| tpearson-mobile | s/programming bug/config file setting/ | 19:01 |
| 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 | 19:01 |
| 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 | 19:02 |
| tpearson-mobile | ...which, so far, isn't having any problems running on POWER | 19:02 |
| 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 :/ | 19:02 |
| tpearson-mobile | ow. that's painful. | 19:03 |
| tpearson-mobile | even on POWER the synthesis of a large LiteX design takes a while | 19:03 |
| tpearson-mobile | long enough that I'm seriously considering moving it to one of the larger servers | 19:03 |
| awordnot | where does the bulk of the time end up being spent? In synthesis or pnr? | 19:04 |
| tpearson-mobile | PNR, actually | 19:04 |
| tpearson-mobile | sorry, was being a bit handwavy there | 19:04 |
| awordnot | lol no worries | 19:04 |
| awordnot | makes sense that pnr would take a while. Not sure how much it would benefit from a machine with more cores though | 19:04 |
| tpearson-mobile | "the magic stuff cranking from HDL to bitstream" == synthesis when not being precise ;) | 19:04 |
| tpearson-mobile | it's supposed to be parallelizable | 19:05 |
| tpearson-mobile | which makes sense, it's running an annealing algorithm | 19:05 |
| awordnot | interesting | 19:05 |
| daveshah | most of the time is routing which isn't annealing but is still quite easy to parallelise | 19:05 |
| tpearson-mobile | yeah, could be | 19:05 |
| daveshah | it's just not quite there yet | 19:05 |
| tpearson-mobile | gotcha | 19:05 |
| 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 | 19:06 |
| tpearson-mobile | well, have a vote (and virtual beer) from me for paralleling that least part someday :) | 19:06 |
| tpearson-mobile | *parallelizing | 19:06 |
| tpearson-mobile | interesting you mention ~ 1 year, since we've been running Arachne (and NextPNR) from around that vintage until very recently | 19:06 |
| tpearson-mobile | might explain my impressions of it thus far | 19:07 |
| 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? | 19:07 |
| *** tpearson-mobile has quit IRC | 19:10 | |
| *** smd has quit IRC | 19:20 | |
| daveshah | synthesis can be parallelised by building modules in separate threads, although this misses cross-boundary optimisations | 19:21 |
| daveshah | one option is a hybrid, to build modules separately and then do "LTO" after flattening them | 19:21 |
| awordnot | daveshah: that's what Xilinx calls "Hierarchical Elaboration" right? | 19:28 |
| awordnot | or is that something else | 19:28 |
| *** st-gourichon-fid has quit IRC | 20:02 | |
| *** kgugala has joined #litex | 20:30 | |
| *** kgugala_ has quit IRC | 20:33 | |
| *** Skip has joined #litex | 20:37 | |
| dkozel | smd: Yes. Doing some packaging and documentation for litepcie's kernel module and userspace driver. Adding an example CMake project and C++ app. | 21:01 |
| 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 | 21:21 |
| awordnot | unless I'm missing something | 21:22 |
| zyp | I was wondering about the same the other day, it'd be neat to avoid that need | 21:32 |
| 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 | 21:34 |
| awordnot | maybe I'll try writing a PoC userspace driver | 21:34 |
| *** sconklin has joined #litex | 21:42 | |
| *** dasdgw has joined #litex | 22:05 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
