03:24 <bubble_buster> I'm trying to generate the orangecrab.py from litex-hub/litex-boards and I get this error

03:24 <bubble_buster> build/orangecrab/software/include/generated/sdram_phy.h:5:10: fatal error: hw/flags.h: No such file or directory

03:25 <bubble_buster> my root litex directory is github enjoy-digital/litex, I've pulled the latest main branch and run litex_setup.py

03:26 <bubble_buster> any suggestions on how to debug this? I've tried to dig around a bit and it's not clear to me where hw/flags.h should be coming from

07:50 <zyp> bubble_buster, do you have the newest litedram? as far as I can see it doesn't try referencing flags.h anywhere

07:53 <zyp> apparently it was removed two months ago: https://github.com/enjoy-digital/litedram/commit/c30910a

07:53 <tpb> Title: init: generate DFII_CONTROL flags in sdram_phy.h instead of defining … · enjoy-digital/litedram@c30910a · GitHub (at github.com)

12:19 <zyp> _florent_, I've been working on porting litepcie_util to use VFIO instead of the litepcie kernel driver and I almost have the dma test working now (got DMA running, just need to fix the buffer management), but it only works once

12:20 <zyp> when I kill and restart the process, it doesn't work anymore and so far I haven't been able to recover without reloading the fpga

12:24 <zyp> I assume the issue is that I don't stop the DMA before exiting the process, so I guess it's still running while the IOMMU gets unmapped which then causes the DMA to deadlock somehow

12:26 <zyp> the obvious solution is of course to stop the DMA before leaving the process, but I still think it's important to be able to recover after the process e.g. segfaults

12:27 <zyp> this only affects DMA, MMIO keeps working

14:19 <_florent_> zyp: interesting for your VFIO work. That would be interesting to add Litescope on the DMA Writer/Reader to see what is going on. I suspect the DMA Reader get stuck by issuing read requests but don't get the completion if the IOMMU is unmapped. If this is what is happening, we could add a register to be flush all the pending read requests restart from a clean state.

15:01 <somlo> _florent_: so with commit 4a18b828 we're back in business for spi-mode sdcard on nexys4ddr and rocket -- thanks!

15:02 <_florent_> somlo: thanks for testing, i was going to ask you if you could do a test ;)

15:02 <somlo> "regular" sdcard is still not working with default litex (and that includes using vexriscv as the cpu)

15:02 <somlo> but that's a completely different complaint :)

15:02 <_florent_> yes i'm working on this

15:03 <somlo> I have vacation coming up in august and nowhere to go, so I'll have some time to spend on this :) Goal is to figure out all the up/down converters needed to properly hook up rocket for DMA

15:04 <somlo> and getting the largest number of rocket cores I can get away with on a genesys2 board...

15:08 <_florent_> somlo: i just need to rearrange the clocking a bit, but you should be able to use the SDCard core in the next days

15:09 <_florent_> somlo: there is a similar DMA interface on VexRiscv SMP and are planning to use the SDCard with DMA to validate it

15:10 <_florent_> so this will be very similar to the work required on Rocket and we could join our efforts on this

15:14 <somlo> might end up being a fun vacation after all ;)

18:02 <_florent_> somlo: can you do a test with latest litesdcard / Vexriscv on the Trellisboard?

19:05 <somlo> _florent_: I already tried with rocket on nexys4ddr (no luck yet). building vexriscv for trellisboard now...

19:17 <zyp> _florent_, re: dma reader; that sounds plausible

19:17 <zyp> which signals would be the interesting ones to watch?

19:17 <zyp> and what should be flushed if anything?

19:35 <_florent_> somlo: since it's doing DMA, i don't think it will work without connecting the DMA to rocket as we discussed.

19:37 <_florent_> zyp: you can look at pending_words: https://github.com/enjoy-digital/litepcie/blob/master/litepcie/frontend/dma.py#L253

19:37 <_florent_> zyp: but this one should be reseted correctly when disabling the DMA

19:39 <_florent_> the controller is currently not reseted: https://github.com/enjoy-digital/litepcie/blob/master/litepcie/tlp/controller.py#L37

19:40 <_florent_> we should probably add a way to reset the controller properly

19:40 <zyp> and the requests_queue is only used for DMA, not MMIO since those requests are going the other way?

19:46 <_florent_> zyp: indeed, it's two different channels

19:51 <somlo> _florent_: I temporarily hacked rocket to route both mmio and mem accesses over the wishbone bus

19:52 <somlo> _florent_: locally, in my clone of the litex repo

19:53 <somlo> _florent_: but I'll stick to vexriscv just to minimize the "unknown unknowns" :D

20:47 <somlo> _florent_: I actually built rocket for trellisboard; sdcard boot works intermittently

20:49 <_florent_> somlo: interesting, could you provide me the bitstream, i instrumented my trellisboard with probes on the SDCard pins and would like to do some checks

20:49 <_florent_> i could do that tomorrow

20:50 <zyp> uh, wtf have I fucked up? https://paste.jvnv.net/view/hAfFi

20:55 <somlo> _florent_: sent you an email

20:58 <zyp> nevermind, I added a do_finalize() to my SoC and forgot to call SoCCore.do_finalize()

21:16 <_florent_> somlo: thanks for the bitstream, can you describe the "works intermittently"?

21:17 <_florent_> somlo: is is failing loading the binary? or is is loading the binary but failing during the Linux boot?

21:22 <somlo> I push it to the board with openocd; it typically hangs or fails at sdcard boot, and when it fails, it falls through to netboot and then the prompt

21:22 <somlo> if I hit the reset switch repeatedly, about 50% of the time it actually loads successfully from sdcard

21:23 <somlo> I should probably send you my boot.bin blob with the rocket bbl and kernel (sorry, forgot to do that)

21:25 <_florent_> ok thanks, i'll have a look at it with the probes

21:26 <somlo> ok, you should have the boot.bin blob I'm using as well

21:28 <somlo> not sure if it's useful to know at this stage that the exact same design built for nexys4ddr fails (falls through to netboot and prompt) reliably

21:30 <_florent_> Would you mind also sending it to me? I'll have look at the SDCard signals

21:30 <zyp> _florent_, I hooked up a couple of LiteScopeIO, pending_words appears to always read 0, requests_queue.level reads 9

21:31 <zyp> so I guess it's the requests_queue that needs to be flushed

21:35 <somlo> _florent_: done