| *** tpb has joined #litex | 00:00 | |
| *** shorne has quit IRC | 00:15 | |
| *** shorne has joined #litex | 00:15 | |
| *** TMM has quit IRC | 00:58 | |
| *** TMM has joined #litex | 00:58 | |
| *** mc6808 has joined #litex | 01:24 | |
| *** Bertl_oO is now known as Bertl_zZ | 01:56 | |
| *** mc6808 has quit IRC | 02:03 | |
| *** FFY00_ has quit IRC | 02:22 | |
| *** FFY00_ has joined #litex | 02:25 | |
| *** FFY00_ has quit IRC | 02:26 | |
| *** FFY00_ has joined #litex | 02:26 | |
| *** chipdsgr has quit IRC | 03:38 | |
| *** Degi_ has joined #litex | 03:44 | |
| *** Degi has quit IRC | 03:44 | |
| *** Degi_ is now known as Degi | 03:44 | |
| *** chipdsgr has joined #litex | 05:28 | |
| *** somlo_ has quit IRC | 06:49 | |
| *** somlo_ has joined #litex | 06:49 | |
| _florent_ | Wolf`: some first tests have been done with LiteX/HBM2 recently yes (using Xilinx's controller): https://twitter.com/enjoy_digital/status/1390336281176117249 | 07:17 |
|---|---|---|
| _florent_ | The code is here: https://github.com/enjoy-digital/fk33_hbm2 | 07:17 |
| Quarky93[m] | Looks like you found your way here wolf :) | 07:46 |
| chipdsgr | any good resources/documentation on how to wrap some existing HDL logic with migen/nmigen? | 07:49 |
| _florent_ | chipdsgr: there is an initial wiki page for this that could be useful: https://github.com/enjoy-digital/litex/wiki/Reuse-A-Verilog-VHDL-nMigen-Core | 08:00 |
| _florent_ | Betrusted project is interesting to have example of HDL integration with Migen/LiteX: https://github.com/betrusted-io/gateware/tree/master/gateware | 08:02 |
| _florent_ | ex: https://github.com/betrusted-io/gateware/blob/master/gateware/i2c/core.py | 08:03 |
| chipdsgr | _florent_: excellent, thanks so much! | 08:40 |
| *** Bertl_zZ is now known as Bertl | 08:49 | |
| *** _franck_ has quit IRC | 11:33 | |
| shoragan | is it intentional that https://github.com/litex-hub/pythondata-cpu-rocket has issues disabled? | 12:04 |
| shoragan | somlo_, ^ | 12:04 |
| *** TMM has quit IRC | 13:20 | |
| *** TMM has joined #litex | 13:21 | |
| *** disasm[m] has quit IRC | 13:22 | |
| *** disasm[m] has joined #litex | 13:23 | |
| *** leons has quit IRC | 13:23 | |
| *** leons has joined #litex | 13:30 | |
| *** guan has quit IRC | 13:30 | |
| *** mithro has quit IRC | 13:32 | |
| *** bubble_buster has quit IRC | 13:33 | |
| *** guan has joined #litex | 13:34 | |
| *** rohitksingh has quit IRC | 13:36 | |
| *** bubble_buster has joined #litex | 13:38 | |
| *** mithro has joined #litex | 13:39 | |
| *** mithro has quit IRC | 13:39 | |
| *** somlo_ has left #litex | 13:39 | |
| *** somlo_ has joined #litex | 13:39 | |
| *** somlo_ has left #litex | 13:40 | |
| *** somlo_ has quit IRC | 13:40 | |
| *** somlo has joined #litex | 13:41 | |
| *** rohitksingh has joined #litex | 13:41 | |
| somlo | shoragan: not *my* intention (I didn't set it up) :) | 13:42 |
| *** mithro has joined #litex | 13:45 | |
| shoragan | somlo, ok. :) if you don't have permissions there, it's probably something for _florent_? | 13:49 |
| somlo | shoragan: history is that pre-built verilog cpu repos used to be part of litex, then got split out, with lots of pythonic "stuff" around them. I maintain the verilog and push occasional updates, but the pythonic "stuff" happens somewhat orthogonally to that. mithro might know | 13:51 |
| mithro | shoragan: As pythondata-cpu-rocket is auto-generated, the issues belong on https://github.com/litex-hub/pythondata-auto | 13:52 |
| shoragan | somlo, ah, thanks for the background. | 13:52 |
| shoragan | mithro, it seems that the submodule updates happen in -rocket, though? | 13:53 |
| mithro | shoragan: https://github.com/litex-hub/pythondata-auto/blob/148f71cddd3bc38f8686d87931d39d5be71a284d/modules.ini#L58-L68 | 13:54 |
| mithro | shoragan: It would be good if you could help update the template README so that is clear to people? | 13:55 |
| shoragan | mithro, i was looking at https://github.com/litex-hub/pythondata-cpu-rocket/commit/e5bbab953c9265e351600a783be70065708a1c40 | 13:55 |
| somlo | shoragan: that's one of the verilog updates I was talking about | 13:56 |
| shoragan | that seems inconsistent | 13:56 |
| somlo | the update script downloads the current upstream chipsalliance/rocket-chip chisel sources, applies some litex-specific patches, and has chisel build the verilog | 13:57 |
| somlo | the diff between old verilog and current verilog is incomprehensible, and that's just the way it is... | 13:58 |
| mithro | shoragan / somlo: That does look like there is some confusion there | 13:58 |
| somlo | the only useful information in the diff is _upstream.rev, telling you which chipsalliance/rocket-chip commit generated the "old" vs. "new" verilog | 13:58 |
| shoragan | somlo, that the diff is mostly unreadable is understood :) | 13:59 |
| shoragan | mithro, as far as i can see, the "LiteX Robot" commits never touch the verilog | 14:00 |
| *** nickoe has quit IRC | 14:01 | |
| *** kgugala has quit IRC | 14:01 | |
| mithro | I think it might be that pythondata-cpu-rocket and pythondata-cpu-vexriscv are special cased -- https://github.com/litex-hub/pythondata-auto/issues/4 | 14:01 |
| *** nickoe has joined #litex | 14:02 | |
| mithro | The other modules use https://github.com/litex-hub/pythondata-auto/blob/148f71cddd3bc38f8686d87931d39d5be71a284d/update.py#L378-L390 | 14:02 |
| shoragan | mithro, ah, yes. now i understand how it works for the others | 14:03 |
| mithro | It really needs some love | 14:04 |
| somlo | shoragan: just out of curiosity, what's the inconsistency you noticed? | 14:04 |
| shoragan | somlo, https://github.com/jluebbe/linux-on-litex-rocket/runs/2595089523?check_suite_focus=true#step:7:683 | 14:04 |
| mithro | shoragan: I'm supportive of your idea around automated bitstream builds | 14:05 |
| mithro | shoragan: I've been doing prebuilt firmware for FPGA designs for a long time -> https://github.com/timvideos/HDMI2USB-firmware-prebuilt :-) | 14:05 |
| shoragan | my work on the github actions was motivated by making sure that at least the "baseline" configs needed by linux-on-* work reliably | 14:06 |
| shoragan | mithro, nice :) altough with the hdl-containers and github-actions-artifacts it seems even simpler, as you don't need to commit back into the repo | 14:07 |
| mithro | shoragan: Yes, I was also doing this before we had open source tooling | 14:07 |
| somlo | shoragan: I'm looking at a falied ci build, not sure what to make of it; either way, the reason I'd be a bit uncomfortable with automating the verilog generation for rocket is that upstream often breaks things, and I only really want to deal with it when I'm good and ready, not every time CI notices some breakage and starts yelling at me :) | 14:08 |
| somlo | your bad experience with current rocket and whatever ci uses for yosys/trellis/nextpnr notwithstanding :) | 14:09 |
| somlo | I'll test (and push an update) for rocket within a week, that's the plan right now :D | 14:09 |
| shoragan | somlo, ok. currently, though, it seems that the litex integration for rocket-chip in master only works with a different verilog version | 14:09 |
| shoragan | my colleague steffen tried an update: https://github.com/strumtrar/pythondata-cpu-rocket/commit/897c6606c0d8a0e8b6c30c47a5b1cc74b204d4ec | 14:10 |
| shoragan | the diff in this case actually looks relevant ;) | 14:11 |
| shoragan | although you get a bitstream with that change, it doesn't boot into the bios, so we didn't make a PR | 14:12 |
| shoragan | without a reproducible, known good version in CI, this is getting somewhat frustrating ;) | 14:13 |
| mithro | My general theory is that if it isn't automatically tested, then it is most certainly broken :-) | 14:13 |
| somlo | shoragan: the high-level problem is that all of rocket, yosys, trellis, nextpnr, and litex itself are fast moving targets, and one could spend a full time job just keeping all their latest versions playing nice with each other | 14:13 |
| shoragan | mithro, yes! | 14:13 |
| somlo | hence the low-pass filter on e.g. the rocket chip verilog and the toolchain, since my main focus is on using them to build something that works in litex :) | 14:14 |
| shoragan | somlo, yes. but in that case i'd at least know that it's not a problem with my local setup | 14:14 |
| somlo | I do want to keep them relatively up to date, but not every week | 14:14 |
| shoragan | somlo, if i could exactly reproduce what you're using, i'd be happy, too | 14:15 |
| somlo | and now that they're gaining at least a small amount of popularity (apparently :) ) -- it's time to 1. update them ASAP (I'm working on that) and 2. figure out how to make it all work for everyone interested (that's not something I have a lot of experience with) | 14:15 |
| shoragan | with the HDL-Containers, the ci job could also pin a specific version of that, until it's time to update | 14:15 |
| somlo | so maybe CI is a good idea | 14:15 |
| somlo | but first let's make sure we at least *start* with a working combination of everything :) | 14:16 |
| shoragan | :) | 14:16 |
| shoragan | actually, my goal is to get a working combination into meta-hdl, as that has an easy way to pin all the dependencies | 14:17 |
| somlo | shoragan: I gave you the toolchain commit IDs I'm using on Fedora. I fully expect to notice your breakage once I update to the latest git upstream -- then I will file bugs with upstream, then maybe they get fixed, then maybe we'll get everything to work, and all that can take a week or two | 14:18 |
| shoragan | but porting SBT into that would be a huge task, so my focus is getting a consistent set into the pythondata-* pacakges | 14:18 |
| shoragan | somlo, i tried with your versions, and then got stuck on a non-booting bios :/ and my debugging-fu at that level is almost non-existant | 14:19 |
| shoragan | ok, i'll try again when you had time to update it :) | 14:20 |
| somlo | shoragan: I understand -- better to have me catch up than you wasting time on debugging with the old toolchain | 14:20 |
| somlo | but me "catching up" takes (me) some effort, so I've historically limited it to once every few months or so; you've just caught me right *before* the next one :) | 14:21 |
| shoragan | :) | 14:22 |
| shoragan | i'm very grateful for your work, thanks | 14:23 |
| somlo | the root issue is that all these are relatively disparate projects run by different groups who are not necessarily concerned with each other's priorities. | 14:23 |
| somlo | my main contribution is to act as the "glue layer" between them :) | 14:23 |
| shoragan | somlo, regressions cause by changes in disparate components is not a new thing for embedded linux developers ;) | 14:24 |
| shoragan | that's why i want to have it all in yocto | 14:24 |
| mithro | shoragan: What is your interest in the rocket version (as opposed to vexriscv)? 64bit RISC-V? | 14:25 |
| mithro | shoragan: Oh, your interested in yocto? https://docs.google.com/document/d/1hBvcE83vDRn5EVzcv4Qv_dcGlDuXp5pNI-_yzrEOwxs/edit | 14:25 |
| tpb | Title: LiteX BuildEnv based on Yocto - Google Docs (at docs.google.com) | 14:25 |
| shoragan | mithro, actually, i want to have both. | 14:25 |
| shoragan | if that works, i want to have a setup for kernelci to catch kernel regressions. but that some way off | 14:27 |
| shoragan | my experiments were based on meta-hdl | 14:27 |
| shoragan | and that largely works (at least i run into the same issues as the github ci runs based on the hdl-containers ;) | 14:28 |
| mithro | shoragan: I would be interested in people looking at working on making gateware generation a first class citizen in yocto | 14:29 |
| shoragan | mithro, as in running sbt? or running litex? | 14:30 |
| mithro | shoragan: All of the above eventually | 14:30 |
| shoragan | sure. first i'd like to have a small collection of working machines (in the yocto sense). first without sbt but from pregenerated verilog. and have that reliably booting into linux | 14:32 |
| shoragan | if that works, pulling out common functionality into bbclasses could be next | 14:32 |
| shoragan | i looked at SBT, but that seems to be a complete packaging system of its own. integrating that as well would be a major effort on its own | 14:33 |
| somlo | shoragan: maybe somewhat related to your interest: I was able to build bitstream for ecp5 from complete scratch on a rv64gc fedora VM in qemu (took 2 days for the whole thing to build) | 14:34 |
| shoragan | one could require it as a preinstalled host-tool, though | 14:34 |
| shoragan | somlo, nice :) | 14:34 |
| somlo | it's the same rv64gc whose root partition I'm trying to boot from on litex/rocket :) | 14:34 |
| mithro | shoragan: Agreed | 14:35 |
| shoragan | somlo, i'm a bit allergic to trying to manually customize a disto image for embedded systems. reproducibility is extremely hard without a build system. | 14:35 |
| somlo | shoragan: I just want a fully self-hosting computer. Right now I can mount and chroot to that filesystem, and run yosys and nextpnr from it (slowly) | 14:36 |
| shoragan | mithro, but even then building vexrisc with sbt failed, because it expects to be run from the full git repo, not from an installed python module :/ | 14:36 |
| somlo | but booting the actual OS would make for a more definitive statement :) | 14:37 |
| shoragan | somlo, yocto has enough packages to be self-hosting (and that's tested by the autobuilders) | 14:37 |
| shoragan | mithro, thanks for the google doc link, a large part of what you discussed there is already working | 14:45 |
| mithro | shoragan: If I gave you edit access, could you update the Google Doc? | 14:45 |
| shoragan | (working, as in they need the pythondata fixes ;)( | 14:47 |
| mithro | shoragan: message me a google account and I'll give you edit access | 14:48 |
| shoragan | regarding the mapping, i don't really have anything to add. nathan rossi did all the work before i even looked at it :) | 14:48 |
| shoragan | are there other socs that would be able to boot linux on a ECP5 besides vexrisc and rocket? | 14:50 |
| mithro | shoragan: I used to work on bitbake when OpenZaurus was a thing :-) | 14:51 |
| mithro | shoragan: back in like 2004 / 2005 | 14:51 |
| mithro | shoragan: The Artix / Arty socs should also work -> https://symbiflow-examples.readthedocs.io/en/latest/building-examples.html#linux-litex-demo | 14:54 |
| tpb | Title: Building example designs SymbiFlow examples documentation (at symbiflow-examples.readthedocs.io) | 14:54 |
| mithro | shoragan: In theory power and mor1k architectures should also work | 14:54 |
| mithro | shoragan: for Power you use microwatt | 14:54 |
| shoragan | i only have the ECPIX-5, and would prefer to stay with the open toolchains | 14:56 |
| shoragan | as that simplifies having the full toolchain in OE a lot | 14:57 |
| mithro | shoragan: Only open toolchains above | 14:57 |
| mithro | shoragan: I assume you are in germany? | 14:57 |
| shoragan | yep | 14:57 |
| shoragan | <mithro> shoragan: I used to work on bitbake when OpenZaurus was a thing :-) | 14:57 |
| shoragan | ^ i used it a lot at OpenMoko and OpenEXZ before that :) | 14:58 |
| mithro | shoragan: What amazes me is people are still working on buildroot.... | 14:58 |
| shoragan | ah, i wasn't aware that the open xilinx tool chain was ready enough yet | 14:58 |
| mithro | shoragan: It's not as polished as the ECP5 + nextpnr flow | 14:58 |
| shoragan | mithro, it's a different niche. much simpler, easy to get started. but also less powerfull | 14:59 |
| mithro | shoragan: I'd be happy to send you an arty if you thought it would help get things tested | 14:59 |
| shoragan | ok. then i think i'll stick with ECP5 for now, until i've got the full chain working (inkl. kernel and userspace) | 14:59 |
| shoragan | mithro, the bottleneck is more time rather than money ;) | 15:00 |
| mithro | shoragan: Yeah - have the same problem, that is why I offer to send people hardware | 15:00 |
| shoragan | if we have a full example for ECP5 in meta-hdl, it should be easier for ppl who are less experinced with OE/Yocto to add support for other socs | 15:01 |
| Wolf` | _florent_: I am doing some of my own work | 15:01 |
| shoragan | so, depth first | 15:01 |
| Wolf` | Quarky93[m]: hai | 15:01 |
| Wolf` | _florent_: Xilinx are underclocking the HBM2 (forcibly - the user is unable to change it as the encrypted HBM IP will not generate settings for its internal PLL to run the memory above 900Mhz. | 15:02 |
| Wolf` | The part, is Samsung Aquabolt HBM2, and it's actually spec'd for 1000Mhz - 1200Mhz (depending on binning) | 15:03 |
| geertu | mithro: Last time I tried microwatt, the yosys from the fpga-toolchain builds didn't have the needed VHDL support | 15:06 |
| mithro | geertu: hdl-containers and the conda environments should do these days -- no idea about YosysHQ/fpga-toolchain -- they are off in their own little world | 15:08 |
| Wolf` | So I'm now working on changing the clock, but... this project has gotten kind of out of control. To control the clock at runtime, I have to poke registers in the APB interface of the HBM IP (or the HBM primitives!) The register details are hidden by Xilinx... so I've been working on reverse engineering all of them. | 15:10 |
| Wolf` | I have enough PLL settings to change the clock, but it's not that easy - you gotta re-train, re-calibrate the MCs, and if you don't wanna lose memory contents, it has to be put in self-refresh mode. | 15:11 |
| shoragan | mithro, with the extended pythondata-cpu-vexriscv_smp, the bitstreams now build and produce artifacts: | 15:32 |
| shoragan | https://github.com/jluebbe/linux-on-litex-vexriscv/actions/runs/853809065 | 15:32 |
| mithro | shoragan: Very cool | 15:33 |
| shoragan | maybe i'll find some spare energy to add a job for the linux/buildroot build as well | 15:43 |
| _florent_ | Wolf`: Interesting, I can understand it's not easy to remove the limitations. I just used the Xilinx controller as a black box with LiteX with the FK33, haven't looked closely at the spec, but I can indeed imagine this is quite complex. | 16:10 |
| _florent_ | shoragan: Sorry for the Linux-on-LiteX-VexRiscv CI PR, I just try to keep thing simple/minimal on the CI front to try to focus on FPGA dev. I also like the idea of automating bitstream generation but just have a preference for experimenting it externally for now. | 16:18 |
| *** kgugala has joined #litex | 16:21 | |
| shoragan | _florent_, sure, there are different perspectives. coming from the embedded build system side, i tend to push back against project-specific build automation. :) | 16:21 |
| shoragan | by keeping the CI directly at the CLI level, it's also easy to correlate with what a user would do manually. i find that useful as a way to have "executable documentation" | 16:23 |
| shoragan | I've become a bit opinionated about the need for reproducible CI over the year ;) | 16:26 |
| shoragan | *years | 16:26 |
| mithro | shoragan: Have you see tuttest? https://github.com/antmicro/tuttest ? We use it to test our README instructions still work on symbiflow-examples | 16:32 |
| mithro | s/see/seen/ | 16:33 |
| shoragan | mithro, no, hadn't seen it yet. interesting. | 16:36 |
| shoragan | maybe release it on pypi? | 16:37 |
| mithro | shoragan: Log a bug about that? | 16:38 |
| shoragan | mithro, done | 16:40 |
| Wolf` | _florent_: it's worse because the APB registers are undocumented by Xilinx. | 16:40 |
| shoragan | it's a bit like literate programming. :) now the use-case seems obvious and i'm wondering why something like that is not widespread... | 16:42 |
| *** _franck_ has joined #litex | 16:50 | |
| *** indy has quit IRC | 17:01 | |
| *** indy has joined #litex | 20:08 | |
| *** pftbest has quit IRC | 20:34 | |
| *** pftbest has joined #litex | 20:48 | |
| *** pftbest has quit IRC | 20:50 | |
| *** pftbest_ has joined #litex | 20:50 | |
| *** dcallagh has quit IRC | 23:25 | |
| *** Quarky93[m] has quit IRC | 23:26 | |
| *** apolkosnik[m] has quit IRC | 23:27 | |
| *** sajattack[m] has quit IRC | 23:27 | |
| *** dcallagh has joined #litex | 23:41 | |
| *** Quarky93[m] has joined #litex | 23:47 | |
| *** apolkosnik[m] has joined #litex | 23:53 | |
| *** sajattack[m] has joined #litex | 23:55 | |
| *** lf has quit IRC | 23:57 | |
| *** lf has joined #litex | 23:57 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!