| *** tpb has joined #litex | 00:00 | |
| *** futarisIRCcloud has joined #litex | 01:10 | |
| xobs | _florent_: is there any way to fix the CSR offsets? I'd like to make sure they don't move around. | 02:21 |
|---|---|---|
| futarisIRCcloud | _florent_ : Looks like antmicro were using a hacked version of u-boot (32bit) for Linux RISC-V. | 02:24 |
| futarisIRCcloud | https://github.com/antmicro/RV32_U-Boot/commits/32bit | 02:24 |
| tpb | Title: Commits · antmicro/RV32_U-Boot · GitHub (at github.com) | 02:24 |
| futarisIRCcloud | https://buildmedia.readthedocs.org/media/pdf/risc-v-getting-started-guide/latest/risc-v-getting-started-guide.pdf | 02:51 |
| futarisIRCcloud | _florent_ / mithro: So I modified litex-buildenv/scripts/build-qemu.sh to build qemu-v4.0.0 for vexriscv & riscv32. I just need to pull the models for litex into that tree, and we should be able to boot BIOS & zepyhr in qemu... | 05:28 |
| _florent_ | xobs: yes it's possible, i also have the same need for some projects (for example keep software compatibility on pcie boards) | 05:31 |
| _florent_ | xobs: i'll give you that in ~1hour when i'll be at the office | 05:31 |
| xobs | _florent_: thanks! no hurry. | 05:31 |
| _florent_ | futarisIRCcloud: thanks for links! (and the previous one), great for qemu | 05:33 |
| _florent_ | futarisIRCcloud: i'll work on getting Linux working today | 05:34 |
| mithro | futarisIRCcloud: we really should get a lot of that qemu stuff upstream... | 05:35 |
| futarisIRCcloud | mithro: Yeah. Probably worth adding a valentyusb model too... | 05:36 |
| keesj | qemu is a fast moving target | 05:36 |
| mithro | futarisIRCcloud: can you send the patches to the build-qemu.sh as a pull request so I can merge? | 05:37 |
| futarisIRCcloud | mithro: Will do, as soon as I get the BIOS running. | 05:37 |
| mithro | Should poke shenki and stafford more about the qemu upstreaming stuff... | 05:38 |
| _florent_ | xobs: if you want to have fixed CSR offsets, you can define you CSRs like that: https://hastebin.com/huyozibawe.py | 07:33 |
| xobs | _florent_: ah, I see! I didn't realize it was a dict of ints. That makes much more sense. | 07:35 |
| futarisIRCcloud | Well, I got qemu 4.0.0 compile. Can't seem to get litex machine to appear in the "-machine help" list though... | 08:15 |
| futarisIRCcloud | Oops. left litex.o out of hw/riscv/Makefile.objs ... | 08:54 |
| futarisIRCcloud | _florent_ : How are interrupts hooked up to vexriscv? | 09:15 |
| _florent_ | https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/cpu/vexriscv/core.py#L36 | 09:22 |
| tpb | Title: litex/core.py at master · enjoy-digital/litex · GitHub (at github.com) | 09:22 |
| _florent_ | it's using a specific plugin (externalInterruptArray) that is not used by the others configurations | 09:23 |
| futarisIRCcloud | https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/cpu/lm32/core.py#L32 - lm32 | 09:36 |
| tpb | Title: litex/core.py at master · enjoy-digital/litex · GitHub (at github.com) | 09:36 |
| futarisIRCcloud | https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/cpu/mor1kx/core.py#L20 - openrisc | 09:36 |
| tpb | Title: litex/core.py at master · enjoy-digital/litex · GitHub (at github.com) | 09:36 |
| futarisIRCcloud | and in qemu: | 09:39 |
| futarisIRCcloud | https://github.com/timvideos/qemu-litex/blob/master/hw/lm32/litex.c#L99 | 09:39 |
| tpb | Title: qemu-litex/litex.c at master · timvideos/qemu-litex · GitHub (at github.com) | 09:39 |
| futarisIRCcloud | https://github.com/timvideos/qemu-litex/blob/master/hw/openrisc/litex.c#L81 | 09:40 |
| tpb | Title: qemu-litex/litex.c at master · timvideos/qemu-litex · GitHub (at github.com) | 09:40 |
| futarisIRCcloud | mithro: https://github.com/futaris/litex-buildenv/commits/build-qemu-vexriscv - litex-buildenv side is fairly straightforward | 10:00 |
| tpb | Title: Commits · futaris/litex-buildenv · GitHub (at github.com) | 10:00 |
| futarisIRCcloud | https://github.com/futaris/qemu/tree/v4.0.0-litex - still needs some work | 10:00 |
| tpb | Title: GitHub - futaris/qemu at v4.0.0-litex (at github.com) | 10:00 |
| futarisIRCcloud | https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/include/base/irq.h | 10:21 |
| tpb | Title: litex/irq.h at master · enjoy-digital/litex · GitHub (at github.com) | 10:21 |
| futarisIRCcloud | So RISC-V just uses the machine interrupt, and triggers off an external PIC / PLIC ... | 10:23 |
| futarisIRCcloud | I guess we should make separate qemu models for each of the RISC-V processors that litex supports. | 10:23 |
| futarisIRCcloud | https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/libbase/crt0-picorv32.S does look like fun. | 10:40 |
| tpb | Title: litex/crt0-picorv32.S at master · enjoy-digital/litex · GitHub (at github.com) | 10:40 |
| keesj | ARRGGG this serdes is to complicated for my knowledge | 13:59 |
| keesj | I am mostly been looking at serwb (liteiclink) perhaps I need to get that one working first on arty or xsim | 14:02 |
| somlo | so for wishbone .adr, there are only 30 bits, and the least significant two extra bits are implicitly assumed to be 0 -- is that correct? | 14:28 |
| somlo | * in LiteX's version of wishbone, specifically. The third-party IP I'm using has 32 bits, so I'd need to wire the least significant two of them to 0 myself, if I'm right about the above | 14:29 |
| keesj | well. that would sounds ackward if 2 bits are not used why would you need to write them? | 14:31 |
| somlo | keesj: assuming w/o having thoroughly RTFM-ed: if a fully "agnostic" wb interface would have to allow individual bytes to be addressed, it would need 32 bits for the address; however, if our application (CPUs accessing 32 bits at once) guarantees that the least significant two will always be 0, we can just implicitly assume what they'd be, and not carry them around as explicit wires | 14:34 |
| _florent_ | somlo: in LiteX wishbone adr is in words | 14:34 |
| _florent_ | (4 bytes) | 14:34 |
| somlo | _florent_: thanks, just wanted to be 100% sure :) | 14:35 |
| keesj | https://zipcpu.com/zipcpu/2017/05/29/simple-wishbone.html is nice for learning about wishbone | 14:36 |
| tpb | Title: Building a simple wishbone slave (at zipcpu.com) | 14:36 |
| keesj | hmm same site but other page .. let me search | 14:36 |
| somlo | keesj: so since I'm using a third-party IP block for axi2wb, its wb side has 32 wires, since it's probably generic and can't assume 4-byte granularity | 14:36 |
| somlo | keesj: so I have to hard-wire those two bits to 0, and connect the rest of them to LiteX's 30 bits, and (fingers crossed), things will magically start working (famous last words) :) | 14:38 |
| keesj | last words before the stuff exploded | 14:39 |
| xobs | That 30-bit bus idea is weird. I see why it's done that way, but it still throws me off a lot of the time. | 15:27 |
| somlo | Hmmm... Using https://bitbucket.org/danstrother/dls_cores/src/beb677ea1919ea2cec984426e1f8d89ec21b03a7/axi/rtl/dlsc_axi_to_wb.v to wrap Rocket before down-converting wishbone from 64->32 bits fails exactly the same as when I was using LiteX's own native axi2wb bridge :( | 16:22 |
| tpb | Title: danstrother / dls_cores / source / axi / rtl / dlsc_axi_to_wb.v Bitbucket (at bitbucket.org) | 16:22 |
| somlo | and Dan Strother's bridge claims support for INCR bursting, so it's not that | 16:23 |
| somlo | the assertion is from deep within Rocket's sources: "Assertion failed at UserYanker.scala:54 assert (!out.r.valid || r_valid) // Q must be ready faster than the response" | 16:24 |
| somlo | now if only I could find some way to understand WTF "UserYanker" does in Rocket's AXI implementation :) | 16:24 |
| keesj | perhaps this was somebody else his last lines of code.. who knows | 19:14 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!