| *** tpb <[email protected]> has joined #litex | 00:00 | |
| somlo | tpw_rules: I think leons was responding to my (much) earlier rant about it being hard to bisect issues that span litex, litedram, and a whole bunch of other repositories that evolve in parallel | 00:12 |
|---|---|---|
| somlo | leons: thanks, I can try to enable BIST and see what new information (if any) that gets us | 00:12 |
| mikek_VA3TEC | somlo: would you have a gists on that? I would love to learn about it.. | 00:13 |
| leons | tpw_rules: hi :) | 00:14 |
| leons | somlo: Sorry, my replies might've been out of context. I was trying to answer mikek_VA3TEC 's question: "is LiteDRAM separate from litex-boards?" | 00:15 |
| somlo | mikek_VA3TEC: gists on what? bisecting across multiple repos with occasional sync points? I don't know how to do that, that's why I'm complaining about it :) | 00:16 |
| somlo | oh, understood -- although it makes sense in my own context as well :) | 00:17 |
| mikek_VA3TEC | :) no more about how you enable the BIST and use it in context.. (Sorry I am still very new to this) | 00:17 |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 00:18 | |
| mikek_VA3TEC | so, I am using external hardware SDDRAM and only getting around 50MT/s and was wondering if this is normal.. | 00:18 |
| leons | somlo: haha that's great :) regarding DRAM speeds in general, I would always try to test with BIST first. That allows you to get an estimate of the maximum achievable speed when the DRAM controller pipelines are always full, so it's a good strategy to determine an upper optimization bound | 00:18 |
| somlo | I was going to try to figure out how to do that tomorrow (assuming it makes sense in my context) -- so I don't know (yet) | 00:18 |
| leons | Without knowing any specifics, I would guess that if the BIST values seem plausible (I guess within ~70-90% of theoretical bandwidth), the VexRiscv not being able to achieve that is a matter of its pipelining and caching and other magic + the WB transactions + any multi-cycle WB XBAR (if any) not being able to keep the pipelines of LiteDRAM full | 00:20 |
| *** Degi <[email protected]> has joined #litex | 00:21 | |
| tpw_rules | leons: somlo's complaint is one of the reasons i'm exceited about nix-litex | 00:24 |
| mikek_VA3TEC | nix-litex?? | 00:24 |
| tpw_rules | excited* | 00:24 |
| mikek_VA3TEC | runt in Litex? | 00:25 |
| mikek_VA3TEC | hahahaha joke! | 00:25 |
| mikek_VA3TEC | oops rust in Litex... | 00:25 |
| leons | tpw_rules: this one? https://libera.irclog.whitequark.org/litex/2022-09-19#32993460;somlo | 00:25 |
| tpb | Title: #litex on 2022-09-19 — irc logs at libera.irclog.whitequark.org (at libera.irclog.whitequark.org) | 00:25 |
| tpw_rules | i guess | 00:26 |
| leons | I feel like I should really get on building the bot which automatically updates pkgs, tests and either pushes / sends an email to the ML with the failed build log. Should be easy enough, major parts are in place. | 00:26 |
| tpw_rules | yes | 00:26 |
| leons | I guess with that we'd be halfway there | 00:26 |
| tpw_rules | what is the other half? actual docs? :) | 00:27 |
| leons | tpw_rules: ouch :D but yes :) | 00:27 |
| mikek_VA3TEC | I second that!!! | 00:27 |
| mikek_VA3TEC | actual docs!! | 00:27 |
| tpw_rules | also a cachix repo maybe. anyway i intend to help with the docs once we refactor the main default.nix. but this is all kind of off topic for this channel | 00:27 |
| mikek_VA3TEC | i hope florent not's listen and gets mad... | 00:28 |
| leons | I don't think getting mad about (more or less) on-topic discussions is how IRC's supposed to work | 00:29 |
| tpw_rules | i think that was more complaining about docs. but that wasn't even about the main litex not docs so florent shouldn't be mad | 00:29 |
| leons | Ah right. For context (for others), this is the repo we're talking about having no docs: https://git.sr.ht/~lschuermann/nix-litex | 00:30 |
| tpb | Title: ~lschuermann/nix-litex - sourcehut git (at git.sr.ht) | 00:30 |
| tpw_rules | and solving the bisection problems/having a single globally consistent view of the litex ecosystem | 00:31 |
| tpw_rules | (and temporally!) | 00:31 |
| mikek_VA3TEC | OH ok.. never heard of the nix package manager.. | 00:31 |
| mikek_VA3TEC | what's wrong with git pull and ./setup --updates | 00:32 |
| mikek_VA3TEC | Wanted your views.. | 00:33 |
| tpw_rules | how do you undo that, for instance? | 00:33 |
| tpw_rules | or do the same thing on a different computer? | 00:34 |
| mikek_VA3TEC | you can't I keep multiple copies of Litex, usually goes by months.. | 00:34 |
| leons | mikek_VA3TEC: And how to guarantee that you end up with the same results (i.e., that `./setup --updates` is reproducible)? | 00:34 |
| mikek_VA3TEC | it's not.. I had a solution, I never said it was a GOOD solution.. :) | 00:35 |
| mikek_VA3TEC | I got stung with this exact problem last week... | 00:36 |
| mikek_VA3TEC | Litex is too bleeding edge, there a lot of changes... sometimes fundamental... like renaming boards... | 00:37 |
| somlo | huh... so I'm not familiar with nix-litex (or nix in general), but is the idea to grab a bunch of repositories and create a super-repository containing their respective commits, correctly interleaved (in the actual chronological order in which they were applied to the original repos)? | 00:39 |
| somlo | I can imagine a tool that could do that programatically, then I could bisect on the super-repo to my heart's content | 00:40 |
| mikek_VA3TEC | IS this not what GIT was suppose to do???? | 00:40 |
| tpw_rules | that's more of a side effect of how nix and nix-litex works, but yes. the holdup now is that leons currently once a month or so updates the list. it would need to be like, daily, to be useful | 00:41 |
| somlo | I can bisect within a git repo, but if what i'm building depends on other repositories that I'd then have to guess where in *their* history I have to go for each intermediate commit picked by bisect in my "main" repo... | 00:41 |
| leons | somlo: Well, first and foremost this is just a way to make LiteX packages available through the Nix package manager, so you can build packages (read: FPGA designs) which depend on the LiteX packages | 00:41 |
| leons | And then the reproducibility, automated tests on the combined package set, etc. comes for free | 00:42 |
| mikek_VA3TEC | CAn software be written for this? example the change log's? | 00:43 |
| mikek_VA3TEC | florent? should maintain a robust change log? | 00:43 |
| somlo | leons: in my case, I *suspect* some generic axi improvements in litex might have something to do with memtest failing in certain cases; but if I pick a "git bisect good" candidate far back enough to be before those changes, I'm *guaranteed* I can't build (and therefore test) my design without guessing how far back to also go in litedram, litesdcard, litex-boards, and so on -- which makes bisect a practical non-starter | 00:44 |
| leons | somlo: ah, yes, this is a very convincing argument. That would've been possible, had I built a bot to update nix-litex regularly :/ | 00:45 |
| tpw_rules | nix-litex works by having a list of repos and hashes, and eventually it will be regularly updated to a set which is temporally coherent and passes all the tests. then you would simply bisect nix-litex and all the rest would be done automatically. but this is a relatively new project so CI hasn't been set up yet | 00:46 |
| somlo | so now I will look for a git-adjacent tool to "merge" multiple repositories by interleaving their commits in the right temporal order :) | 00:46 |
| somlo | should be worth something, so maybe someone already did it (like all my greatest ideas, others typically already had them before me :D) | 00:47 |
| tpw_rules | yeah that would pretty much be the only way to do it now. but it will be better in the future :) | 00:47 |
| mikek_VA3TEC | See Git was suppose to do exactly this, different people had different changes to make, then biscet the changes. the problem now is that there are MULTIPLE git repo;s! | 00:47 |
| mikek_VA3TEC | if I said it right.. | 00:47 |
| leons | somlo: The problem is that there's commits which are applied to multiple LiteX repos, but it's not necessarily in a fixed order (i.e. corresponding changes are merged into LiteX before it's merged into LiteDRAM or the other way around) | 00:48 |
| leons | So the benefit of nix-litex would be that the bot would only push collections of packages which are known to build along each other and pass all tests of all packages | 00:48 |
| mikek_VA3TEC | Can special codes be entered into the git commit messages? | 00:48 |
| mikek_VA3TEC | or travers? | 00:49 |
| somlo | mikek_VA3TEC: we're going a bit off-topic talking about how git works, but *within* a repo: people can have clones, push and pull and generally trade commits, etc.; But if unrelated repositories need to be used in concert to build something, then bisecting in one of them is only feasible if it's safe to assume the other repositories are OK staying the same across the range of commits in the "repository under test" searched by bisect | 00:52 |
| somlo | which is clearly *not* the case across the Lite* family of repositories. The simplest example is when something about litedram or litesdcard changes, and the bios code to initialize it in litex/litex/soc/software/* changes to match | 00:53 |
| somlo | you need to have the *right* version (commit) of litedram/litesdcard/etc. depending on where in the history of the main litex repo you happen to test | 00:54 |
| somlo | s/right/matching/ | 00:54 |
| somlo | iow, bisect works *within* a repository, not across multiple repositories | 00:55 |
| mikek_VA3TEC | I somewhat understand. This is not an easy problem to solve, You have the main tools and all the boards that are used against it. Right so now there has to be new software written that spans accross multiple repo's | 00:56 |
| mikek_VA3TEC | Linus can write that!! :) | 00:56 |
| leons | somlo: I'd go as far as to say the problem is more far-reaching than that. Each repo has it's own CI, which tests a subset of the repos together, exercising a subset of functionality in the other repos' code. There is no way to be sure that a given commit in one repo, where CI passes, just caused the next CI run in another repo to fail | 01:05 |
| leons | I don't know of a trivial way to fix this, except for an external CI which tracks known good compositions of packages, which is essentially what nix-litex is set out to become (as soon as I find some time...) | 01:06 |
| mikek_VA3TEC | leons: this is why I was saying messages in the commits. you can view the messages and see if things match u this way?? | 01:06 |
| mikek_VA3TEC | match up this way? | 01:07 |
| leons | mikek_VA3TEC: I guess you could try and match up commits across multiple repos, but then again the whole point of CI is that it does not rely on maintainers doing the right thing(TM), and it being automatic | 01:08 |
| mikek_VA3TEC | OH i totally agree.... more software has to be written, I was just giving a intern solution.. | 01:09 |
| mikek_VA3TEC | But i guess that's what Linux was.... is.. work arounds work arounds until someone writes the proper software.. | 01:10 |
| mikek_VA3TEC | Could this be a Python Script?? | 01:10 |
| leons | The update mechanism of nix-litex is already implemented as a Python script: https://git.sr.ht/~lschuermann/nix-litex/tree/main/item/maintenance/update_packages.py | 01:11 |
| tpb | Title: ~lschuermann/nix-litex: maintenance/update_packages.py - sourcehut git (at git.sr.ht) | 01:11 |
| mikek_VA3TEC | Ah ok... but yes... if the maintainers are not keeping up the good code practise... then all bets are off. | 01:15 |
| mikek_VA3TEC | How was florent, OR the maintainers doing this before? | 01:15 |
| *** bl0x <[email protected]> has joined #litex | 01:22 | |
| *** bl0x_ <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 01:23 | |
| *** mikek_VA3TEC <mikek_VA3TEC!~mikek@cpe000eb66559e0-cm08a7c0b4bdc4.cpe.net.cable.rogers.com> has quit IRC (Quit: Leaving) | 01:54 | |
| *** nickoe <[email protected]> has quit IRC (Quit: Client closed) | 02:08 | |
| *** nickoe <[email protected]> has joined #litex | 02:09 | |
| *** VC707 <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 04:27 | |
| *** nickoe <[email protected]> has quit IRC (Quit: Client closed) | 04:47 | |
| *** nickoe <[email protected]> has joined #litex | 04:47 | |
| *** nickoe <[email protected]> has quit IRC (Quit: Client closed) | 07:11 | |
| *** nickoe <[email protected]> has joined #litex | 07:12 | |
| _florent_ | The situation regarding repo split/CI/doc is clear far from perfect, but it should be improving over time (I hope :)). It's mostly time/resource/dev/budget issues that also have their own constraints. | 07:27 |
| _florent_ | I'm personally more interested to build a nice community of developers finding the project useful and wanting to contribute than a big project/business, so things are growing/improving slowly, but I think with feedback from each other we'll go in the right direction :) | 07:30 |
| _florent_ | For development, the repo split make things easier, but we should indeed continue removing some inter-dependencies (like having gateware/software for some cores in the same repo). | 07:31 |
| _florent_ | litex_setup.py was initially used for development and has been improved a bit for deployment (with --tag support for example to install releases), but we should indeed improve pip or nix installation support | 07:33 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 09:29 | |
| *** TMM_ <[email protected]> has joined #litex | 09:29 | |
| *** nickoe <[email protected]> has quit IRC (Quit: Client closed) | 10:51 | |
| *** nickoe <[email protected]> has joined #litex | 10:51 | |
| *** FabM <FabM!~FabM@2a03:d604:103:600:2e60:8c7c:e8fb:7990> has joined #litex | 11:32 | |
| *** nats` <nats`!~nats@2001:41d0:8:c634::1> has quit IRC (Ping timeout: 240 seconds) | 11:38 | |
| *** mlaga97_ <mlaga97_!~quassel@user/mlaga97> has joined #litex | 11:41 | |
| *** trabucayre <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 11:41 | |
| *** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has joined #litex | 11:43 | |
| *** TMM_ <[email protected]> has quit IRC (*.net *.split) | 11:46 | |
| *** RaYmAn <[email protected]> has quit IRC (*.net *.split) | 11:46 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has quit IRC (*.net *.split) | 11:46 | |
| *** hrberg_ <[email protected]> has joined #litex | 11:46 | |
| *** zjason` <zjason`[email protected]> has quit IRC (*.net *.split) | 11:51 | |
| *** lexano <[email protected]> has quit IRC (*.net *.split) | 11:51 | |
| *** SpaceCoaster <SpaceCoaster!~derek@user/spacecoaster> has quit IRC (*.net *.split) | 11:51 | |
| *** geertu <[email protected]> has quit IRC (*.net *.split) | 11:51 | |
| *** msh <[email protected]> has quit IRC (*.net *.split) | 11:51 | |
| *** _whitelogger <[email protected]> has quit IRC (*.net *.split) | 11:51 | |
| *** mithro <[email protected]> has quit IRC (*.net *.split) | 11:51 | |
| *** alanvgreen <[email protected]> has quit IRC (*.net *.split) | 11:51 | |
| *** yootis <[email protected]> has quit IRC (*.net *.split) | 11:51 | |
| *** eigenform_ <[email protected]> has quit IRC (*.net *.split) | 11:51 | |
| *** tucanae47 <[email protected]> has quit IRC (*.net *.split) | 11:51 | |
| *** x56_ <x56_!0x56@user/x56> has quit IRC (*.net *.split) | 11:51 | |
| *** _alice <[email protected]> has quit IRC (*.net *.split) | 11:51 | |
| *** LoveMHz <[email protected]> has quit IRC (*.net *.split) | 11:51 | |
| *** Xesxen <Xesxen!~cyber@hackalot/deelnemer/xesxen> has quit IRC (*.net *.split) | 11:51 | |
| *** Emantor <[email protected]> has quit IRC (*.net *.split) | 11:51 | |
| *** nelgau_ <[email protected]> has quit IRC (*.net *.split) | 11:51 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (*.net *.split) | 11:51 | |
| *** hrberg <[email protected]> has quit IRC (*.net *.split) | 11:51 | |
| *** mlaga97 <mlaga97!~quassel@user/mlaga97> has quit IRC (*.net *.split) | 11:51 | |
| *** joseng <[email protected]> has quit IRC (*.net *.split) | 11:51 | |
| *** trabucayre <[email protected]> has joined #litex | 11:52 | |
| *** ants` <ants`!~nats@2001:41d0:8:c634::1> has joined #litex | 11:54 | |
| *** zjason` <zjason`[email protected]> has joined #litex | 11:54 | |
| *** lexano <[email protected]> has joined #litex | 11:54 | |
| *** Emantor <[email protected]> has joined #litex | 11:54 | |
| *** SpaceCoaster <SpaceCoaster!~derek@user/spacecoaster> has joined #litex | 11:54 | |
| *** nelgau_ <[email protected]> has joined #litex | 11:54 | |
| *** geertu <[email protected]> has joined #litex | 11:54 | |
| *** msh <[email protected]> has joined #litex | 11:54 | |
| *** Xesxen <Xesxen!~cyber@hackalot/deelnemer/xesxen> has joined #litex | 11:54 | |
| *** LoveMHz <[email protected]> has joined #litex | 11:54 | |
| *** _alice <[email protected]> has joined #litex | 11:54 | |
| *** x56_ <x56_!0x56@user/x56> has joined #litex | 11:54 | |
| *** tucanae47 <[email protected]> has joined #litex | 11:54 | |
| *** eigenform_ <[email protected]> has joined #litex | 11:54 | |
| *** yootis <[email protected]> has joined #litex | 11:54 | |
| *** alanvgreen <[email protected]> has joined #litex | 11:54 | |
| *** mithro <[email protected]> has joined #litex | 11:54 | |
| *** _whitelogger <[email protected]> has joined #litex | 11:54 | |
| *** joseng <[email protected]> has joined #litex | 11:54 | |
| *** hrberg_ <[email protected]> has quit IRC (Max SendQ exceeded) | 11:54 | |
| *** hrberg <[email protected]> has joined #litex | 11:54 | |
| *** TMM_ <[email protected]> has joined #litex | 11:54 | |
| *** RaYmAn <[email protected]> has joined #litex | 11:54 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #litex | 11:54 | |
| *** zjason` <zjason`[email protected]> has quit IRC (*.net *.split) | 11:55 | |
| *** lexano <[email protected]> has quit IRC (*.net *.split) | 11:55 | |
| *** SpaceCoaster <SpaceCoaster!~derek@user/spacecoaster> has quit IRC (*.net *.split) | 11:55 | |
| *** geertu <[email protected]> has quit IRC (*.net *.split) | 11:55 | |
| *** msh <[email protected]> has quit IRC (*.net *.split) | 11:55 | |
| *** Crofton[m] <Crofton[m]!~croftongn@2001:470:69fc:105::9a7> has quit IRC (Ping timeout: 250 seconds) | 11:57 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC (Ping timeout: 250 seconds) | 11:58 | |
| *** CarlFK <CarlFK!~carlfk@2001:470:69fc:105::5d8> has quit IRC (Ping timeout: 264 seconds) | 11:58 | |
| *** jryans <jryans!~jryans@2001:470:69fc:105::1d> has quit IRC (Ping timeout: 268 seconds) | 11:58 | |
| *** pepijndevos[m] <pepijndevos[m]!~pepijndev@2001:470:69fc:105::b6a8> has quit IRC (Ping timeout: 268 seconds) | 11:58 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has quit IRC (Ping timeout: 264 seconds) | 11:58 | |
| *** sajattack[m] <sajattack[m]!~sajattack@2001:470:69fc:105::1d9> has quit IRC (Ping timeout: 240 seconds) | 11:58 | |
| *** a3f <a3f!~a3f@2001:470:69fc:105::41d> has quit IRC (Ping timeout: 250 seconds) | 11:58 | |
| *** amstan <amstan!~amstan@2001:470:69fc:105::1e9> has quit IRC (Ping timeout: 250 seconds) | 11:58 | |
| *** RowanG[m] <RowanG[m]!~rowang077@2001:470:69fc:105::1:ca9f> has quit IRC (Ping timeout: 264 seconds) | 11:58 | |
| *** mikolajw <mikolajw!~mikolajtc@2001:470:69fc:105::3b02> has quit IRC (Ping timeout: 268 seconds) | 11:59 | |
| *** zjason` <zjason`[email protected]> has joined #litex | 12:00 | |
| *** lexano <[email protected]> has joined #litex | 12:00 | |
| *** SpaceCoaster <SpaceCoaster!~derek@user/spacecoaster> has joined #litex | 12:00 | |
| *** geertu <[email protected]> has joined #litex | 12:00 | |
| *** msh <[email protected]> has joined #litex | 12:00 | |
| *** DerekKozel[m] <DerekKozel[m]!~dkozelgnu@2001:470:69fc:105::2f14> has quit IRC (Ping timeout: 264 seconds) | 12:00 | |
| *** leons <leons!~leons@2001:470:69fc:105::abc> has quit IRC (Ping timeout: 268 seconds) | 12:01 | |
| *** fpga_zealot[m] <fpga_zealot[m]!~fpgazealo@2001:470:69fc:105::2:6c7b> has quit IRC (Ping timeout: 268 seconds) | 12:01 | |
| *** xenador77[m] <xenador77[m]!~xenador77@2001:470:69fc:105::2:5a64> has quit IRC (Ping timeout: 268 seconds) | 12:01 | |
| *** pepijndevos[m] <pepijndevos[m]!~pepijndev@2001:470:69fc:105::b6a8> has joined #litex | 12:07 | |
| *** Crofton[m] <Crofton[m]!~croftongn@2001:470:69fc:105::9a7> has joined #litex | 12:10 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #litex | 12:11 | |
| *** a3f <a3f!~a3f@2001:470:69fc:105::41d> has joined #litex | 12:12 | |
| *** sajattack[m] <sajattack[m]!~sajattack@2001:470:69fc:105::1d9> has joined #litex | 12:13 | |
| *** RowanG[m] <RowanG[m]!~rowang077@2001:470:69fc:105::1:ca9f> has joined #litex | 12:21 | |
| *** CarlFK <CarlFK!~carlfk@2001:470:69fc:105::5d8> has joined #litex | 12:27 | |
| *** jryans <jryans!~jryans@2001:470:69fc:105::1d> has joined #litex | 12:29 | |
| *** mikolajw <mikolajw!~mikolajtc@2001:470:69fc:105::3b02> has joined #litex | 12:30 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #litex | 12:35 | |
| *** DerekKozel[m] <DerekKozel[m]!~dkozelgnu@2001:470:69fc:105::2f14> has joined #litex | 12:35 | |
| *** fpga_zealot[m] <fpga_zealot[m]!~fpgazealo@2001:470:69fc:105::2:6c7b> has joined #litex | 12:36 | |
| *** leons <leons!~leons@2001:470:69fc:105::abc> has joined #litex | 12:36 | |
| *** xenador77[m] <xenador77[m]!~xenador77@2001:470:69fc:105::2:5a64> has joined #litex | 12:37 | |
| *** amstan <amstan!~amstan@2001:470:69fc:105::1e9> has joined #litex | 13:17 | |
| leons | _florent_: I agree and the conversation wasn't supposed to be a rant about the current situation, just thinking about how someone downstream can ensure that a given collection of LiteX packages will work together. | 14:35 |
| *** mikek_VA3TEC <[email protected]> has joined #litex | 14:46 | |
| *** nickoe <[email protected]> has quit IRC (Quit: Client closed) | 14:47 | |
| *** nickoe <[email protected]> has joined #litex | 14:47 | |
| somlo | as it turns out, I had a typo associating the wrong verilog to the "problematic" rocket cpu variant -- git bisect would have never caught it (I would have failed to find a "good" commit, no matter how far back I went) :) | 15:16 |
| somlo | not that the whole argument about bisect-ability isn't valid in the big scheme of things, just not applicable to this particular issue | 15:17 |
| somlo | anyhow, got Fedora to boot on nexys_video: https://imgur.com/a/GozXcQ8 | 15:18 |
| tpb | Title: Imgur: The magic of the Internet (at imgur.com) | 15:18 |
| somlo | (at least for a short time before it crashed, but progress!) | 15:18 |
| mikek_VA3TEC | Sweet! :) | 15:19 |
| leons | somlo: That is very cool! I have actually just gotten access to a Nexys Video board, mind sharing how to reproduce / pushing the code somewhere? | 15:20 |
| mikek_VA3TEC | Yes, i second that! | 15:21 |
| somlo | so building the bitstream is easy (now that `fulld` rocket variant is no longer broken): | 15:23 |
| somlo | litex-boards/litex_boards/targets/digilent_nexys_video.py --build \ | 15:23 |
| somlo | --cpu-type rocket --cpu-variant fulld --sys-clk-freq 50e6 \ | 15:23 |
| somlo | --with-ethernet --with-sdcard \ | 15:23 |
| somlo | --with-sata --sata-gen 1 --pll-refclk | 15:23 |
| somlo | then there's downloading the latest fedora-riscv64 image, and prepping a special initrd, dts/dtb, and opensbi firmware blob, and the writing all that to a sdcard | 15:25 |
| somlo | I'll have to write all that down in a way that is intelligible (from various notes I took while hacking on it) -- that might take a day or two (need some peace and quiet from $DAYJOB to focus :D) | 15:27 |
| somlo | using `full4d` (4x SMP) crashes *before* getting a login prompt; using `full` (1x single-core) with the 4x DTB (I was lazy) crashes *after* the login prompt | 15:28 |
| somlo | I still need to try the single-core with the correct DTB (that doesn't claim there are 4 cores available :) and see if maybe I get it to work *without* crashing | 15:29 |
| somlo | gotta go, lunch break is almost over and I spent it on hacking instead of eating -- I'll be back later with more useful details | 15:31 |
| mikek_VA3TEC | Thanks Somlo! :) | 15:31 |
| *** mikek_VA3TEC <[email protected]> has quit IRC (Remote host closed the connection) | 15:40 | |
| *** zjason` is now known as zjason | 16:10 | |
| *** mikek_VA3TEC <[email protected]> has joined #litex | 16:45 | |
| *** nickoe <[email protected]> has quit IRC (Quit: Client closed) | 17:13 | |
| *** nickoe <[email protected]> has joined #litex | 17:14 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 268 seconds) | 18:54 | |
| *** nickoe <[email protected]> has quit IRC (Quit: Client closed) | 19:37 | |
| *** nickoe <[email protected]> has joined #litex | 19:38 | |
| tnt | Mmmm ... the error messages of migen are a bit obscure ... "assert (node.stop - node.start) >= 1" | 19:49 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 20:34 | |
| *** TMM_ <[email protected]> has joined #litex | 20:34 | |
| *** mikek_VA3TEC <[email protected]> has quit IRC (Remote host closed the connection) | 20:34 | |
| tnt | """ERROR: [Synth 8-3391] Unable to infer a block/distributed RAM for 'storage_49_reg' because the memory pattern used is not supported. Failed to dissolve the memory into bits because the number of bits (528384) is too large. Use 'set_param synth.elaboration.rodinMoreOptions {rt::set_parameter dissolveMemorySizeLimit 528384}' to allow the memory to be dissolved into individual bits""" | 21:23 |
| tnt | Anyone seen this before ? | 21:23 |
| *** nickoe <[email protected]> has quit IRC (Quit: Client closed) | 22:18 | |
| *** nickoe <[email protected]> has joined #litex | 22:19 | |
| *** nickoe <[email protected]> has quit IRC (Quit: Client closed) | 22:56 | |
| *** nickoe <[email protected]> has joined #litex | 22:57 | |
| *** cr1901_ <cr1901_!~cr1901@2601:8d:8600:911:5485:20e1:cdc4:b4f2> has joined #litex | 22:57 | |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:911:bd35:d349:c17c:2188> has quit IRC (Ping timeout: 268 seconds) | 23:01 | |
| *** cr1901_ is now known as cr1901 | 23:02 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!