| *** tpb has joined #litex | 00:00 | |
| *** CarlFK has joined #litex | 00:05 | |
| *** CarlFK has quit IRC | 02:07 | |
| *** _whitelogger has quit IRC | 02:27 | |
| *** disasm[m] has quit IRC | 02:27 | |
| *** _whitelogger has joined #litex | 02:33 | |
| *** disasm[m] has joined #litex | 02:33 | |
| *** _whitelogger has quit IRC | 02:35 | |
| *** _whitelogger has joined #litex | 02:41 | |
| *** jaseg has quit IRC | 02:45 | |
| *** jaseg has joined #litex | 02:47 | |
| *** FFY00 has quit IRC | 02:50 | |
| *** FFY00 has joined #litex | 02:50 | |
| *** Degi has quit IRC | 02:59 | |
| *** Degi has joined #litex | 03:00 | |
| *** CarlFK has joined #litex | 03:37 | |
| *** _whitelogger has quit IRC | 04:06 | |
| *** _whitelogger has joined #litex | 04:08 | |
| *** m4ssi has joined #litex | 08:18 | |
| ranzbak | I'm struggeling with Litevideo code, and I can't really find documentation using Google, is there documentation available how to build a RGB -> video pipeline -> DDR3 ram -> VGA out? | 09:11 |
|---|---|---|
| *** jaseg has quit IRC | 09:22 | |
| *** jaseg has joined #litex | 09:24 | |
| acathla | How do I know which part of a litex design is taking which amount of LC, BRAM, etc? | 10:05 |
| zyp | compare the numbers with a given part disabled or enabled? | 10:09 |
| acathla | zyp, that's a solution but a bit limited as some blocks can't be enabled alone | 10:16 |
| zyp | the problem is that the whole hierarchy of migen modules reduces into a single verilog module | 10:26 |
| zyp | external cores like the cpus and so on will still be their own modules, so they'll show up in the statistics | 10:26 |
| acathla | If I can output a verilog for a module, like an uart+phy, how can I synthetise it to know the LC usage? | 10:29 |
| zyp | I guess you could pull out part of the design, turn it into a standalone verilog module and then put it back in as an external module | 10:29 |
| acathla | Is that normal that a simple UART+UARTPhy takes 564 LC? | 10:34 |
| daveshah | I think high UART resource usage has previously been caused by the FIFOs not mapping to BRAM | 10:35 |
| daveshah | You could reduce the FIFO depth from 16 to 1/2 and see if that reduces resource usage | 10:35 |
| lkcl | hmmm, when generating the ls180 ASIC verilog i'm getting GPIO tristates being declared as inputs, SDRAM address as output reg and many other oddities | 11:00 |
| lkcl | output reg [12:0] sdram_a | 11:00 |
| lkcl | SDRAM address pins are not outputs! | 11:01 |
| daveshah | > SDRAM address pins are not outputs | 11:02 |
| daveshah | really? | 11:02 |
| lkcl | err... | 11:04 |
| lkcl | outputs from a _chip_ i wouldn't have expected them to be | 11:05 |
| lkcl | outputs from the *peripheral* i would expect them to be | 11:05 |
| daveshah | huh? | 11:06 |
| daveshah | they are outputs from the SoC and inputs to the SDRAM | 11:06 |
| lkcl | outputs from the SoC... *smack* yes of course | 11:06 |
| lkcl | doh | 11:06 |
| lkcl | this still leaves GPIOTristate as being declared as input | 11:07 |
| daveshah | yeah, not sure about that one | 11:07 |
| lkcl | input wire [11:0] gpio_io, | 11:07 |
| lkcl | things that are "inout" that work successfully are SDRAM and SDMMC | 11:07 |
| daveshah | ime, unexpected inputs with litex are usually when the pin is accidentally unused | 11:08 |
| daveshah | Has the tristate logic been generated correctly? | 11:08 |
| lkcl | 1 sec let me check | 11:08 |
| lkcl | assign main_gpio_pads[0] = main_gpio_tstriple0_oe ? main_gpio_tstriple0_o : 1'bz; | 11:08 |
| lkcl | assign main_gpio_tstriple0_i = main_gpio_pads[0]; | 11:09 |
| lkcl | yes that looks like tristate. | 11:09 |
| lkcl | it looks exactly like sdcard_cmd | 11:09 |
| lkcl | litesdcard phy does this: | 11:10 |
| lkcl | # Cmd | 11:10 |
| lkcl | self.specials += SDRTristate( | 11:10 |
| lkcl | GPIOTristate uses TSTriple | 11:12 |
| lkcl | where SDRTristate uses Tristate | 11:13 |
| lkcl | and TSTriple has get_tristate which returns Tristate | 11:14 |
| lkcl | so i'm not seeing anything obvious that would cause gpio pins to be declared input where sdcard_cmd is correctly inout | 11:14 |
| lkcl | _florent_, any ideas? | 11:16 |
| lkcl | ahh i have a clue | 11:19 |
| lkcl | SDRTristate | 11:19 |
| lkcl | def iter_expressions(self): | 11:19 |
| lkcl | yield self, "io", SPECIAL_INOUT | 11:19 |
| lkcl | ngggh that's likely it. | 11:20 |
| lkcl | migen Specials detects that back in Special.list_io | 11:20 |
| lkcl | urrr i have a horrible-hack idea, but it would make a mess of the CSRs... | 11:23 |
| lkcl | use SDRTristate for GPIO :) | 11:23 |
| lkcl | arg arg i'm going to have to hack something together, a hybrid combination of GPIOTristate and SDCard CMD | 11:25 |
| acathla | daveshah, from 8 to 16 bytes fifo, it's an increase of 33 LC | 11:39 |
| acathla | and 2 ICESTORM_RAM to 3 | 11:40 |
| somlo | so here's something a bit weird: 64-bit rocketchip based LiteX SoC running a stock linux kernel (with drivers for litex gateware as the only modification) | 13:58 |
| somlo | I went with some silly low number for "timebase-frequency" in the DTS: e.g., 1000000 | 13:58 |
| somlo | recently, I decided to make that number reflect the *real* clock speed I'm using on the nexys4ddr: 75000000 | 13:59 |
| somlo | and as a result, I can barely type on the tty, and running `date` will advance by a second about every minute or so... | 13:59 |
| somlo | so I am wondering if I need to tell linux about some custom HZ related configuration -- this ring any bells to anyone? | 14:00 |
| sorear | the timebase-frequency in the DTS needs to match the rate at which mtime/mtimecmp are incremented | 14:11 |
| *** jaseg has quit IRC | 14:19 | |
| *** jaseg has joined #litex | 14:21 | |
| somlo | sorear: thanks -- that makes me think there should probably be another DT variable besides timebase-frequency that indicates the main sys_clock, and/or some sort of relationship between it and timebase-frequency | 15:04 |
| somlo | at least now I know the basic idea of what I'm looking for (back-story is that the current litesdcard driver proposed by antmicro uses timebase-frequency in lieu of the overall system clock when computing the divider for clocking the sdcard) | 15:06 |
| somlo | and now I suspect that timebase-frequency should *not* be assumed to be the same thing as the overall SoC clock generator, but something *based* on that that's internal to the CPU | 15:07 |
| *** proteusguy has quit IRC | 15:11 | |
| somlo | so, according to https://github.com/torvalds/linux/blob/master/Documentation/devicetree/booting-without-of.rst#L940 | 15:17 |
| tpb | Title: linux/booting-without-of.rst at master · torvalds/linux · GitHub (at github.com) | 15:17 |
| somlo | a cpu could also have a `clock-frequency` cell, which would be the more appropriate thing to use to refer to the raw clock frequency | 15:18 |
| somlo | but even more appropriate would be to use a `bus-frequency` cell in the soc node: https://github.com/torvalds/linux/blob/master/Documentation/devicetree/booting-without-of.rst#L1043 | 15:19 |
| tpb | Title: linux/booting-without-of.rst at master · torvalds/linux · GitHub (at github.com) | 15:19 |
| somlo | _florent_: what do you think, the "75MHz" of a litex SoC on nexys4ddr, should that go under the CPU node as `clock-frequency`, under the soc node as `bus-frequency`, or more likely *both* ? | 15:21 |
| somlo | it should definitely *not* be the cpu node's `timebase-frequency`, as my experience shows :) | 15:21 |
| somlo | _florent_: we're talking about the `CONFIG_CLOCK_FREQUENCY` in generated/soc.h, to be precise | 15:23 |
| *** proteusguy has joined #litex | 15:23 | |
| *** m4ssi has quit IRC | 16:04 | |
| Finde | somlo: here's how it's done for ariane's dts: https://github.com/openhwgroup/cva6/blob/master/bootrom/ariane.dts | 16:42 |
| tpb | Title: cva6/ariane.dts at master · openhwgroup/cva6 · GitHub (at github.com) | 16:42 |
| Finde | CPU0 has clock-frequency and cpus has timebase-frequency | 16:43 |
| Finde | and uart has its own clock-frequency | 16:43 |
| somlo | Finde: thanks! At this point, the remaining question is whether the LiteX `CONFIG_CLOCK_FREQUENCY` value should become clock-frequency on (each of the) CPU(s) or bus-frequency on the SoC node, or both | 17:09 |
| somlo | and once that's decided, I can modify the litesdcard driver proposed here [*] to grab it from the appropriate location in DT (because we've established that using timebase-frequency is wrong) | 17:12 |
| somlo | [*] https://github.com/litex-hub/linux/commit/7ee130ea590f30b89f3621b82ca54cd343aa5dd9 | 17:12 |
| tpb | Title: litex_mmc: Update to the DMA-based version of the core · litex-hub/linux@7ee130e · GitHub (at github.com) | 17:12 |
| somlo | specifically, here: https://github.com/litex-hub/linux/blob/wip/litex-vexriscv--linux5.0_sd_card_dma/drivers/mmc/host/litex_mmc.c#L515 | 17:15 |
| tpb | Title: linux/litex_mmc.c at wip/litex-vexriscv--linux5.0_sd_card_dma · litex-hub/linux · GitHub (at github.com) | 17:15 |
| *** conmega has quit IRC | 19:10 | |
| *** conmega has joined #litex | 19:10 | |
| *** peeves57 has joined #litex | 20:09 | |
| st-gourichon-fid | Hi everyone. Is it normal that https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/cpu/serv/irq.h is empty? Could it mean "not done", or "SERV does not support interrupts"? That prevents us from running C code on the softcore from this gist provided by _florent_ https://gist.github.com/enjoy-digital/82ed88b77ef0b1e3e91b0592e44eaa14 | 20:46 |
| tpb | Title: litex/irq.h at master · enjoy-digital/litex · GitHub (at github.com) | 20:46 |
| Finde | I didn't think that serv had interrupts | 20:48 |
| *** flammit has quit IRC | 20:50 | |
| *** Claude has quit IRC | 20:50 | |
| st-gourichon-fid | Finde, mmh, SERV's github does mention "irq" though not a lot. | 20:50 |
| *** alanvgreen has quit IRC | 20:50 | |
| *** Claude has joined #litex | 20:50 | |
| *** futarisIRCcloud has quit IRC | 20:51 | |
| *** alanvgreen has joined #litex | 20:51 | |
| *** tannewt has quit IRC | 20:51 | |
| *** tucanae47 has quit IRC | 20:51 | |
| *** bubble_buster has quit IRC | 20:51 | |
| *** key2 has quit IRC | 20:51 | |
| st-gourichon-fid | We tried to just remove mentions in C code, but crt0 does mention interrupts. I guess it's because few people actually use SERV so the path has to be somehow cleared up... ? | 20:52 |
| *** tucanae47 has joined #litex | 20:52 | |
| *** key2 has joined #litex | 20:52 | |
| *** flammit has joined #litex | 20:52 | |
| *** tannewt has joined #litex | 20:52 | |
| *** futarisIRCcloud has joined #litex | 20:53 | |
| *** bubble_buster has joined #litex | 20:53 | |
| Finde | "SERV only implement the bits required for ecall, ebreak, misalignment and timer interrupts" | 20:54 |
| Finde | from its manual | 20:54 |
| st-gourichon-fid | Mfmfmf, indeed https://serv.readthedocs.io/en/latest/#serv-csr | 21:06 |
| tpb | Title: SERV user manual SERV documentation (at serv.readthedocs.io) | 21:06 |
| *** carlomaragno has quit IRC | 22:50 | |
| *** guan has quit IRC | 22:50 | |
| *** pdp7 has quit IRC | 22:50 | |
| *** mithro has quit IRC | 22:50 | |
| *** daveshah has quit IRC | 22:50 | |
| *** sorear has quit IRC | 22:50 | |
| *** Claude has quit IRC | 22:50 | |
| *** _florent_ has quit IRC | 22:50 | |
| *** key2 has quit IRC | 22:50 | |
| *** alanvgreen has quit IRC | 22:50 | |
| *** tucanae47 has quit IRC | 22:50 | |
| *** tannewt has quit IRC | 22:51 | |
| *** flammit has quit IRC | 22:51 | |
| *** carlomaragno has joined #litex | 22:51 | |
| *** guan has joined #litex | 22:51 | |
| *** daveshah has joined #litex | 22:51 | |
| *** sorear has joined #litex | 22:52 | |
| *** alanvgreen has joined #litex | 22:52 | |
| *** futarisIRCcloud has quit IRC | 22:52 | |
| *** y2kbugger has quit IRC | 22:53 | |
| *** tannewt has joined #litex | 22:53 | |
| *** Claude has joined #litex | 22:53 | |
| *** rohitksingh has quit IRC | 22:53 | |
| *** key2 has joined #litex | 22:53 | |
| *** _florent_ has joined #litex | 22:54 | |
| *** pdp7 has joined #litex | 22:54 | |
| *** y2kbugger has joined #litex | 22:54 | |
| *** mithro has joined #litex | 22:54 | |
| *** futarisIRCcloud has joined #litex | 22:54 | |
| *** tucanae47 has joined #litex | 22:54 | |
| *** rohitksingh has joined #litex | 22:56 | |
| *** flammit has joined #litex | 22:57 | |
| *** bubble_buster has quit IRC | 22:57 | |
| *** bubble_buster has joined #litex | 23:01 | |
| *** lf has quit IRC | 23:22 | |
| *** lf has joined #litex | 23:23 | |
| *** CarlFK has quit IRC | 23:46 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!