| *** tpb has joined #litex | 00:00 | |
| *** lf_ has quit IRC | 00:33 | |
| *** lf has joined #litex | 00:33 | |
| *** futarisIRCcloud has joined #litex | 02:33 | |
| *** Degi_ has joined #litex | 03:25 | |
| *** Degi has quit IRC | 03:26 | |
| *** Degi_ is now known as Degi | 03:26 | |
| *** Bertl_oO is now known as Bertl_zZ | 03:34 | |
| *** futarisIRCcloud has quit IRC | 04:42 | |
| *** tpb has joined #litex | 05:27 | |
| *** _whitelogger has quit IRC | 05:48 | |
| *** _whitelogger has joined #litex | 05:50 | |
| *** SpaceCoaster_ has quit IRC | 06:06 | |
| *** SpaceCoaster has joined #litex | 06:06 | |
| *** skiphs has joined #litex | 08:07 | |
| *** skiphs has quit IRC | 08:25 | |
| *** Bertl_zZ is now known as Bertl | 10:38 | |
| *** kgugala has quit IRC | 11:34 | |
| *** Melkhior has joined #litex | 11:35 | |
| Melkhior | Hello again:-) Another week-end another question; this time it relates to clocks - why is 'cd_idelay' (used to drive an IDELAYCTRL block if I understand correctly) fixed at 200 MHz for DDR3 and 500 MHz at DDR4 (or so it seems from grep'ing the targets file) ? It that a hard requirement ? Could it be a multiple of the core and/or reference | 12:06 |
|---|---|---|
| Melkhior | frequency ? | 12:06 |
| Melkhior | Currently this fixed 200 MHz frequency prevent me to fine-tune the frequency of my cores, as the S7MMCM fails to find parameters in most cases. So I can use a core at 100 MHz or 83.333 from my 48 MHz reference, but not 96 MHz. And I've added so much stuff in the decoder it won't pass timings at 100 Mhz anymore :-) | 12:06 |
| Melkhior | On the other hand, if I set the cd_idelay clock to 192 MHz (exactly 4x the reference clock), then the S7MMCM seems much more tolerant, as the parameters are much easier to compute... | 12:06 |
| *** pdp7 has quit IRC | 12:10 | |
| *** dayjaby has joined #litex | 12:11 | |
| dayjaby | Hi:) how to set breakpoints reliably for a LiteX cpu? currently trying to run zephyr on arty a7-35t + vexriscv. I tried: | 12:16 |
| dayjaby | (gdb) break console_out | 12:16 |
| dayjaby | (gdb) c | 12:16 |
| dayjaby | Continuing. | 12:16 |
| dayjaby | << here I restart litex_term to flash zephyr.bin >> | 12:16 |
| dayjaby | Note: CPU is currently in a trap: Misaligned load address of 0x00010005 at 0x40001d28 | 12:16 |
| dayjaby | 40001d08 <console_out>: | 12:16 |
| dayjaby | 40001d08: ff010113 addi sp,sp,-16 | 12:16 |
| dayjaby | 40001d0c: 400037b7 lui a5,0x40003 | 12:16 |
| dayjaby | 40001d10: 00812423 sw s0,8(sp) | 12:16 |
| dayjaby | 40001d14: 00112623 sw ra,12(sp) | 12:16 |
| dayjaby | 40001d18: 00050413 mv s0,a0 | 12:16 |
| dayjaby | 40001d1c: 7807a503 lw a0,1920(a5) # 40003780 <uart_console_dev> | 12:16 |
| dayjaby | 40001d20: 00852783 lw a5,8(a0) | 12:16 |
| dayjaby | 40001d24: 0ff47593 andi a1,s0,255 | 12:16 |
| dayjaby | 40001d28: 0047a783 lw a5,4(a5) | 12:16 |
| dayjaby | It seems like the breakpoint gets ignored | 12:16 |
| *** Melkhior has quit IRC | 12:57 | |
| *** dayjaby has quit IRC | 12:57 | |
| *** Melkhior has joined #litex | 13:25 | |
| *** dayjaby has joined #litex | 13:54 | |
| dayjaby | --============= Liftoff! ===============-- | 13:54 |
| dayjaby | *** Booting Zephyr OS build zephyr-v2.4.0-2710-g5358a11687a3 *** | 13:54 |
| dayjaby | Hello World! litex_vexriscv | 13:54 |
| dayjaby | Got it working! | 13:54 |
| *** kgugala has joined #litex | 15:06 | |
| *** Bertl is now known as Bertl_oO | 15:13 | |
| *** dayjaby has quit IRC | 16:56 | |
| *** Melkhior has quit IRC | 16:57 | |
| *** skiphs has joined #litex | 18:12 | |
| geertu | Does anyone know which board from litex-boards was tested with microwatt? | 19:50 |
| geertu | with orangecrab, if fails with | 19:50 |
| geertu | AttributeError: 'Microwatt' object has no attribute 'interrupt' | 19:50 |
| geertu | So I'd thought to ask first, before I dive deeper... | 19:51 |
| geertu | s/if fails/it fails/, ofc | 19:51 |
| zyp | benh can probably answer that | 20:00 |
| *** skiphs has quit IRC | 20:11 | |
| tcal | dayjaby: the debug vexriscv pre-built for use with litex has no hardware breakpoints, while gdb / wishbone-tool assumes the hw breakpoints are there. Can you coerce GDB to use SW breakpoints (replace the instruction at the breakpoint with a trap instruction)? Otherwise, you can rebuild vexriscv with the hw breakpoint support, although you'll need to install sbt (the scala build tool). Let me know if you want to go | 21:23 |
| tcal | that route... | 21:23 |
| *** Finde has quit IRC | 23:46 | |
| *** Finde has joined #litex | 23:47 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!