| *** tpb has joined #litex | 00:00 | |
| *** CarlFK has quit IRC | 02:17 | |
| *** CarlFK has joined #litex | 03:13 | |
| 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:26 |
|---|---|---|
| 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:27 |
| 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. | 04:36 |
| 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:17 |
| 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:25 |
| 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:55 |
| 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:01 |
| 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:20 |
| xobs | Interesting. So how do I indicate a region shouldn't be cached? | 06:22 |
| _florent_ | xobs: is there something else specific with your SoC/use-case? is it only when having debug enabled? | 06:23 |
| 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:25 |
| _florent_ | In the SoC, we have the shadow_base, but i how to check how this information is passed to vexriscv | 06:26 |
| xobs | Just to check: have others gotten "linux+debug" and/or "linux" to work with the uart? | 06:28 |
| _florent_ | xobs: for linux yes, not sure we tested linux+debug | 06:29 |
| xobs | _florent_: alright, thanks. I'm not using an socsdram, so there's no L2 cache. Would that affect anything? | 06:30 |
| _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:34 |
| 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:34 |
| _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:35 |
| xobs | florent: no, the behavior I see is it just prints a few underscores and then gets stuck in the isr. | 06:36 |
| 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:38 |
| _florent_ | ah ok, i already saw that then | 06:38 |
| xobs | Already saw that? | 06:40 |
| _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:42 |
| 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:45 |
| xobs | Alright, it kind of makes sense that assigning the csr to a high address fixes it. Thanks for the feedback! | 06:46 |
| xobs | I'm still curious how to indicate to vex that a region is uncached. | 06:47 |
| 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) | 06:49 |
| xobs | So maybe it's the mmu and not the dcache. | 07:04 |
| _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:08 |
| 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:08 |
| 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:11 |
| xobs | Thanks! I'm confident that remapping ram will fix things. | 07:12 |
| xobs | I should remap them in Fomu, too. | 07:14 |
| xobs | I wonder. Does that mean they're not subject to mmu access controls? | 07:16 |
| _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:31 |
| 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:44 |
| xobs | Thanks for tracking that down, _florent_! I've learned something today about vex and riscv. | 07:49 |
| _florent_ | That was also instructive for me, i should really spend more time studying VexRiscv code | 07:51 |
| 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:00 |
| 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. | 09:03 |
| *** _whitelogger has quit IRC | 10:57 | |
| *** _whitelogger has joined #litex | 11:00 | |
| *** freemint has quit IRC | 12:12 | |
| *** freemint has joined #litex | 13:12 | |
| *** freemint has quit IRC | 14:13 | |
| *** freeemint has joined #litex | 14:13 | |
| *** xobs has quit IRC | 14:19 | |
| *** synaption[m] has quit IRC | 14:19 | |
| *** john_k[m] has quit IRC | 14:19 | |
| *** nrossi has quit IRC | 14:19 | |
| *** CarlFK has quit IRC | 15:18 | |
| *** xobs has joined #litex | 16:31 | |
| xobs | florent: that did solve the problem, thanks! | 16:37 |
| *** synaption[m] has joined #litex | 16:52 | |
| *** nrossi has joined #litex | 16:52 | |
| *** john_k[m] has joined #litex | 16:53 | |
| *** CarlFK has joined #litex | 16:55 | |
| _florent_ | xobs: ok great, thanks for the feedback | 17:33 |
| *** freeemint has quit IRC | 17:35 | |
| *** freeemint has joined #litex | 17:35 | |
| *** freeemint has quit IRC | 18:34 | |
| *** freeemint has joined #litex | 19:19 | |
| *** freeemint has quit IRC | 19:44 | |
| *** freeemint has joined #litex | 19:44 | |
| *** freeemint has quit IRC | 19:55 | |
| *** freeemint has joined #litex | 19:56 | |
| *** freeemint has quit IRC | 21:36 | |
| *** freeemint has joined #litex | 22:17 | |
| *** freeemint has quit IRC | 22:22 | |
| *** CarlFK has quit IRC | 22:28 | |
| *** freeemint has joined #litex | 23:33 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!