| *** tpb has joined #litex | 00:00 | |
| *** acathla has quit IRC | 00:22 | |
| *** futarisIRCcloud has joined #litex | 02:09 | |
| *** RedMercury has joined #litex | 04:22 | |
| RedMercury | hello | 04:22 |
|---|---|---|
| RedMercury | I'm trying to play with litex, building for mimasv2, but I'm getting this error: OSError: no version directory for Xilinx tools found in /opt/Xilinx/ | 04:23 |
| *** futarisIRCcloud has quit IRC | 04:28 | |
| RedMercury | just tried my arty instead, ran into an issue and that's how I created my first litex pull request :p | 05:20 |
| *** RedMercury has quit IRC | 06:10 | |
| *** futarisIRCcloud has joined #litex | 06:40 | |
| futarisIRCcloud | https://antmicro.com/blog/2019/05/zephyr-rtos-in-riscv-getting-started-guide/ | 07:29 |
| tpb | Title: Open source Zephyr RTOS featured in RISC-V Getting Started Guide (at antmicro.com) | 07:29 |
| *** acathla has joined #litex | 07:48 | |
| *** acathla has quit IRC | 07:54 | |
| *** acathla has joined #litex | 07:54 | |
| *** futarisIRCcloud has quit IRC | 09:40 | |
| *** futarisIRCcloud has joined #litex | 11:02 | |
| *** futarisIRCcloud has quit IRC | 13:12 | |
| *** ambro718 has joined #litex | 16:42 | |
| ambro718 | Hi. Could someone explain the ethernet config in dts? https://github.com/enjoy-digital/linux-on-litex-vexriscv/blob/master/buildroot/board/litex_vexriscv/litex_vexriscv_arty.dts#L72 | 16:43 |
| tpb | Title: linux-on-litex-vexriscv/litex_vexriscv_arty.dts at master · enjoy-digital/linux-on-litex-vexriscv · GitHub (at github.com) | 16:43 |
| ambro718 | I don't understand where the address f0009800 comes from or where interrupts = <0x3>; comes from. | 16:43 |
| ambro718 | According to soc_linux.py, the ethernet is at address 0x30000000, and I can't find any setting of the interrupt number | 16:44 |
| _florent__ | ambro718: sorry, the ethernet support is still not finished, there are probably some incoherencies, i need to have a closer look | 17:05 |
| ambro718 | Okay, no problem. | 17:09 |
| ambro718 | I am wondering what's all the infrastructure around CSRs? I read these are special registers built into the risc-v instruction set but I don't get what is happening in litex with the csr mapping and WB2CSR | 17:11 |
| _florent__ | ambro718: for your arty a7-100: https://github.com/enjoy-digital/litex/commit/220e2bdc6e8e68244c53c685282a318e48dfef82 | 17:20 |
| tpb | Title: boards/platform/arty: add Arty A7-100 variant · enjoy-digital/litex@220e2bd · GitHub (at github.com) | 17:20 |
| ambro718 | _florent__: That's cool, though how can it be used from linux-on-litex-vexriscv? | 17:21 |
| somlo | ambro718: RISC-V CSRs are orthogonal to LiteX CSRs (I know, confusing at first) :) | 17:22 |
| ambro718 | somlo: so what are LiteX CSRs? | 17:22 |
| somlo | LiteX CSRs are essentially MMIO registers | 17:22 |
| somlo | for various hardware provided by the SoC, external to the CPU itself | 17:23 |
| ambro718 | somlo: That's the same thing peripherals are typically accessed from? | 17:23 |
| somlo | yes | 17:23 |
| ambro718 | Ah so this is all about the address space of the peripherals? | 17:23 |
| somlo | LiteX gives you a bunch of peripherals, and you configure them via MMIO - they're referred to as CSRs in the LiteX vernacular | 17:23 |
| ambro718 | So how is access to CSRs routed to peripherals? | 17:24 |
| _florent__ | the CSR of LiteX are different than CSR of RISC-V, that's the Control Status Registers you create in your SoC | 17:25 |
| _florent__ | In LiteX, a specific Wishbone region is allocated for CSRs and there is a Wishbone to CSR bridge to control the CSR bus (and then registers) | 17:26 |
| ambro718 | Is there any documentation for the litex CSR system? | 17:26 |
| ambro718 | what is the Wishbone to CSR bridge used for, is this between the CPU and the CSR system? | 17:27 |
| ambro718 | ... and then it goes to different cores? | 17:28 |
| somlo | ambro718: I recently had to tinker with it, and you might find the commit log of this candidate patch helpful: https://github.com/enjoy-digital/litex/commit/ce976d070534135216933b3c1622a8482f417464 | 17:29 |
| tpb | Title: [RFC - Do NOT Pull] Align MMIO/CSRs on 64-bit address boundary · enjoy-digital/litex@ce976d0 · GitHub (at github.com) | 17:29 |
| ambro718 | I am looking at soc_linux.py in linux-on-litex-vexriscv and I am confused how both the csr numbers (csr_map) and memory addresses (mem_map) are specified. | 17:30 |
| ambro718 | I would expect only memory addresses to be defined for each core and the framework would take care of the rest. | 17:31 |
| somlo | ambro718: not having seen linux-on-litex-vexriscv yet, I'll defer to _florent__ on that one; however, MMIO regions (specifically the CSR region) in the overarching map is or-ed with 0x80000000, so any memory (cacheable) accesses happen below that, and any MMIO (uncached) accesses happen above that address | 17:36 |
| somlo | within the CSR region (which ends up starting at 0xe0000000) each device gets a "bank" (i.e. a sub-range), and individual registers for that peripheral are grouped within that bank, in slices of up to 8bits that are addressable by an individual store or load CPU opcode | 17:37 |
| ambro718 | "below" you mean "at higher addresses"? | 17:39 |
| somlo | below == at lower addresses | 17:40 |
| somlo | 0...0x8000_0000 is assumed to be cached, 0x8000_0000 and above == uncached | 17:40 |
| ambro718 | Ok thanks for the explanation. But I am not connecting it with the soc_linux definitions at all, it seems to contradict what you said. https://github.com/enjoy-digital/linux-on-litex-vexriscv/blob/master/soc_linux.py#L25 | 17:41 |
| tpb | Title: linux-on-litex-vexriscv/soc_linux.py at master · enjoy-digital/linux-on-litex-vexriscv · GitHub (at github.com) | 17:41 |
| somlo | but the only uncached thing above 0x8000_0000 is the CSR (MMIO) register area starting at 0xE000_0000 (that I know of) | 17:41 |
| somlo | oh, that appears to be a different allocation scheme than what the litex repository uses by default | 17:43 |
| somlo | my numbers and examples use the defaults from here: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc_core.py#L169 | 17:44 |
| tpb | Title: litex/soc_core.py at master · enjoy-digital/litex · GitHub (at github.com) | 17:44 |
| ambro718 | somlo: why does the eth_max appear with its own address, why isn't it part of csr? | 17:45 |
| ambro718 | eth_mac | 17:45 |
| somlo | I *think* those are some sort of hardware tx/rx buffer space, different from actual config registers (but I invite _florent__ to kick me if what I just said is monumentally stupid :) | 17:46 |
| ambro718 | Yeah it has a separate wishbone interface for reading/writing packets. | 17:56 |
| _florent__ | ambro718: cores can have registers but also use memory regions | 17:58 |
| _florent__ | ambro718: the csr memory regions is shared for the CSRs of all cores | 17:58 |
| ambro718 | But why, why not have just one uniform way for CPU to access cores? | 17:59 |
| _florent__ | that's an architecture choice, to have a simple bus to control the cores | 18:06 |
| ambro718 | The CPU always uses wishbone for non-memory accesses, which then goes through the WB2CSR or core-specific WB interfaces? | 18:11 |
| _florent__ | that's correct to access CSRs, for core-specific WB interfaces, it's directly on the wishbone bus | 18:13 |
| ambro718 | Makes sense, thanks for explaining. | 18:14 |
| ambro718 | What is the simplest core that uses DMA? | 18:16 |
| ambro718 | I want to understand how DMA works in litex | 18:16 |
| _florent__ | ambro718: not sure i have an example to share for wishbone, but for litedram, you can look at that: https://github.com/enjoy-digital/litedram/blob/master/litedram/frontend/dma.py | 18:23 |
| tpb | Title: litedram/dma.py at master · enjoy-digital/litedram · GitHub (at github.com) | 18:23 |
| ambro718 | _florent__: I mean making a core write to or read from DRAM, is there not a single right way to do that? | 18:24 |
| _florent__ | ambro718: you can look at that: https://github.com/enjoy-digital/litedram/blob/fifo/litedram/frontend/fifo.py | 18:26 |
| tpb | Title: litedram/fifo.py at fifo · enjoy-digital/litedram · GitHub (at github.com) | 18:26 |
| _florent__ | ambro718: sorry, i have to go | 18:26 |
| ambro718 | okay thanks | 18:26 |
| *** tinyfpga_ has quit IRC | 19:01 | |
| ambro718 | I'm thinking about how to do DMA for Ethernet. I've come to the following schema: Ethernet core --(WB)--> L2 arbiter --> L2 cache --> DRAM. (L2 arbiter and L2 cache are part of soc_sdram.py) | 20:46 |
| ambro718 | Alternative way would be to go directly to DRAM with any of the available options bypassing the L2 | 20:47 |
| ambro718 | But that seems like a no-go due to cache incoherency problems. | 20:47 |
| ambro718 | I mean via calling sdram.crossbar.get_port() | 20:49 |
| ambro718 | Or is there some way to solve cache incoherency? | 20:49 |
| ambro718 | The non-ideal thing of going through L2 is that its WB interface has 32-bit data width which would result in suboptimal performance (the raw DRAM interfaces are wider e.g. 128-bit) | 20:50 |
| *** ambro718 has quit IRC | 22:05 | |
| *** tinyfpga has joined #litex | 22:33 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!