Thursday, 2019-06-06

*** tpb has joined #litex00:00
*** futarisIRCcloud has joined #litex04:34
keesjthis is not the nicesed part of the system06:41
key2keesj: what is07:18
*** futarisIRCcloud has quit IRC07:33
keesjthe syntax for combinatory logic07:45
*** ambro718 has joined #litex08:52
*** futarisIRCcloud has joined #litex10:25
somlotrying 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
tpbTitle: linux-on-litex-vexriscv/sim.py at master · enjoy-digital/linux-on-litex-vexriscv · GitHub (at github.com)13:33
somlodoes the shadow mask (0x8000_0000) still apply (i.e. does spiflash go to 5+8 -> 0xD000_0000)?13:34
somloand to ethmac (3->B)?13:34
somloand, overall, any particular motivation for why it *need* to be different from the default LiteX model?13:35
somlo_florent__ ^13:35
daveshahIncidentally, it would be worth considering the best way to get 1GiB of contiguous main RAM space13:36
somloI'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 ranges13:36
somlobut yeah, also what daveshah said :)13:36
daveshahThis 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
tpbTitle: Add TrellisBoard, 1GB hack · daveshah1/linux-on-litex-vexriscv@4bb8cd9 · GitHub (at github.com)13:38
daveshahBut I was a bit confused about the shadow stuff in linux-on-litex-vexriscv too13:38
daveshahVexRiscv also has some hardcoded IO range stuff: https://github.com/enjoy-digital/VexRiscv-verilog/blob/master/src/main/scala/vexriscv/GenCoreDefault.scala#L14013:39
tpbTitle: VexRiscv-verilog/GenCoreDefault.scala at master · enjoy-digital/VexRiscv-verilog · GitHub (at github.com)13:39
DoluI agree, some memory remapping could be usefull13:40
DoluProbably the 0xC0000000 is because the linux kernel use virtual address 0xC0000000 for its memory location ? (1:1 virtual to physical mapping)13:41
DoluBut that's not a requirements13:41
DoluAlso we can change uncached IO region in the VexRiscv generation13:42
DoluFor what is used shadow stuff in Litex ?13:42
daveshahYep, I had to do that to move the uncached CSR region below 0xC, so 0xC and up was the 1GiB of contiguous RAM13:43
daveshahI think the idea about shadow is to provide uncached/cached views of the same memory13:43
daveshahNot sure how consistently it is being used though13:43
DoluIs it used to access the memory used by DMA without having to flush data cache ?13:44
somlofrom 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
somloright now, in standard litex, that's "everything below 0x8000_0000 is cached, everything above is uncached", which works out nicely13:47
somlobut then again, I'm only starting to understand what it'd take to boot linux on it...13:48
somlobtw, with the standard LiteX mapping main_ram at 0x4000_0000, we'd be able to fit exactly 1GB before reaching the uncached >= 0x8000_0000 zone13:57
somlodaveshah: 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
Doluso, potentialy, RV32 linux cores with the standard MMU can handle 8GB of physical memory space13:59
somloDolu: where would the 33rd address bit come from (you can address 4GB with 32 bits)14:20
DoluFrom the riscv-previleged spec : The 20-bit VPN is translated into a 22-bit physical page number (PPN)14:22
Dolusorry, 16 GB O.o14:22
Doluso Sv32 => 32 bits virtual address into 34 bits physical address14:24
somloAah, that makes sense14:24
somloif 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
DoluIt make me think to actual hard drive, which to read their whole content would need about 15 hours XD14:26
*** futarisIRCcloud has quit IRC14:34
*** futarisIRCcloud has joined #litex16:07
futarisIRCcloudMorning. Linux on LiteX call time?16:09
somlohmm... 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 expansion17:26
somlostill digging around, hopefully discontiguous RAM regions don't *have* to each be reached through their own separate AXI port :)17:26
*** futarisIRCcloud has quit IRC19:25
*** ambro718 has quit IRC23:10
*** futarisIRCcloud has joined #litex23:47
futarisIRCcloud_florent__: https://github.com/enjoy-digital/linux-on-litex-vexriscv/pull/1823:48
tpbTitle: make liteeth work by frantony · Pull Request #18 · enjoy-digital/linux-on-litex-vexriscv · GitHub (at github.com)23:48
futarisIRCcloudI 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!