01:05 <oter> Deciding whether to buy a Genesys2 or KC705 board to work with litex (eth and dram needed). Prefer the cheaper one if possible ;-) The Genesys2 entry in https://github.com/litex-hub/litex-boards says for the eth Phy "1Gbps RGMII*" --> "*Present on the board but not yet supported or validated with LiteX." Q: can anyone with a G2 board confirm that liteeth (all the way to arp and udp for my use-case) does or does not work for them? Thanks!

01:05 <tpb> Title: GitHub - litex-hub/litex-boards: LiteX boards files (at github.com)

01:28 <Finde> if someone built the appropriate files I wouldn't mind trying it on mine

03:54 <oter_> Thanks for offering your help, Finde!

06:23 <_florent_> lkcl: ok i see, the fact you have your IO/Pad ring at the top level makes things indeed a bit different and will indeed requires some modifications

06:25 <_florent_> oter_: the README is probably outdated, LiteEth is supported in the Genesys2 and i've been using it recently with the Genesys2 in LiteDRAM bench: https://github.com/enjoy-digital/litedram/blob/master/bench/genesys2.py

06:25 <tpb> Title: litedram/genesys2.py at master · enjoy-digital/litedram · GitHub (at github.com)

06:26 <_florent_> oter_: in this bench, the control of the SoC/log of the BIOS is done over Ethernet

07:29 <oter> _florent_ - that's great - thanks!

09:59 <shorne> my 3 year old just brought a development board to me and asked what is this?

10:00 <shorne> I said its a tool to design products like a phone

10:00 <shorne> Thats not what I am really doing though

10:00 <shorne> :)

10:33 <lkcl> _florent_: the precedent will establish litex for use in developing ASICs.

10:33 <lkcl> which is a Big Deal :)

10:51 <lkcl> _florent_, however on balance it's minimal modifications, which is fantastic

12:32 <pepijndevos> I have a 85F UL3XS, what do I need to do to run Linux on that? Seems the prebuilt stuf at least is for 45F but I assume I can compile from source?

13:04 <pepijndevos> wah... I added soc_kwargs and it compiles and loads fine

13:05 <pepijndevos> but I don't see a ttyUSB0 after uploading the bitstream

13:10 <pepijndevos> https://bpa.st/UCMQ wtf

13:10 <tpb> Title: View paste UCMQ (at bpa.st)

13:40 <pepijndevos> Okay, now I'm getting FileNotFoundError: [Errno 2] No such file or directory: 'buildroot/Image'

13:41 <pepijndevos> (used openFPGALoader instead of ujprog btw)

13:41 <pepijndevos> So obviously that image is just not being compiled at all... and I'm not sure what's supposed to do that.

13:44 <pepijndevos> ah okay, that's also in the prebuilt repo...

13:59 <pepijndevos> horaay! I can boot linux.

13:59 <pepijndevos> Now... can I use HDMI one the ULX3S?

14:23 <keesj> I don't know but .. how long before this all becomes a reality and we have usb stacks and hardware video decoding and we run it all on open scilicon

14:27 <keesj> The amp hour podcast had a few speakers on the open source PDK ( #501) Fabless Chip design (#503) is litex playing a role there?,

17:15 <_florent_> pepijndevos: not sure we have a ready-to-use solution for HDMI with ULX3S, but it should not be too complicated to reuse some HDMI code available for the ULX3S and connect LiteVideo or the DMA from LiteX to it

18:00 <pepijndevos> _florent_, yea it's very much not ready-to-use but people have done similar things. Would be cool if LiteVideo supported more devices, like ECP5.

18:01 <pepijndevos> If I understand correctly, you'd only need to implement the SERDES bits, right?

18:26 <_florent_> pepijndevos: yes indeed, LiteVideo has been developed before ECP5 was so popular and currently on supports Spartan6 and 7-Series

18:27 <_florent_> it would be nice to extend if to more devices, but i've not had time yet to do it myself

18:28 <_florent_> For video out, only the Serializer should indeed be replaced

18:30 <_florent_> The Gearbox from LiteX could also be useful: https://github.com/enjoy-digital/litex/blob/master/litex/soc/interconnect/stream.py#L504-L569

18:30 <tpb> Title: litex/stream.py at master · enjoy-digital/litex · GitHub (at github.com)

18:30 <_florent_> depending the serialization ratio of the ECP5 primitives

18:33 <_florent_> pepijndevos: also regarding twitter/LitePCIe, it's not a full PCIe core since reuses the PCIe hardblock PHYs, but it's still implementing the upper layers and is equivalent to the others PCIe core you can find (RIFFA, verilog-pcie, etc...)

18:35 <_florent_> even if we had an open-source PCIe PHY, it would still make sense to use the PCIe hardblock since it comes almost for free on FPGAs with PCIe hardblock PHYs

18:37 <_florent_> similar to using BlockRAMs when available instead of LUTRAMs :)

20:09 <tcal> Does wishbone-tool --load-name xxx.bin --load-address 0x4000000 work?

20:10 <tcal> I have a debug Litex SoC on Arty, with UART crossover bridge and a debug VexRiscv.

20:11 <tcal> I can use wishbone-tool with both -s terminal and -s gdb and they work great. But I need to figure out how to load my "application" program (bare metal compiled from C, linked with the Litex software/ libraries).

20:18 <zyp> litex-terminal can load software via the terminal, but I haven't tried using that with the crossover uart

20:20 <zyp> I guess you could use the --load-* flags to load it into memory and then maybe there's a terminal command to jump to it?

20:33 <tcal> Yeah, I'd usually use lxterm / litex_term to load the app with "--kernel" (serialboot). But the app hangs when it attempts to write a character, so I'm trying to debug on the board. Hmm, I have a UART Pmod, maybe I can rebuild the SoC to have two UARTs, and use one for the bridge with gdb, and use the other for terminal+serialboot.

20:40 <zyp> there's also the possibility of using the load command in gdb, but I don't think support for that is implemented in wishbone-tool yet

20:41 <zyp> it's on the list of things I'd like to put some work into at some point

20:42 <leons> Currently trying to port an OS to LiteX/VexRiscv. However after quite some debugging I can't seem to get the external interrupts (from the core's eventmanagers) to work. I must be missing something... Is there any good approach on how to debug something like this?

20:44 <leons> Until now I've treated the system as a black box and only tested from the OS (setting a Timer, observing that no interrupt fires and that the registers don't indicate anything pending)

20:45 <leons> Is there an easier way to check whether a certain signal is asserted other than for instance plain routing it to an LED?

20:46 <zyp> maybe use litescope?

20:48 <leons> zyp: That looks interesting. I'll see whether I can get it up and running