| *** tpb has joined #litex | 00:00 | |
| *** futarisIRCcloud has joined #litex | 04:34 | |
| keesj | this is not the nicesed part of the system | 06:41 |
|---|---|---|
| key2 | keesj: what is | 07:18 |
| *** futarisIRCcloud has quit IRC | 07:33 | |
| keesj | the syntax for combinatory logic | 07:45 |
| *** ambro718 has joined #litex | 08:52 | |
| *** futarisIRCcloud has joined #litex | 10:25 | |
| somlo | trying to understand the linux-on-litex-vexriscv memory model (https://github.com/enjoy-digital/linux-on-litex-vexriscv/blob/master/sim.py#L69) and how it compares against the LiteX default (https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc_core.py#L157) | 13:33 |
| tpb | Title: linux-on-litex-vexriscv/sim.py at master · enjoy-digital/linux-on-litex-vexriscv · GitHub (at github.com) | 13:33 |
| somlo | does the shadow mask (0x8000_0000) still apply (i.e. does spiflash go to 5+8 -> 0xD000_0000)? | 13:34 |
| somlo | and to ethmac (3->B)? | 13:34 |
| somlo | and, overall, any particular motivation for why it *need* to be different from the default LiteX model? | 13:35 |
| somlo | _florent__ ^ | 13:35 |
| daveshah | Incidentally, it would be worth considering the best way to get 1GiB of contiguous main RAM space | 13:36 |
| somlo | I'm asking because Rocket has internal routing hardcoded in chisel, so I need to pre-configure which way it'll send out cached-RAM vs. uncached(MMIO) requests, and for which address ranges | 13:36 |
| somlo | but yeah, also what daveshah said :) | 13:36 |
| daveshah | This was the mapping I ended up trying: https://github.com/daveshah1/linux-on-litex-vexriscv/commit/4bb8cd9a06565b34470dd5fc4b6b07a914dbcf56#diff-1c3a073ba4b12612a2c65941bd2a5842R69 (also had to modify LiteX's memory decoding to support different size mappings) | 13:38 |
| tpb | Title: Add TrellisBoard, 1GB hack · daveshah1/linux-on-litex-vexriscv@4bb8cd9 · GitHub (at github.com) | 13:38 |
| daveshah | But I was a bit confused about the shadow stuff in linux-on-litex-vexriscv too | 13:38 |
| daveshah | VexRiscv also has some hardcoded IO range stuff: https://github.com/enjoy-digital/VexRiscv-verilog/blob/master/src/main/scala/vexriscv/GenCoreDefault.scala#L140 | 13:39 |
| tpb | Title: VexRiscv-verilog/GenCoreDefault.scala at master · enjoy-digital/VexRiscv-verilog · GitHub (at github.com) | 13:39 |
| Dolu | I agree, some memory remapping could be usefull | 13:40 |
| Dolu | Probably the 0xC0000000 is because the linux kernel use virtual address 0xC0000000 for its memory location ? (1:1 virtual to physical mapping) | 13:41 |
| Dolu | But that's not a requirements | 13:41 |
| Dolu | Also we can change uncached IO region in the VexRiscv generation | 13:42 |
| Dolu | For what is used shadow stuff in Litex ? | 13:42 |
| daveshah | Yep, I had to do that to move the uncached CSR region below 0xC, so 0xC and up was the 1GiB of contiguous RAM | 13:43 |
| daveshah | I think the idea about shadow is to provide uncached/cached views of the same memory | 13:43 |
| daveshah | Not sure how consistently it is being used though | 13:43 |
| Dolu | Is it used to access the memory used by DMA without having to flush data cache ? | 13:44 |
| somlo | from a Rocket perspective, I'd be most happy if I could route all MMIO to one giant contiguous range, and all cached RAM to another contiguous range. I am enough of a Rocket n00b that it's likely possible to do multiple interleaved regions of different types, but at this time I just don't know :) | 13:46 |
| somlo | right now, in standard litex, that's "everything below 0x8000_0000 is cached, everything above is uncached", which works out nicely | 13:47 |
| somlo | but then again, I'm only starting to understand what it'd take to boot linux on it... | 13:48 |
| somlo | btw, with the standard LiteX mapping main_ram at 0x4000_0000, we'd be able to fit exactly 1GB before reaching the uncached >= 0x8000_0000 zone | 13:57 |
| somlo | daveshah: which for me would end up being a problem if we'd ever get a board with *two* Gigs :) | 13:58 |
| * somlo better start digging through the Rocket sources and find some way to interleave cached and mmio regions :) | 13:58 | |
| Dolu | so, potentialy, RV32 linux cores with the standard MMU can handle 8GB of physical memory space | 13:59 |
| somlo | Dolu: where would the 33rd address bit come from (you can address 4GB with 32 bits) | 14:20 |
| Dolu | From the riscv-previleged spec : The 20-bit VPN is translated into a 22-bit physical page number (PPN) | 14:22 |
| Dolu | sorry, 16 GB O.o | 14:22 |
| Dolu | so Sv32 => 32 bits virtual address into 34 bits physical address | 14:24 |
| somlo | Aah, that makes sense | 14:24 |
| somlo | if you add up all the non-overlapping portions of many separate 32-bit virtual spaces, and the hardware cooperates, you can keep going on and on :) | 14:25 |
| Dolu | It make me think to actual hard drive, which to read their whole content would need about 15 hours XD | 14:26 |
| *** futarisIRCcloud has quit IRC | 14:34 | |
| *** futarisIRCcloud has joined #litex | 16:07 | |
| futarisIRCcloud | Morning. Linux on LiteX call time? | 16:09 |
| somlo | hmm... default rocket config is MMIO at 0x6000_000 and RAM at 0x8000_0000; they might be on to something, as MMIO ports can plausibly be packed into a smaller overall region, and 0x8000_0000+ allows for practically unlimited contiguous RAM expansion | 17:26 |
| somlo | still digging around, hopefully discontiguous RAM regions don't *have* to each be reached through their own separate AXI port :) | 17:26 |
| *** futarisIRCcloud has quit IRC | 19:25 | |
| *** ambro718 has quit IRC | 23:10 | |
| *** futarisIRCcloud has joined #litex | 23:47 | |
| futarisIRCcloud | _florent__: https://github.com/enjoy-digital/linux-on-litex-vexriscv/pull/18 | 23:48 |
| tpb | Title: make liteeth work by frantony · Pull Request #18 · enjoy-digital/linux-on-litex-vexriscv · GitHub (at github.com) | 23:48 |
| futarisIRCcloud | I guess the simplest way to fix interrupts is to hook up a gpio pushbutton to an interrupt line... | 23:51 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!