Friday, 2023-01-13

octaviusAnother problem I'm now hitting is during building of Microwatt for the orangecrab ecp5 target.00:46
octaviusFirst, I follow the guide on the wiki page ( up to the point where the verilator_trace branch is checked out.00:46
octaviusThen I build an OrangeCrab bitstream using (make microwatt.bit).00:46
octaviusGetting the following error:00:46
octaviusInfo: Annotating ports with timing budgets for target frequency 40.00 MHz00:46
octaviusERROR: cell type '$mem_v2' is unsupported (instantiated as 'soc0.processor_internal.processor.icache_0.itlb_tags')00:46
octavius375 warnings, 1 error00:46
octaviusmake: *** [Makefile:275: microwatt_out.config] Error 25500:46
octaviusThis is the design utilisation on ECP5:00:46
octaviusInfo: Logic utilisation before packing:00:47
octaviusInfo:     Total LUT4s:     42698/83640    51%00:47
octaviusInfo:         logic LUTs:  37246/83640    44%00:47
octaviusInfo:         carry LUTs:   4084/83640     4%00:47
octaviusInfo:           RAM LUTs:    912/41820     2%00:47
octaviusInfo:          RAMW LUTs:    456/20910     2%00:47
octaviusInfo:      Total DFFs:     26330/83640    31%00:47
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC00:48
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc00:49
lkcloctavius, you're using the wrong version of yosys.00:49
lkcli use this:00:51
lkcl$ yosys --version00:51
lkclYosys 0.13 (git sha1 eb5f9d9de, clang 9.0.1-12 -fPIC -Os)00:51
programmerjakeif you're curious, that bug, which only started in versions of yosys after what we use, is likely
*** octavius <octavius!> has quit IRC00:52
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC01:00
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC01:11
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc01:11
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc01:49
*** Ritish <Ritish!~Ritish@2409:4070:2cc6:4e1f:f4e5:8c5:aeea:b7cf> has joined #libre-soc04:22
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC04:30
*** Ritish <Ritish!~Ritish@2409:4070:2cc6:4e1f:f4e5:8c5:aeea:b7cf> has quit IRC05:43
*** ghostmansd <ghostmansd!> has quit IRC06:42
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC06:53
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc06:54
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC07:06
*** Gayatri <Gayatri!~Gayatri@> has joined #libre-soc07:50
*** Gayatri <Gayatri!~Gayatri@> has quit IRC07:52
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc07:59
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC08:51
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc08:52
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC09:12
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc09:44
*** midnight <midnight!~midnight@user/midnight> has quit IRC11:28
*** midnight <midnight!~midnight@user/midnight> has joined #libre-soc11:29
*** octavius <octavius!> has joined #libre-soc11:34
octaviusJust checked, my yosys is also 0.13 (I used the hdl-tools-yosys as usual):11:35
octaviusYosys 0.13 (git sha1 eb5f9d9de, clang 7.0.1-8+deb10u2 -fPIC -Os)11:35
octaviusBut my clang is different11:35
octaviusChecking clang version I get11:37
octaviusclang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final)11:37
markos7? that's ancient, I think it's time we spend some time in updating our working system base, bullseye is almost frozen, I'd suggest we do that and in the process provide a VM with all the tools installed, for x86 and ppc64le11:41
markosthat would actually be a nice task11:42
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC11:44
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc11:46
octaviusmarkos, that's kind of where I was heading with my experimenting so far.11:47
octaviusTo have a stable chroot for fpga image building, power binary compilation, etc.11:48
*** octavius <octavius!> has quit IRC13:11
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC13:16
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc13:42
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC14:01
lkclmarkos, the amount of time it would take would be several WEEKS, followed by massive disruption for several MONTHS... for everyone14:31
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc14:32
lkclstabilising the debian/10 chroot (for inexperienced developers), well, 2 years after the repo was first created we are still finding and fixing problems.14:32
markosnot saying it should be done at the expense of other more important stuff, but it would certainly pay off in the end14:32
lkcli'm not repeating that.14:32
markosdebian 10 will soon be oldstable14:32
markosactually, wrong14:32
markosit's already oldstable14:32
markos11 is current stable14:32
markos12 will soon be next stable, and 10 will be oldoldstable14:33
lkclif it "disappears" we find a mirror somewhere else.14:33
lkclstill have no problem with that14:33
lkclit's not being upgraded, it's ... well... "Stable".14:33
markoswe should prepare to migrate to 12 in the next months, surely we should be able to get someone to do the work and provide working VMs for others14:33
programmerjakeimho we should spend the time to upgrade...14:33
lkclno, no, no folks.14:33
markosgive me a good reason why not14:34
lkcli'm not going to say "no" again.14:34
lkclwe have not got time14:34
markosnot saying you should do it14:34
markosbut for an experienced person, this should not be more than a couple of weeks14:34
lkcland the disruption - which i've witnessed every single message where all of you have not - has been immense14:34
lkcli have had to be the one answering 10, 15, 20, 30 messages14:34
markosyou're missing the point14:34
lkclno, it really won't be14:35
markoscurrent compilers used are already ancient14:35
lkclthe nixos developers took *over two months*14:35
lkclthat's not a problem at all14:35
lkclif the tools work, the tools work14:35
lkclif you need something else, you install it from source14:36
markosof course it is, if you want to get support for a new architecture upstream, eventually, you have to follow the moving target14:36
lkclyes, and that's perfectly fine too: follow the moving target by installing its source code within the stable base14:36
lkclpinned (as we do) through explicit installation of the specific git tag14:36
markoswhich may have newer dependencies than your current system provides14:36
lkclwhich is also not in the least bit a problem14:36
lkclunder which circumstances *those* get installed from source, too14:36
lkclwhich is also not in the least bit a problem14:37
markoswhich means you'll end up installing half the world from newer source on an ancient base system14:37
markossorry, I will definitely not do that14:37
lkcland when - and only when - it gets to 75% it will become a problem14:37
lkcl*you* don't have to - it's a matter of "run the script and sit back"14:37
markoshave done that multiple times in the past, and it's a PITA, you have no idea of the amount of work involved here14:37
lkcli don't know if you've seen some of the scripts for e.g. f4fpga?14:37
markosit's one thing to follow a compiler14:37
markosand quite another to follow a full system14:38
markosmight as well install gentoo14:38
lkclmarkos, i've been following the messages for two years14:38
lkclwhere you've been part-time14:38
markosI'm not saying it has to be done now14:38
lkclthe number of messages "i tried installing X and it didn't work" is overwhelming for me14:38
markosbut you have to add it in the tasks14:38
markosexactly why this will be more imperative in the future14:39
lkclbecause nobody else has been helping (except occasionally jacob)14:39
markosdebian 10 was oldstable which will be ok for a while yet14:39
markosbut not for long14:39
markosI did maintain a full repo for a full distro based on Debian for previous companies in the past14:40
markosso please trust me on this14:40
markosbecause they -again- did not want to base directly off a recent debian base14:40
markossoon, the amount of work involved will outweigh the risk14:41
markosthe risk of having a few problems from a migration that is14:41
markosso my advise on this, is please consider adding a task for at least investigating an upgrade14:42
lkcli know - i have had those same issues in the past as well.  i consider them *still less work for me* than to even investigate let alone schedule an upgrade.14:42
lkclthe answer's no.  *i* am not doing it.14:42
markosand please refrain from being always so adamant in rejecting a valid idea14:42
markosI never said you should do it14:42
lkclthe issue i have even with it being raised is that i have to check it14:43
*** octavius <octavius!> has joined #libre-soc14:43
lkcland i have to worry about the risk it will cause14:43
programmerjakewe can have precompiled .deb versions of software we need e.g. yosys so installation becomes much easier: create chroot, add apt source, apt install, add our dev repos that change a bunch...much simpler without needing hours/days of compiling code14:44
lkclit's too much14:44
octaviusCan we please leave this conversation for another time14:44
markosyes, that's exactly what I am suggesting, investigate and consider the risk, in an objective and calm manner14:44
lkclthat might work - it just leaves who is hosting the binaries? (it's not going to be the server)14:44
markosif it is indeed too much, then ok, reject it, but you reject it outright without even discussing it14:45
octaviusDo you have any idea why I'm getting the problem I mentioned above (about the memory cell)? Even though I'm using the right yosys version14:45
markosprogrammerjake, that's exactly the goal14:45
programmerjakeoctavius: sorry, idk14:45
markosVMs would be easier for some people, but a working repo would be the next best thing14:45
lkclmarkos, i'm not coping with the overload from the full implications, having been at the "shit end" of 2 years of people continuously submitting support requests14:46
lkcland then they don't actually do anything useful14:46
octaviusDoes anyone have a working chroot, where they can successfully build microwatt and substitute with libre-soc?14:46
lkclafter i spend days-to-weeks helping them14:46
lkclhaving stabilised the existing devscripts i am NOT going to subject myself to a destabilised system yet again14:47
markoslkcl, if you would be more willing to discuss, I would even suggest I pick the task myself, or together with eg. programmerjake, after all I've been doing that for years14:47
markosso you would never have to touch a line yourself14:47
lkclwill you also commit to the 2 years of answering the "support" requests?14:47
lkclthat's the real issue14:47
lkclthe continual inevitable questions, just as the one that happened yesterday14:48
programmerjakei can answer some of them but not all...14:48
lkcl"i have a dependency that didn't work because its git tag wasn't pinned"14:48
markosthat's something, I've been doing for years as well, you just have to know when to just close the bugs as 'wontfix' and send annoying requests to /dev/null14:48
lkclthat doesn't work for a "reproducible build" scenario14:48
lkclwhere you HAVE to produce IDENTICAL GDS-II files14:49
markosconsider this, right now you have only a few such requests because the project is low-profile still14:49
lkclif you have two engineers that have different GDS-II files14:49
markosif it starts picking up speed, you will have tons more such requests14:49
lkcland it is 3 days before the Foundry Deadline14:49
markosand I promise you it will be unmanageable14:49
markosbut point them to a repo and 90% of the problems will be solved14:49
markosor a working dev VM14:49
lkclthere will be more people, they can be requested to solve the issues and submit a patch to fix it14:50
programmerjakeby having precompiled yosys, etc. it helps with reproducibility because people are less likely to compile a different version14:50
lkclif they don't then yes, their bug gets /dev/null'd14:50
markosprogrammerjake, exactly14:50
lkclprogrammerjake, who is hosting them?14:50
lkclit's not going to be *.libre-soc.org14:50
programmerjakewhy not? i'd expect the pkgs to be <200MB...14:51
lkclaside from overwhelming the hosting (both in space and network bandwidth)14:51
lkclit makes the server a much higher value hacking target14:51
markosspace is something I would also provide, or toshywoshy, heck I have almost 100TB of storage14:51
lkclunless they are GPG-signed14:51
lkclwhich then in turn means that we then need GPG keys14:51
lkclwhich in turn need to be published as a keyring14:51
markoslkcl, well that's a good proposal in any case14:52
programmerjakeif server space is an issue, red semi or nlnet can fund $10/mo to get more space on that server14:52
programmerjakegpg keys are something we need to get anyway...14:52
lkcland i have to manage it.14:52
lkclplease stop14:52
lkcli can't cope14:52
markoslkcl, we're not saying you have to do it at all, let alone now, but can we please add these tasks for discussion on the agenda?14:53
lkclthe "simple" proposal has turned into a massive list spanning a hundred tasks, every single one of which i have to keep an eye on, many of which i am the only person who can do them14:53
markoshardly anything I mentioned is only doable by you14:54
programmerjakei could run a new pkgs server, though it might be better to have someone else since i have no experience creating/hosting package archives14:55
markosI have bootstrapped full debian on a new architecture in the past, twice, and ran an private debian autobuilder for 2 companies as well14:56
markosso I have a pretty good idea of what's needed, if we ever had to do such a thing14:56
markosbut we probably won't need something as needy14:56
markoswe just need a private repo on top of debian stable14:56
markosanyway, you obviously don't want to discuss this further, but please keep an open mind about this in a future meeting14:59
lkclin all honesty, i don't. and - being honest again: i am absolutely dreading that future meeting15:00
markosso you're saying you will keep using an ancient base system for ever? you will never upgrade because it takes time?15:02
markosI'll give you an example, I used to work with a team in Germany, in a video-codec related project and they had similar problems, the debian base was ancient -8 or 9 iirc- and they were refusing for years to upgrade because of lack of time and other reasons15:04
markosthey were afraid the software would not even work on newer systems and there would be many changes needed15:04
markosbut we -our team in Belgium- needed the newer debian base for other features and could not afford backport everything back to oldstable15:05
markosand it was a stale situation15:05
markosnothing would move15:05
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC15:05
markosand I took the initiative and took a system and upgraded it to the newer stable15:05
markosinstalled our software on top15:05
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc15:05
markosand in less than 30 minutes, I had a working system, turns out only a couple of dependencies were broken15:06
markosin 30 minutes I demonstrated it to the team in Germany and everyone was just amazed, not because I did something incredibly smart, but because no one else had thought to just test the stupid thing even once15:06
markosit goes without saying that we did a full upgrade on all systems after that and fixed all problems in a few weeks15:07
markosand both teams were happy15:07
lkclso, a piece of missing information: i actually run with debian/testing. everything i compile first in that, *then* i create (or ask someone to create) a chroot script15:08
lkclusing the same git tag as the one i had compiled in debian/testing15:09
markosso why the resistance?15:09
programmerjakewell, i've been testing with newer versions to some extent, no breakage that i recall...15:09
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC15:21
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc15:22
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC15:33
octaviusprogrammerjake, when were you last able to build a microwatt bitstream? I seem to remember you were experimenting with a maze game last year, cesar working on it too17:25
programmerjakemarch 4th 2022, i haven't tried since then17:28
octaviusCould tell me the git commit versions of the tools in that chroot? I'm trying to get all the pieces to be at the right version17:33
octaviusMaybe some of the debian apt packages have been updated since then17:33
octaviusAlso a log of installed pkg's (apt list --installed) in pastebin would be good to compare17:36
programmerjakeoh, i installed it on ubuntu, not in a chroot...lemme get you git commits...17:46
programmerjakeyosys eb5f9d9de61411d22944c105cf3800f121f9066617:47
programmerjakenextpnr 0a70b9c992c06a7553725b3742052eb95abd5f2017:49
programmerjakeprjtrellis 3ae21cf6a07f3883fafa5bf31e9104dfa6c9a63f17:49
programmerjakei did use the docker option for microwatt's makefile, so that's where i got ghdl and stuff, so those versions ^ may not have been used at all17:57
programmerjakei used:17:58
programmerjake`sudo make FPGA_TARGET=ORANGE-CRAB-0.21 dfuprog DOCKER=1 LITEDRAM_GHDL_ARG=-gUSE_LITEDRAM=false RAM_INIT_FILE=usb_3d_game/usb_3d_game.hex MEMORY_SIZE=$((1<<18))`17:58
programmerjakethat isn't necessarily what libre-soc needs tho...17:59
octaviusOk, nextpnr in the dev-scripts is different, so I'll try the one you used,18:54
octaviusalso where does dfuprog come from I didn't find it in apt18:55
programmerjakeoh, i forgot...19:03
programmerjakelemme look19:03
lkcldfuprog is in the dev-env-setup scripts19:03
lkcloctavius: remember to use "grep" on the contents of repositories to find keywords.19:03
octaviusAh yes, I apologise19:04
lkclthat was find-able with "grep dfu"19:04
octaviusInteresting, I ran that script19:04
lkclnotice we pin at version 0.1119:04
lkclit runs "make install"19:04
lkclby default everything should be in /usr/local/bin19:05
lkclis "/usr/local/bin" in your $PATH env var?19:05
lkclsometimes in a chroot it won't be19:05
octaviusI have dfu-prefix/suffix/util, but not prog19:05
lkcldfuprog... dfuprog...19:05
lkclwhat the heck *is* dfuprog, and why are you needing it?19:06
octaviusAnd searching for dfuprog on the internet didn't yield results (other than a forum post about windows)19:07
programmerjakei did apt install dfu-util from ubuntu focal19:07
lkclis it this one?
programmerjakedfuprog is the name of the target in microwatt's makefile19:07
lkclprogrammerjake, urr19:07
lkcli never use it19:07
programmerjakethe actual program it uses is dfu-util from apt19:07
programmerjakeoriginally from http://dfu-util.sourceforge.net19:08
lkcli bypass that and use a more standard ecp5-well-known method for uploading bitstreams19:08
lkclbut for orangecrab... what did i use..19:08
lkclyyeah i think i might have used dfu-util directly, by reading some of greg davill's posts19:08
octaviusgrep'ing for dfuprog I find nothing in microwatt repo (verilator_trace commit)19:08
lkclahh it's a makefile target name.19:09
lkclthe *actual* program needed is indeed dfu-util19:09
lkclthx programmerjake19:09
octaviusAh ok jacob, that's a different commit to our's though19:10
programmerjakei just grabbed the latest commit off github for the link19:10
programmerjakeit's not what i used when building19:11
programmerjakewell, i'll be offline for a while -- taking my phone apart to replace the battery...hopefully i don't break it19:12
octaviusgood luck :)19:12
*** octavius <octavius!> has quit IRC19:46
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc20:05

Generated by 2.17.1 by Marius Gedminas - find it at!