01:09 <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:36 <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:43 <CarlFK> huh. boot pi, then plug in netv2, pi is fine.

02:29 <CarlFK> swell. boots debian fine, ubuntu.. wonky hardly gets out the door

06:44 <zyp> oter_, what are you trying to achieve?

07:07 <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:08 <oter_> zyp, some of my access patterns are random access and for others I might be able to use the litedram DMA frontend.

07:09 <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:12 <zyp> ah, for litedram I believe you should be able to add another port that you can access

07:16 <_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:17 <_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:18 <zyp> if you want wishbone, can't you just use LiteDRAMWishbone2Native with option 2?

07:19 <_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:22 <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:25 <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:30 <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:31 <_florent_> oter_: exactly

07:32 <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:33 <oter_> roger that _florent_ and tpb!

07:34 <sajattack[m]> tpb is a bot

07:34 <oter_> oh :-)

09:12 <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>`

14:27 <CarlFK> xobs: still having trouble ?

14:28 <futarisIRCcloud> https://twitter.com/shenki/status/1262738635356430342?s=19

14:28 <xobs> Yeah, I ended up giving up on it.

14:33 <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:35 <CarlFK> I thought conda had it's own python binary

15:08 <xobs> I think that's why it works when you use it with Conda. But conda couldn't update or install anything.

15:40 <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:41 <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:50 <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)

16:14 <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:17 <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:24 <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:26 <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:33 <somlo> CarlFK: never tried building h2u -- I've only worked with "stock" upstream litex so far

16:35 <somlo> and only used sdcard and ethernet peripherals -- text-mode serial uart console only, no usb, graphics, pci, or anything "fancy" like that :)

16:39 <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:53 <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:54 <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)

17:12 <_florent_> somlo: not sure i tested with rocket, i'm going to try

17:14 <_florent_> somlo: can you give me the command you are executing?

17:15 <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:20 <somlo> reverting b4b84def fixes it for me, although I completely fail to see why :)

20:03 <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:05 <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:17 <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:18 <daveshah> yeah, dependencies need to come after the things that use them, iirc

20:18 <somlo> sending PR :)

20:24 <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)

22:05 <benh> Is Treillisboard something one can buy ? I'd like something ECP5 based for my work on Microwatt to complement my Arty