02:45 <gregdavill> loxodes: I just took a look at your dma code, and opened an issue with a fix. Pretty sure you just need to flush the caches.

03:00 <loxodes> gregdavill: thanks! the fix worked for me

03:06 <loxodes> I'm trying to understand why this fixed it - so the vexriscv cpu was caching some of the "adc_sram" memory, and reading unrelated hid the problem because that filled up the cache with something else?

03:08 <loxodes> and adding the volatile keyword to dram_array didn't help in this case because that only works on the compiler?

03:10 <gregdavill> Yeah, I think so. I'm not entirely sure of the logic behind how the cache lines are filled on the vex. But in general you should always invalidate the cache when using DMA and shared memory spaces.

16:45 <kbeckmann> Is anyone working on integrating PSRAM/qspi-ram support in litex? I have some quite low quality code that works but is good enough to verify that the chip works. (write 42Mbps / read 27Mbps at 50MHz cpu core)

16:45 <kbeckmann> just asking before i put in an effort in making it nice. would be fun to run it at the max speed and so on.

17:13 <zyp> there's hyperram at least: https://github.com/gregdavill/litex-hyperram/blob/master/hyperbus.py

17:13 <tpb> Title: litex-hyperram/hyperbus.py at master · gregdavill/litex-hyperram · GitHub (at github.com)

17:27 <kbeckmann> right, that nice. but i was thinking of integrating with LY68L6400SLIT

17:33 <kbeckmann> ah i see that https://github.com/enjoy-digital/litex/pull/381 exists, that should be usable for (q)spi-ram as well

17:33 <tpb> Title: spi_flash: Add quadspi support by mateusz-holenko · Pull Request #381 · enjoy-digital/litex · GitHub (at github.com)