04:26 <xobs> florent (or anyone else): have you ever encountered an issue where the UART rx IRQ gets stuck? I'm trying to get litescope working so I can get a better idea of why...

04:27 <xobs> ...but the symptoms are that the ISR is constantly running, and the UART_EV_STATUS bit is permanently stuck on 2. Disabling that IRQ fixes it, though.

04:36 <xobs> I'm sorry, it's the "tx" bit. Hmm... maybe this is a software problem in the bios. If I manually clear that register, then it prints out more data, but it looks like the actual buffer contents are dropped.

05:17 <xobs> Okay, that's just bizarre. It's doing `lw a5,0(a5)` with `a5=0x82001810`. In the debugger, this returns `1` (i.e. "tx bit set"), but the CPU is actually seeing this as `0`. If I change the return value to `1` then it works better.

05:17 <xobs> I wonder if there's a caching issue here...

05:25 <xobs> Looks like it. If I use my own CPU (which has a cache) or linux+debug, then I get the failure. If I use "min+debug" it works.

05:55 <xobs> Yeah, my theory is that the dcache isn't getting flushed. It's either that or the mmu (which isn't used) is causing issues. But I definitely can tell that the CPU is not seeing what's actually going on, even if I stick a `fence.i` in there.

05:59 <sorear> why is the I/O space being cached in the first place?

06:00 <sorear> `fence.i` only affects instruction fetches and wouldn't be expected to help here

06:00 <xobs> I'm not sure the vexriscv knows which space is which. I thought the high bit prevented it from being cached, but AIUI that's only if you're using the L2 cache.

06:19 <sorear> risc-v is designed around the idea that your memory attributes are set correctly and cache flushing is not a thing

06:20 <sorear> only caches that are entirely transparent to software are supportable

06:22 <xobs> Interesting. So how do I indicate a region shouldn't be cached?

06:23 <_florent_> xobs: is there something else specific with your SoC/use-case? is it only when having debug enabled?

06:24 <xobs> florent: ill have to check about the debug mode.

06:24 <xobs> But how does litex indicate to vex that a particular region shouldn't be cached?

06:26 <_florent_> In the SoC, we have the shadow_base, but i how to check how this information is passed to vexriscv

06:28 <xobs> Just to check: have others gotten "linux+debug" and/or "linux" to work with the uart?

06:29 <_florent_> xobs: for linux yes, not sure we tested linux+debug

06:30 <xobs> _florent_: alright, thanks. I'm not using an socsdram, so there's no L2 cache. Would that affect anything?

06:33 <_florent_> xobs: if i do: lxsim --cpu-type=vexriscv --cpu-variant=std

06:33 <_florent_> it's working correctly

06:33 <_florent_> but lxsim --cpu-type=vexriscv --cpu-variant=linux

06:33 <_florent_> https://www.irccloud.com/pastebin/0nNjaGYS/

06:33 <tpb> Title: Snippet | IRCCloud (at www.irccloud.com)

06:34 <_florent_> is not and is stuck just after ^

06:34 <_florent_> do you have a similar behaviour?

06:35 <_florent_> but we have using a specific mem-map in linux-on-litex-vexriscv: https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/soc_linux.py#L45-L52 which makes it works

06:35 <tpb> Title: linux-on-litex-vexriscv/soc_linux.py at master · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com)

06:36 <xobs> florent: no, the behavior I see is it just prints a few underscores and then gets stuck in the isr.

06:37 <xobs> So when I get the device back, I'll check to see if it works with debug disabled, then I'll check to see if the "std" cpu works. Then I'll see if reassigning the memory map helps.

06:37 <_florent_> ah ok, i already saw that then

06:40 <xobs> Already saw that?

06:41 <_florent_> yes with a wrong mem_map/shadow_base

06:41 <_florent_> are you able to share your SoC/CPU, i could do a test in simulation

06:41 <xobs> Oh. So you've seen the issue, and fixing the mem_map works around it?

06:45 <xobs> The design is at https://github.com/xobs/haddecks/blob/master/haddecks.py but that's three days old. Not much has changed.

06:45 <tpb> Title: haddecks/haddecks.py at master · xobs/haddecks · GitHub (at github.com)

06:46 <xobs> Alright, it kind of makes sense that assigning the csr to a high address fixes it. Thanks for the feedback!

06:47 <xobs> I'm still curious how to indicate to vex that a region is uncached.

06:48 <xobs> Also, is it possible to use the L2 cache in front of the spi ram module I have? Or does it basically assume sdram?

06:48 <_florent_> i think your issue is the same i see with the simulation, just that the behaviour is a bit different on real hardware vs simulation (the simulation is able to output more characters)

07:04 <xobs> So maybe it's the mmu and not the dcache.

07:07 <_florent_> xobs: then maybe have a look at this: https://github.com/m-labs/VexRiscv-verilog/blob/master/src/main/scala/vexriscv/GenCoreDefault.scala#L139-L143

07:07 <tpb> Title: VexRiscv-verilog/GenCoreDefault.scala at master · m-labs/VexRiscv-verilog · GitHub (at github.com)

07:08 <_florent_> xobs: it seems cached/uncached regions are just defined in VexRiscv with ioRange (uncached = io)

07:11 <xobs> Oh! That's what that does. Then that totally explains it. The regions are hardcoded and the defaults put them in the wrong spot.

07:12 <xobs> Thanks! I'm confident that remapping ram will fix things.

07:14 <xobs> I should remap them in Fomu, too.

07:16 <xobs> I wonder. Does that mean they're not subject to mmu access controls?

07:30 <_florent_> xobs: when looking at VexRiscv source code, it seems to be subject to mmu access controls:

07:30 <_florent_> https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/scala/vexriscv/plugin/MmuPlugin.scala#L124

07:30 <tpb> Title: VexRiscv/MmuPlugin.scala at master · SpinalHDL/VexRiscv · GitHub (at github.com)

07:30 <_florent_> https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/scala/vexriscv/plugin/MmuPlugin.scala#L131

07:30 <tpb> Title: VexRiscv/MmuPlugin.scala at master · SpinalHDL/VexRiscv · GitHub (at github.com)

07:30 <_florent_> so you first translate

07:31 <_florent_> and the check is done here: https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/scala/vexriscv/plugin/MmuPlugin.scala#L138

07:31 <tpb> Title: VexRiscv/MmuPlugin.scala at master · SpinalHDL/VexRiscv · GitHub (at github.com)

07:43 <xobs> That's really well designed. I guess riscv must have a concept of an io region that is defacto uncached. That's different coming from arm.

07:49 <xobs> Thanks for tracking that down, _florent_! I've learned something today about vex and riscv.

07:51 <_florent_> That was also instructive for me, i should really spend more time studying VexRiscv code

09:00 <xobs> Ah, I see why I don't have the issue with foboot - I already hardcoded the memory addresses to the ones you provided.

09:03 <xobs> _florent_: I was getting ready to use litescope, and I found an issue in wishbone-tool where it doesn't support transfers with more than one word. So that's another yak to shave! But that's really a thing I should have already fixed.

16:36 <xobs> florent: that did solve the problem, thanks!

17:33 <_florent_> xobs: ok great, thanks for the feedback