| *** tpb has joined #litex | 00:00 | |
| *** Degi has quit IRC | 00:15 | |
| *** Degi has joined #litex | 00:16 | |
| *** jon_ has quit IRC | 00:21 | |
| somlo | jon_: the trellisboard is not available via *retail* -- the idea is you contract with a PCB manufacturer to have the design at https://github.com/gatecat/TrellisBoard custom made, so that's probably not what you want. If you want to stay on the Free/Libre side of things with ECP5, then the lambdaconcept ECPIX5 board (make sure it's the 85k version) is your best bet. They are occasionally sold out, so check back with them every week or two | 00:25 |
|---|---|---|
| somlo | jon_: also, the latest, most up-to-date build instructions are at https://github.com/litex-hub/linux-on-litex-rocket (there should be a link to that on the cmu page, somewhere) | 00:26 |
| somlo | oh crap, he quit... :) | 00:27 |
| *** pftbest_ has joined #litex | 00:32 | |
| *** pftbest has quit IRC | 00:33 | |
| *** jon_ has joined #litex | 01:22 | |
| *** jon_ has quit IRC | 01:36 | |
| *** Bertl is now known as Bertl_zZ | 04:25 | |
| *** TMM has quit IRC | 04:41 | |
| *** TMM has joined #litex | 04:41 | |
| *** Melkhior has joined #litex | 06:11 | |
| nickoe | How can I make the --load arg to the programmer use the running jtag connection of the litex_server? Having to stop it every time I need to load the bitstream is a bit tedious for me, I assume there is a way to make it use the litex_server. | 06:26 |
| geertu | Melkhior: feel free to complain to the people that removed hardware accelerated console support... | 06:48 |
| Melkhior | @geertu I can already guess the answer... "put up or shut up", and I don't have the time to maintain fbcon... | 08:53 |
| Melkhior | too bad, that was the one part of Linux where I had contributed (wrote an accelerated driver waaaaaaaaaay back to get a decent console in PPC Linux for my PowerMac 7500) | 08:54 |
| Melkhior | idly wondering whether you can expose some acceleration feature through fbdev that could be used in X11 | 08:55 |
| Melkhior | first I have to finish compiling X11 on my SoC :-) | 08:56 |
| Melkhior | @geertu In the 'weird idea' category ... ever thought if a M68K core (from the numerous recreation project for Atari/Amiga/Mac/...) could be integrated in Litex so we could get some NetBSD/68k with somewhat higher performance than the 'real thing' ? No idea whether any open FPGA softcore supports SMP though, which is kind of useful nowadays. | 09:04 |
| Melkhior | (I'd suggest SPARC but Columbia's ESP soft-SoC supports LEON in SMP already:-) ) | 09:04 |
| zyp | SMP as in vexriscv-SMP? | 09:05 |
| _florent_ | Melkhior: For the DMA, there is also some WishboneDMA modules that could be easier to operate: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/dma.py | 09:06 |
| _florent_ | Also you don't need to do everything in the fabric, the DMA have optional CSRs to allow software control | 09:06 |
| _florent_ | this way in the SoC you only have to connect the DMAReader.source to the DMAWriter.sink: ex: dma_reader.source.connect(dma_writer.sink) | 09:07 |
| _florent_ | you can also provide default values for all or some of the CSRs (useful for example if you are always doing the accesses are fixed addresses, with fixed lengths, etc... ), in this case, the software intervention can be limited to enable th transfer | 09:09 |
| _florent_ | This is used for example for in the VideoFramebuffer: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/video.py#L605-L613 | 09:10 |
| _florent_ | The software then just has to enable the DMA: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/bios/main.c#L168-L174 | 09:11 |
| Melkhior | @zyp yes, as in having multiple cores: | 09:11 |
| Melkhior | (dolbeau)buildroot:~> lscpu | 09:11 |
| Melkhior | Architecture: riscv32 | 09:11 |
| Melkhior | Byte Order: Little Endian | 09:11 |
| Melkhior | CPU(s): 4 | 09:11 |
| Melkhior | On-line CPU(s) list: 0-3 | 09:11 |
| Melkhior | Thread(s) per core: 4 | 09:11 |
| Melkhior | Core(s) per socket: 1 | 09:11 |
| Melkhior | Socket(s): 1 | 09:11 |
| Melkhior | L1d cache: 8 KiB | 09:11 |
| Melkhior | L1i cache: 8 KiB | 09:11 |
| _florent_ | Melkhior: BTW, Charles is working on a USB Host core and already got keyboard, mouse and usb stick working, this will be useful for the single board computer case :) | 09:16 |
| Melkhior | _florent_ Thanks for the pointers; the goal was to be able to do rectangle/copy - write the (x,y) origin point, the (width, height) of the rectangle, and the (x',y') destination point in CSRs and then let the DMAs do the 'copy' (and if there's overlaps it gets complicated) . The address generators would use the CSRs value to generate two streams | 09:17 |
| Melkhior | of addresses to feed to the two back-to-back DMAs. The driver would then just have to write in the CSRs (+ some 'start bit') when a copy is needed. | 09:17 |
| Melkhior | Many moons ago it would have enabled the Linux console to have hardware scrolling... | 09:17 |
| Melkhior | _florent_ oh nice; but none of my boards have USB PHYs which is why I went with PS/2 | 09:18 |
| Melkhior | Other might in the same case so maybe there's still some value there ? | 09:18 |
| Melkhior | I ordered myself a splitter cable to see if I can get two PS/2 devices from the same PMod and add mouse support as well, if i ever find a PS/2 mouse | 09:18 |
| Melkhior | but indeed USB is probably the best way :-) | 09:19 |
| _florent_ | Melkhior: OK I see for the DMA. The easier for that will probably then to use the WishboneDMAWriter/Reader without the CSRs, still connect them together, but have your own logic to generate the addresses/handle the software control | 09:20 |
| geertu | Melkhior: Of course I thought about that ;-) It's a pity the APOLLO CORE 68080 is not FLOSS | 09:22 |
| zyp | _florent_, the other day I did some litescope probing across my nmigen wrapper: https://paste.jvnv.net/view/flGJB | 09:24 |
| tpb | Title: JVnV Pastebin View paste – Untitled (at paste.jvnv.net) | 09:24 |
| cr1901_modern | The maintainers of 68k userland have gotten projects like Clang and Boost to compile in QEMU VMs | 09:24 |
| Melkhior | _florent_ As usual the issue will be software:-) | 09:24 |
| Melkhior | I have a nice hw-accelerated AES-256-GCM in FPGA for my SPARCstation, and no good software support in NetBSD - OpenSSL doesn't use the kernel support for GCM (and is buggy for CTR, different interface), so I'm stuck with CBC (which is disabled by default in SSL); then I discovered SSH support is broken (SSL opens the driver device, then SSH closes | 09:24 |
| Melkhior | all FD >= 3 ...) | 09:24 |
| Melkhior | Now the hardware console is gone in Linux... | 09:24 |
| geertu | Melkhior: I used to have an accelerated X server on ATI RAGE II+, using the MMIO region exposed by atyfb | 09:26 |
| Melkhior | @geertu yes it seems most of the FLOSS cores are 68000 only, and you really want 68020+68851 or 68030 minimum | 09:27 |
| Melkhior | @geertu Xorg has become quite bloated, not sure if you can still use only very basic acceleration (and not need a full-fledged GL support:-( ) | 09:29 |
| Melkhior | @_florent_ BTW it's mixed with my other changes, but I will try to clean-up my patch to add cache information in the DTS (so lscpu see the VexRiscv caches as shown above) | 09:31 |
| Melkhior | cr1901_modern Yes Qemu is often the right answer - pkgsrc on NetBSD/sparc is easier to deal with in emulation than on the real thing, mostly because I/O is much, much faster and you can have more memory | 09:35 |
| geertu | Melkhior: Indeed, the new qemu m68k has 3.2 GiB, my vexriscv on OrangeCrab has only 128 MiB ;-) | 09:50 |
| Melkhior | @geertu have you considered a VCU128 ? plenty of memory and you should be able to fit a lot of cores :-) | 09:56 |
| Melkhior | https://www.xilinx.com/products/boards-and-kits/vcu128.html | 09:57 |
| Melkhior | it's bit expensive though :-> | 09:57 |
| *** pftbest_ has quit IRC | 09:58 | |
| *** pftbest has joined #litex | 10:01 | |
| geertu | Melkhior: Does it have a FLOSS FPGA toolchain? | 10:04 |
| * geertu hasn't touched the de0nano and Quartus since the advent of Project IceStorm | 10:05 | |
| Melkhior | geertu probably not... it's UltraScale+ so not even sure it fits in the '7-series' descriptot of project X-Ray | 10:06 |
| Melkhior | and in any case it's probably not a primary (or secondary or tertiary...) target, $9k boards aren't easy to access... | 10:07 |
| geertu | Melkhior: Would be cool to implement a heterogenous vexriscv + openrisc + microwatt + lean, ... cluster ;-) | 10:10 |
| geertu | s/lean/leon/ | 10:10 |
| Melkhior | @geertu Not sure an OS would deal with that properly... but it could be fun to try :-) | 10:13 |
| leons | Melkhior: yeah, SMP would for sure not work haha. But having a coprocessor of a different arch could be really cool (although probably impractical most of the time) | 10:15 |
| Melkhior | yes one could use a extra core as an accelerator for Linux's binfmt_misc | 10:18 |
| geertu | leons: There are plenty of SoCs with CPU cores of different archs | 10:20 |
| geertu | You cannot run a single Linux OS on them, though. | 10:21 |
| leons | geertu: yeah, that's what I was trying to say | 10:34 |
| _florent_ | zyp: nice, thanks for your efforts to simplify nMigen cores integration in LiteX, that will be very useful | 10:37 |
| *** pftbest has quit IRC | 11:53 | |
| *** pftbest has joined #litex | 11:55 | |
| *** Bertl_zZ is now known as Bertl | 12:14 | |
| *** nats` has joined #litex | 13:00 | |
| Melkhior | @_florent_ Just saw there was a Linux DRM driver for a "litex,litevideo" device ; but I don't see anything like that in litex_json2dts.py | 13:07 |
| Melkhior | Do you know what it does? I think only reocnfigure the video output | 13:09 |
| geertu | Melkhior: simple-framebuffer? | 13:14 |
| Melkhior | @geertu you don't need that driver, and indeed in the DTS it's 'compatible ="simple-framebuffer"' (and works fine) | 13:15 |
| geertu | Melkhior: There's also a new simpledrm in the works, using | 13:16 |
| geertu | simple-framebuffer | 13:16 |
| Melkhior | it seems the driver will only change timings and resolution | 13:16 |
| Melkhior | @geertu Could it use simple-acceleration as well ? | 13:16 |
| Melkhior | 'some simple acceleration' I should say | 13:17 |
| Melkhior | something that could give X11 a bit of boost for 'solid' and 'copy' at least... | 13:17 |
| Melkhior | not that I have the time :-) | 13:18 |
| Melkhior | thanks for the simpledrm hint, will look at it | 13:18 |
| geertu | Melkhior: https://lore.kernel.org/r/[email protected] | 13:27 |
| tpb | Title: [PATCH v5 0/9] drm: Support simple-framebuffer devices and firmware fbs - Thomas Zimmermann (at lore.kernel.org) | 13:27 |
| geertu | Melkhior: The DT bindings do not declare anything w.r.t. acceleration ;-) | 13:27 |
| Melkhior | @geertu Thanks! | 13:34 |
| Melkhior | 68030 but no MMU yet: https://download.experiment-s.de/Configware/releasenotes.txt | 13:34 |
| Melkhior | Also I don't see a license :-( | 13:34 |
| shoragan | Melkhior, on which FPGA do you have your 4 core vexriscv? | 13:36 |
| *** jon_ has joined #litex | 13:37 | |
| Melkhior | @shoraga Artix-7 100T, fit nicely even with full B and K support and a shared FPU for all 4 cores | 13:37 |
| Melkhior | ~$90 Qmtech Wukong from aliexpress IIRC | 13:38 |
| Melkhior | Adding some of P would probably limit to 2-3 cores only and cut down the frequency (my P stuff isn't very good, I just wanted a feel of the extension) | 13:38 |
| Melkhior | | Slice LUTs | 46518 | 0 | 63400 | 73.37 | | 13:39 |
| Melkhior | 100 MHz with no issue, too slow for Gigabit Ethernet I think so I limit the switch to Fast and it's 100% reliable; micro-sd card running perfectly at 25 MHz (didn't move to the interrupt-enabled version yet) | 13:40 |
| Melkhior | @shoragan sorry for the typo | 13:40 |
| Melkhior | the only issue is that 256 MiB is not enough RAM :-) | 13:41 |
| shoragan | Melkhior, nice. I've trying it on a 85k ECP | 13:41 |
| shoragan | IX-5, but the bios only boots in the single core variant | 13:41 |
| Melkhior | ... also I'm running with Vivado | 13:41 |
| Melkhior | @shoragan up-to-date linux-on-litex-vesriscv & litex should have no issue with basic SMP (I only added instructions, the SMP stuff is unchanged) | 13:42 |
| Melkhior | if the cores fit in the FPGA it should run, but you need to double check that everything was built with the same version/configuration: the DTS/DTB, BIOS, OpenSBI, SMP support in Linux, ... | 13:43 |
| shoragan | i had to generate _Wm variants: https://github.com/jluebbe/pythondata-cpu-vexriscv_smp/commit/450f42b43b268d241c952599e3b7dfa35c75325a | 13:44 |
| shoragan | so maybe something went wrong there | 13:44 |
| shoragan | not even the BIOS boots | 13:44 |
| shoragan | the frequency and utilization is fine for the 2 core config | 13:45 |
| Melkhior | mmm, i use native mode not wishbone ; normally the toolchain can generate the appropriate core, but you need "sbt" installed otherwise it fails cryptically | 13:45 |
| Melkhior | is wishbone mode (_Wm) required on your system ? | 13:46 |
| shoragan | Melkhior, i'm not sure. https://github.com/litex-hub/linux-on-litex-vexriscv/commit/83f92358ccb2b49226a43f3e9f8539fe92f85263 sounds like that | 13:47 |
| Melkhior | yes I was looking at the make.py and it defaults to Wishbone on the Versa | 13:48 |
| shoragan | i'm try to build it in OE, using meta-hdl. perhaps there's some issue with the toolchain for building the BIOS? but as the single-core variant works fine, i wouldn't think so | 13:48 |
| Melkhior | you'll have to ask @_florent_ for that, I don't know | 13:49 |
| Melkhior | (the Wishbone stuff I mean) | 13:49 |
| Melkhior | Yes if the single-core variant works then it's likely the toolchain is fine... | 13:50 |
| Melkhior | And if the BIOS fails it's not the DTS or kernel | 13:50 |
| shoragan | yes | 13:51 |
| Melkhior | Sorry I don't know :-( | 13:51 |
| shoragan | thanks anyway :) | 13:51 |
| _florent_ | Melkhior: Regarding the litevideo linux driver, it was indeed required with the VideoOutput core from LiteVideo to configure the timings, but it's no longer required with the new simple VideoFramebuffer directly integrated in LiteX (that comes with timings pre-initialized). A driver would only be useful to update/change the timings. | 13:51 |
| Melkhior | shoragan Maybe you can have a try w/o the wishbone to see if it reaches the BIOS, even if it's not stable enough for e.g. ? it would pinpoint the issue... | 13:52 |
| Melkhior | @_florent_ OK thanks, make sense ; indeed in my config I fix the timings in the 'target' based on the requested resolution | 13:53 |
| shoragan | Melkhior, ok. i thought there would be no chance of that working. | 13:53 |
| Melkhior | @shoragan I don't know either but it migth be worth a shot... | 13:53 |
| Melkhior | Hopefully you can get better help from others... I'm just a (happy) user of the SMP mode | 13:54 |
| _florent_ | shoragan: you can indeed try to rebuild by commenting out: https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/make.py#L376 | 13:54 |
| shoragan | _florent_, ok, i'll try that. | 13:54 |
| _florent_ | This will remove the L2 cache/Wishbone path and will use direct LiteDRAM interface | 13:54 |
| shoragan | are there other "common" things to look out for if the bios doesn't boot? :) | 13:55 |
| _florent_ | We had problems on some ECPIX-5 to use direct LiteDRAM interface so I reverted to Wishbone | 13:55 |
| shoragan | _florent_, which issues did you see that would be fixed with wishbone? | 13:55 |
| _florent_ | errors during the DDR3 memtest | 13:56 |
| shoragan | ah, ok. so i should see output even if i run into that specific issue? | 13:56 |
| _florent_ | related to the use of DM when using direct LiteDRAM interface (with Wishbone, DM are not used) | 13:57 |
| shoragan | DM? | 13:57 |
| _florent_ | DM = DDR3 Data Mask | 13:58 |
| shoragan | ok | 13:58 |
| shoragan | i tried to reduce the sys clock to 25 and 10 MHz, but i didn't see a difference | 13:59 |
| Melkhior | @shoragan I had issue at one point when my clock was too low https://github.com/litex-hub/litex-boards/issues/166 | 14:02 |
| Melkhior | there has been improvement since in litedram, but you may need the speed to be 'high enough' for the DRAM to work | 14:03 |
| _florent_ | shoragan: can you provide the build command you are using? I can try to build on my side and share it with you | 14:03 |
| shoragan | Melkhior, but in that case, you'd still have the initial output from the bios even in the bad case? | 14:03 |
| Melkhior | yes, the BIOS was still working in that case | 14:03 |
| shoragan | _florent_, i'm building using meta-hdl (updated to current litex, yosys, ... repos). basically it should be ./make.py --board ecpix5 --cpu-count 2 --build | 14:05 |
| shoragan | ok, so I now have two things to try. build without wishbone and also build without meta-hdl | 14:07 |
| _florent_ | shoragan: ok, I'll build it with this command line | 14:08 |
| shoragan | _florent_, do you think the _Wm variants will be needed for longer? then it may be useful to add those to the pythondata package to avoid the need for sbt? | 14:09 |
| _florent_ | shoragan: on some boards, the data mask are grounded (ex SDS1104XE + ColorLight I5 IIRC) so this will be kept yes | 14:11 |
| _florent_ | shoragan: I could try to add more config to the pythondata package | 14:11 |
| shoragan | thanks, that would also make it easier to use with meta-hdl, as running sbt in yocto doesn't work right at the moment | 14:12 |
| _florent_ | shoragan: here is a bitstream I just generated with your command line and with l2_size commented out: https://github.com/litex-hub/linux-on-litex-vexriscv/files/6421906/lambdaconcept_ecpix5_cpu_count_2_litedram_2021_05_04.zip | 14:51 |
| _florent_ | it works on my ECPIX-5 | 14:51 |
| _florent_ | sorry I'm not able to generate default version now | 14:51 |
| shoragan | _florent_, yes, that works on mine as well. | 14:54 |
| shoragan | _florent_, this is with the manual change from Wishbone to litedram? | 14:55 |
| _florent_ | so you can try to rebuild it and see if it also works with yours, if so, this could be an issue with cpu_count > 1 and the wishbone interface | 14:55 |
| *** jon_ has quit IRC | 15:05 | |
| *** jon_ has joined #litex | 15:09 | |
| shoragan | _florent_, ok. build without the l2_size line works for me | 15:11 |
| cr1901_modern | _florent_: Is there a way to completely override (not just append) to a build script before it's generated? The context is "Microwatt blows up the autonaming pass in yosys, and it probably shouldn't be done for now" | 15:18 |
| shoragan | _florent_, a mem_test 0x40000000 0x20000000 works fine | 15:20 |
| *** SpaceCoaster has quit IRC | 15:51 | |
| *** SpaceCoaster has joined #litex | 15:52 | |
| *** jon_ has quit IRC | 16:15 | |
| acathla | is it normal gdb doesn't stop on breakpoints I put and other strange behaviors on a vexriscv? Is it a minimal implementation of gdb? | 16:16 |
| acathla | oh, no hardware breakpoints... | 16:19 |
| tcal | acathla: correct; you can rebuild VexRiscv setting the DebugPlugin's `hardwareBreakpointCount` to 2 or greater (don't use 1; there's a known issue that I don't think has been fixed). | 16:23 |
| *** jon_ has joined #litex | 16:33 | |
| _florent_ | cr1901_modern: I don't think this is possible currently | 17:07 |
| nickoe | In the litex_sim.py there is self.submodules.crg = CRG(platform.request("sys_clk")) | 17:09 |
| nickoe | can I easily simulate the CRG generating different clock frequencies? | 17:09 |
| *** rj has joined #litex | 17:27 | |
| *** rj has quit IRC | 17:50 | |
| *** rj has joined #litex | 17:55 | |
| *** sorear has quit IRC | 17:58 | |
| *** davidlattimore has quit IRC | 17:59 | |
| *** _florent_ has quit IRC | 18:01 | |
| *** davidlattimore has joined #litex | 18:01 | |
| *** sorear has joined #litex | 18:02 | |
| *** _florent_ has joined #litex | 18:03 | |
| *** rj has quit IRC | 18:34 | |
| *** rj has joined #litex | 18:37 | |
| *** pftbest has quit IRC | 18:52 | |
| *** kgugala_ has joined #litex | 18:57 | |
| *** kgugala has quit IRC | 19:00 | |
| *** kgugala has joined #litex | 19:10 | |
| *** pftbest has joined #litex | 19:12 | |
| *** kgugala_ has quit IRC | 19:13 | |
| *** kgugala_ has joined #litex | 19:14 | |
| *** kgugala has quit IRC | 19:15 | |
| *** kgugala has joined #litex | 19:15 | |
| *** rj has quit IRC | 19:17 | |
| *** pftbest has quit IRC | 19:17 | |
| *** kgugala_ has quit IRC | 19:18 | |
| *** rj has joined #litex | 19:22 | |
| *** kgugala_ has joined #litex | 19:23 | |
| *** kgugala__ has joined #litex | 19:26 | |
| *** kgugala_ has quit IRC | 19:26 | |
| *** kgugala has quit IRC | 19:27 | |
| *** kgugala__ has quit IRC | 19:37 | |
| *** kgugala has joined #litex | 19:37 | |
| *** jon_ has quit IRC | 19:48 | |
| *** pftbest has joined #litex | 19:54 | |
| *** pftbest has quit IRC | 19:58 | |
| *** rj has quit IRC | 20:02 | |
| *** rj has joined #litex | 20:07 | |
| *** pftbest has joined #litex | 20:13 | |
| *** jon_ has joined #litex | 20:45 | |
| *** rj has quit IRC | 20:46 | |
| *** TMM has quit IRC | 20:50 | |
| *** TMM has joined #litex | 20:50 | |
| *** rj has joined #litex | 20:51 | |
| *** rj has quit IRC | 21:29 | |
| *** rj has joined #litex | 21:33 | |
| *** jon_ has quit IRC | 21:39 | |
| *** pftbest has quit IRC | 22:03 | |
| *** pftbest has joined #litex | 22:13 | |
| *** rj has quit IRC | 22:13 | |
| *** rj has joined #litex | 22:19 | |
| *** kgugala has quit IRC | 22:20 | |
| *** jon_ has joined #litex | 22:32 | |
| *** pftbest has quit IRC | 22:52 | |
| *** pftbest has joined #litex | 22:53 | |
| *** jon_ has quit IRC | 22:54 | |
| *** rj has quit IRC | 22:59 | |
| *** rj has joined #litex | 23:03 | |
| *** jon_ has joined #litex | 23:07 | |
| *** lf has quit IRC | 23:14 | |
| *** lf has joined #litex | 23:14 | |
| *** rj has quit IRC | 23:38 | |
| *** rj has joined #litex | 23:38 | |
| *** rj has quit IRC | 23:43 | |
| *** rj has joined #litex | 23:44 | |
| *** pftbest has quit IRC | 23:44 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!