09:12 <leons> This might be a stupid question: how predictable is the timing of accessing memory-mapped registers (such as the CSRs) via Wishbone when issuing a read / write using something like a VexRiscv CPU?

09:13 <leons> I'm afraid I don't fully understand how the data bus caching would affect those, but intuitively I'd guess not at all? Given that a register read / write may have other side effects so it effectively can't be cached, right?

09:39 <Zguig> Hi _florent_, for info, I did some research, but couldn't find how to debug this. I still have issues with the IRQ configuration of liteeth with my ecpix5 board and linux on vexriscv. When I put back polling in the dtb it is working fine as you adviced me but I could find a good tutorial on how to analyse the IRQ reception in Linux to find what was

09:39 <Zguig> the issue... Has anybody else the same issue?

09:42 <Zguig> Best ressources I found were this

09:42 <Zguig> https://blog.packagecloud.io/eng/2016/06/22/monitoring-tuning-linux-networking-stack-receiving-data/#interrupt-handler

09:42 <tpb> Title: Monitoring and Tuning the Linux Networking Stack: Receiving Data - Packagecloud Blog (at blog.packagecloud.io)

09:42 <Zguig> https://wiki.linuxfoundation.org/networking/napi

09:42 <tpb> Title: networking:napi [Wiki] (at wiki.linuxfoundation.org)

12:44 <_florent_> leons: The CSR region is part of the IO region and is not cached. So if the CPU is the only master on the SoC bus, you'll have predictable timings. (If you have other Masters there will be some arbitration which will not be predictable)

12:46 <leons> florent: that's what I thought, but great to have someone more knowledgeable confirm it, thanks!

12:47 <_florent_> Zguig: I'm going to do a quick test with Linux-on-LiteX-Vexriscv and the ECP5

12:48 <_florent_> ECP5/ECPIX5

13:32 <_florent_> Zguig: I'm able to reproduce the issue but will not be able to investigate now

13:37 <shorne_> somlo: sorry for late reply, Yes its upstream, time to rebased and test if you haven't already

13:38 <shorne_> any luck with MMC? I got sidetracked on some other work (barebox, openrisc github ci) but now I can get back to looking at the MMC stuff

13:38 <shorne_> I wanted to try out litescope

16:01 <_florent_> shorne_: Hi, somlo investigated a bit on the SDCard but we've also been busy with other things.

16:03 <_florent_> shorne_: I still need to do some capture with an external Logic Analyzer with Arty/SDCard PMOD to compare accesses with the BIOS and with Linux

16:03 <_florent_> If you want to use LiteScope, you can have a look at: https://github.com/enjoy-digital/litex/wiki/Use-LiteScope-To-Debug-A-SoC

17:38 <_florent_> oter: Not sure I've seen this, but if you have a minimal design that reproduce the issue, can you create an issue on LiteEth? I could investigate (and also have a Genesys2)

17:51 <_florent_> oter: ok thanks, that's indeed easier to investigate on the same hardware :)

19:26 <nickoe> _florent_: Should I create an issue about the donut issue where it appears to exit it immediately (one frame) in simlation?

20:34 <_florent_> nickoe: yes please, thanks.

21:10 <shorne_> _florent_: thanks, I was reading *a* page on litescope, but I think your link is much more detailed