*** tpb has joined #litex | 00:00 | |
*** oter has joined #litex | 00:42 | |
*** oter_ has joined #litex | 00:42 | |
oter_ | I'm trying to read the main_ram region from custom logic - Q: is the best way to do that by getting the wb slave signals from `soc.bus.slaves.get('main_ram')` and drive those, or should I use some other way to access the ram's wb slave? I'm worried that I need to do `crossbar.get_port(...)` on the ram (or cache) directly to avoid contention and that would be a little daunting ... Could find an example to template off of, unfortunately. Q: | 01:09 |
---|---|---|
oter_ | any pointers to example of direct L2 cache, or main_ram access from custom logic? | 01:09 |
CarlFK | bunnie: p4 boots fine until I plug an netv2, then this: https://matrix.org/_matrix/media/r0/download/matrix.org/pwdjcZallCIAMlpgDQAwPGhn | 01:36 |
CarlFK | but it was working a day ago.. maybe because I switched to ubuntu, but im not sure it has booted that yet | 01:36 |
CarlFK | huh. boot pi, then plug in netv2, pi is fine. | 01:43 |
CarlFK | swell. boots debian fine, ubuntu.. wonky hardly gets out the door | 02:29 |
*** Degi has quit IRC | 03:16 | |
*** Degi has joined #litex | 03:17 | |
*** CarlFK has quit IRC | 04:47 | |
*** CarlFK has joined #litex | 04:51 | |
*** _whitelogger has quit IRC | 05:45 | |
*** peeps has quit IRC | 05:47 | |
*** _whitelogger has joined #litex | 05:47 | |
*** peepsalot has joined #litex | 05:58 | |
*** proteusguy has quit IRC | 06:12 | |
*** proteusguy has joined #litex | 06:24 | |
zyp | oter_, what are you trying to achieve? | 06:44 |
oter_ | Hi zyp, I have a module that reads/writes to UDP packets (based on LiteEthTTYRX/TX, not via CPU) and would like to access the DDR3 RAM on my versa_ecp5 board (again, not via code on the CPU). Ideally reading/writing 32 bit RAM values. Love that I can peek and poke via the wishbone-tool and use the LiteScope for debugging; but for the main task, I'm mostly trying to build a eth-connected accelerator and use the Lite* parts w/o code on the | 07:07 |
oter_ | CPU (i.e. I love the UDP stack in HW!). | 07:07 |
oter_ | zyp, some of my access patterns are random access and for others I might be able to use the litedram DMA frontend. | 07:08 |
oter_ | Had great fun and learnt a lot following and adapting examples and diving deep using the LiteScope - ergo trying the same for main_ram access now. | 07:09 |
zyp | ah, for litedram I believe you should be able to add another port that you can access | 07:12 |
_florent_ | oter_: for what you are trying to achieve you have two possibilities: 1) connect a module as a Wishbone master to the main bus of the SoC and make your UDP module do wishbone access to the main ram | 07:16 |
_florent_ | 2) request a specific port to the DRAM controller with crossbar.get_port(...) | 07:16 |
_florent_ | If you are familiar with Wishbone, 1) should not be too complicated but for high perf it will not work since wishbone is slow and the main bus will be shared with the others peripherals | 07:17 |
zyp | if you want wishbone, can't you just use LiteDRAMWishbone2Native with option 2? | 07:18 |
_florent_ | for 2) once you request your port, you can create a DMA around it | 07:19 |
oter_ | OK, got it. Thanks to both of you! _florent_, I'll probably try (2) with the DMA frontend and fall back to (1) if I get stuck and learn as I go. Btw. great platform, so much fun to learn! | 07:19 |
_florent_ | with: https://github.com/enjoy-digital/litedram/blob/master/litedram/frontend/dma.py#L19 | 07:19 |
tpb | Title: litedram/dma.py at master · enjoy-digital/litedram · GitHub (at github.com) | 07:19 |
_florent_ | or https://github.com/enjoy-digital/litedram/blob/master/litedram/frontend/dma.py#L147 | 07:19 |
tpb | Title: litedram/dma.py at master · enjoy-digital/litedram · GitHub (at github.com) | 07:19 |
oter_ | tpd _lorent_ do I need to reach inside the DMA reader/write to poke into the _base/_length and _start signals (wrapped with the CSRs for the CPU/wb access) to setup the copying into/from the FIFOs? If so, I guess, I can just reach inside those CSR .output signals? | 07:22 |
_florent_ | zyp: you can use LiteDRAMWishbone2Native too, but for low perf, it's easier to just connect to the main bus of the SoC | 07:22 |
*** pdp7 has quit IRC | 07:24 | |
zyp | yeah, I just figured if you have a wishbone master, it'd give you a bit extra performance without a lot of extra work | 07:25 |
_florent_ | oter_: the DMA can be operated in 2 modes: without CSR, the user provide the address/data stream from the logic, with CSR the address stream is programmed by the CPU and automatically generated, the user logic only handles the data stream | 07:25 |
*** guan has quit IRC | 07:26 | |
*** pdp7 has joined #litex | 07:27 | |
*** guan has joined #litex | 07:28 | |
oter_ | _florent_ I see. For the "without CSR" mode, I'll just not call the add_csr and then drive it all via the sink of the reader (address record) or writer (address/data record), respectively, correct? | 07:30 |
_florent_ | oter_: exactly | 07:31 |
oter_ | awesome! I'll try that tomorrow (time for bed for me, here on the US West coast). This navigation help is gold! Thanks a ton | 07:32 |
_florent_ | oter_: if you need examples, you can probably look at frontend/fifo that is using both writer and reader: https://github.com/enjoy-digital/litedram/blob/master/litedram/frontend/fifo.py | 07:32 |
tpb | Title: litedram/fifo.py at master · enjoy-digital/litedram · GitHub (at github.com) | 07:32 |
oter_ | roger that _florent_ and tpb! | 07:33 |
sajattack[m] | tpb is a bot | 07:34 |
oter_ | oh :-) | 07:34 |
*** futarisIRCcloud has quit IRC | 07:48 | |
xobs | Hey, is anyone around to help me troubleshoot a Conda install? I'm trying to get the Valentyusb test suite working, but Conda is being difficult. | 09:12 |
xobs | I just installed miniconda, but whenever I try to use it it just says "CondaHTTPError: HTTP 000 CONNECTION FAILED for url <https://repo.anaconda.com/pkgs/main/linux-64/current_repodata.json>` | 09:12 |
*** futarisIRCcloud has joined #litex | 09:56 | |
*** _whitelogger has quit IRC | 13:00 | |
*** _whitelogger has joined #litex | 13:02 | |
*** Skip has joined #litex | 14:01 | |
*** kgugala has joined #litex | 14:08 | |
*** kgugala_ has quit IRC | 14:08 | |
CarlFK | xobs: still having trouble ? | 14:27 |
futarisIRCcloud | https://twitter.com/shenki/status/1262738635356430342?s=19 | 14:28 |
xobs | Yeah, I ended up giving up on it. | 14:28 |
xobs | CarlFK: I did just download iverilog from the symbiflow conda repo, but I couldn't use sigrok-cli from there because it links against python3.7m.so and Ubuntu 20.04 ships python3.8. So I rebuilt sigrok from scratch. | 14:33 |
CarlFK | I thought conda had it's own python binary | 14:35 |
xobs | I think that's why it works when you use it with Conda. But conda couldn't update or install anything. | 15:08 |
somlo | _florent_: somewhere in the last 24 hours I started getting "undefined reference to `busy_wait`" errors while building the (64-bit, Rocket) bios | 15:40 |
somlo | probably something about the `-I` path in some makefile -- busywait is defined in `litex/soc/software/libbase/system.c`, and declared in `system.h` which is now replicated inside each CPU specific directory | 15:41 |
somlo | _florent_: bisect says it's commit b4b84def (although I'm not seeing an obvious reason for e.g. libliteeth/udp.c to complain about an undefined reference to busy_wait following that particular patch) | 15:50 |
somlo | ok, I think I entered some sort of git twilight-zone -- I tried to `git revert b4b84def -n`, then build (successfully made it past the place it crapped out earlier); then `git revert --abort`, and now the build works fine while everything is back to the way it was when it crashed (for dubious values of "everything"). I even nuked the whole litex repo, cloned it, fetched, sync-ed up with upstream, everything works fine now :) | 16:14 |
somlo | _florent_: so, in conclusion, nevermind, latest git upstream is building fine, no idea why it wasn't, or why it is again, maybe I should just take a day off or something :D | 16:17 |
CarlFK | somlo: I don't suppose you are good at building https://github.com/timvideos/HDMI2USB-litex-firmware | 16:24 |
tpb | Title: GitHub - timvideos/HDMI2USB-litex-firmware: A version of the HDMI2USB firmware based around LiteX tools produced by @Enjoy-Digital (based on misoc+migen created by @M-Labs) (at github.com) | 16:24 |
CarlFK | I am not, and I burn up hours trying, so I don't. but there is a stupid off-by-1 error or something that is making me grumpy | 16:24 |
CarlFK | https://github.com/timvideos/HDMI2USB-litex-firmware | 16:26 |
tpb | Title: GitHub - timvideos/HDMI2USB-litex-firmware: A version of the HDMI2USB firmware based around LiteX tools produced by @Enjoy-Digital (based on misoc+migen created by @M-Labs) (at github.com) | 16:26 |
somlo | CarlFK: never tried building h2u -- I've only worked with "stock" upstream litex so far | 16:33 |
somlo | and only used sdcard and ethernet peripherals -- text-mode serial uart console only, no usb, graphics, pci, or anything "fancy" like that :) | 16:35 |
CarlFK | ah well, I'll dig up a 2018 build that worked good enough | 16:39 |
CarlFK | trying to use this device to debug a ubuntu+pi+netv2 bugaboo | 16:39 |
somlo | _florent_: re commit b4b84def -- I missed the change of build directory (from ./soc_basesoc_trellisboard to ./build/trellisboard/) which might explain the weirdness I was observing (and mistakenly blaming on git) | 16:53 |
somlo | now that I'm cleaning ./build/trellisboard before rebuilding, I'm back to getting a compile error for the bios (libliteeth/udp.c thinks busy_wait is an undefined reference) | 16:54 |
_florent_ | somlo: not sure i tested with rocket, i'm going to try | 17:12 |
_florent_ | somlo: can you give me the command you are executing? | 17:14 |
somlo | rm -rf build/trellisboard; litex-boards/litex_boards/targets/trellisboard.py --yosys-nowidelut --csr-csv ./csr_trellisboard.csv --sys-clk-freq 60e6 --with-ethernet --with-spi-sdcard --csr-data-width 32 --cpu-type rocket --cpu-variant linuxq --build | 17:15 |
somlo | reverting b4b84def fixes it for me, although I completely fail to see why :) | 17:20 |
*** kgugala has quit IRC | 17:56 | |
*** kgugala has joined #litex | 17:57 | |
*** kgugala_ has joined #litex | 17:58 | |
*** kgugala has quit IRC | 18:01 | |
*** Skip has quit IRC | 18:06 | |
*** kgugala has joined #litex | 18:52 | |
*** kgugala_ has quit IRC | 18:54 | |
somlo | _florent_: it's a LD (not CC) error, so I'm guessing software/libbase/system.c isn't getting compiled (or linked) into bios.elf for some reason | 20:03 |
somlo | so there's a build/trellisboard/software/libbase/system.o, and it does contain a busy_wait function (checked with objdump) | 20:05 |
somlo | so I wonder if it's somehow not getting linked | 20:05 |
somlo | _florent_: oh, I think I fixed it, it's really dumb, but apparently the order in which things are linked on the linker command line matters: https://pastebin.com/98DvHGkP | 20:17 |
tpb | Title: [Diff] diff --git a/litex/soc/software/bios/Makefile b/litex/soc/software/bios/Makefile - Pastebin.com (at pastebin.com) | 20:17 |
daveshah | yeah, dependencies need to come after the things that use them, iirc | 20:18 |
somlo | sending PR :) | 20:18 |
somlo | https://github.com/enjoy-digital/litex/pull/531 | 20:24 |
tpb | Title: software/bios: fix link order to avoid undefined symbol errors by gsomlo · Pull Request #531 · enjoy-digital/litex · GitHub (at github.com) | 20:24 |
*** darren099 has joined #litex | 21:54 | |
benh | Is Treillisboard something one can buy ? I'd like something ECP5 based for my work on Microwatt to complement my Arty | 22:05 |
*** darren099 has quit IRC | 22:13 | |
*** CarlFK has quit IRC | 23:45 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!