_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://libera.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #litex
Degi_ has joined #litex
Degi has quit [Ping timeout: 268 seconds]
Degi_ is now known as Degi
lambda has quit [Ping timeout: 260 seconds]
lambda has joined #litex
lexano has quit [Ping timeout: 248 seconds]
lexano has joined #litex
<_florent_> I just update the Discord invitation link to make it permanent: https://discord.gg/PkJwjDbxeG (but I don't think the previous one was expired)
<tpb> Title: LiteX (at discord.gg)
<cr1901> Will there be a bridge to IRC?
<cr1901> The discord-irc node package works fine IME, but I don't have a server to put it on
<_florent_> cr1901: I need to setup a server yes, probably on a Rapsberry Pi first, it would be fun to try to run it on Linux-on-LiteX-VexRiscv after :)
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
Brinx has quit [Ping timeout: 260 seconds]
<MoeIcenowy> somlo: okay I switched back to STLV7325 and SDCard with Rocket seems to work
nelgau_ has joined #litex
nelgau has quit [Ping timeout: 256 seconds]
<somlo> _florent_: you could always run it on Fedora ;)
Brinx has joined #litex
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
FabM has joined #litex
FabM has joined #litex
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #litex
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #litex
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #litex
Brinx has quit [Remote host closed the connection]
FabM has quit [Ping timeout: 256 seconds]
<geertu> somlo: Current litex-rebase hangs when starting userspace on my OrangeCrab, litex-rebase^ boots into userspace
<geertu> somlo: overriding the return value of platform_get_irq_optional() to zero to force polling makes it work again
<geertu> somlo: Always doing the timer setup in liteuart_startup() also makes it work
<geertu> Looks like the liteuart interrupt never fires:
<geertu> # cat /proc/interrupts
<geertu> 2: 0 SiFive PLIC 0 Edge liteuart
<geertu> CPU0
<geertu> 4: 0 litex-gpio 1 Edge B
<geertu> 3: 0 litex-gpio 2 Edge C
<geertu> 5: 42670 RISC-V INTC 5 Edge riscv-timer
<geertu> 6: 0 litex-gpio 0 Edge A
<geertu> A, B, and C are the GPIO switches on the Adafruit OLED Featherwing (https://www.adafruit.com/product/3045), which I also never got to work.
<somlo> geertu: so maybe the way the liteuart irq line is wired into the rest of the SoC is buggy in some way ?
<geertu> Perhaps there's an interrupt routing problem on OrangeCrab?
<somlo> yeah... so if you omit the liteuart irq from DT it should default to polling -- as a first-pass band aid
<somlo> having an irq number in DT wasn't doing anything before, anyway :)
<somlo> but LMK if you end up thinking it's a regression in the linux driver updates I'm working on...
<somlo> also (low likelihood, but since we're brainstorming) -- on Rocket I have to add 1 to each irq number generated by litex_json2dts_linux.py
<somlo> so maybe the actual irq number you have is off-by-one?
<somlo> like I said, grasping at straws, but might be worth ruling out :)
<geertu> somlo: You mean the interrupts to the PLIC?
<geertu> (thinking about adding the 1 inside Linux instead of flashing a new dtb)
<geertu> somlo: Do you know why Rocket has that issue? And why it wasn't fixed properly?
<somlo> so the "raw" litex IRQs are what they are, but I think inside the Rocket "box" (it also calls itself SoC :) there's a PLIC, and it reserves zero for itself or something (I am fuzzy on the actual details)
<somlo> and e.g. vexriscv takes raw litex interrupts, so for that the json2dts script is correct
<somlo> on rocket, due to the PLIC, the numbers have to be incremented by 1 -- and that's something I'll have to figure out once I add Rocket support to json2dts (which is vaguely on my to-do list, but is definitely not something that's supported ATM)
<somlo> so what Linux sees when running on rocket aren't the raw LiteX IRQ numbers
<somlo> LiteX assigns (on the boards I've been using) IRQ 0 to the uart
<somlo> but when building LiteX with Rocket, and loading linux, in my DTS I have
<somlo> liteuart0: serial@12009000 {
<somlo> compatible = "litex,liteuart";
<somlo> interrupts = <1>;
<somlo> interrupt-parent = <&L1>;
<somlo> reg = <0x12009000 0x100>;
<somlo> };
<somlo> and I *think* that's because there's also:
<somlo> L1: interrupt-controller@c000000 {
<somlo> compatible = "riscv,plic0";
<somlo> #interrupt-cells = <1>;
<somlo> interrupt-controller;
<somlo> interrupts-extended = <&L4 11 &L4 9 &L14 11 &L14 9 &L24 11 &L24 9 &L34 11 &L34 9>;
<somlo> reg = <0xc000000 0x4000000>;
<somlo> reg-names = "control";
<somlo> riscv,max-priority = <7>;
<somlo> riscv,ndev = <8>;
<somlo> };
<somlo> (which comes from rocket's chisel-elaborated dts, generated alongside the verilog code)
<somlo> and which I've got to somehow cut'n'paste from when adding json2dts support to litex :)
<geertu> somlo: Tried oirq.args[0]++ in of_irq_get(), but it doesn't help
mewt has quit [Read error: Connection reset by peer]
jevinskie[m] has joined #litex
<somlo> geertu: then it's probably in the gateware, somewhere...
<jersey99> _florent_ .. this is the example I am talking about FYI. https://pastebin.com/SrSPeibF
<tpb> Title: test sim litex - Pastebin.com (at pastebin.com)
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #litex
nelgau_ has quit []
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #litex