| octavius | Another problem I'm now hitting is during building of Microwatt for the orangecrab ecp5 target. | 00:46 |
|---|---|---|
| octavius | First, I follow the guide on the wiki page (https://libre-soc.org/HDL_workflow/microwatt/) up to the point where the verilator_trace branch is checked out. | 00:46 |
| octavius | Then I build an OrangeCrab bitstream using (make microwatt.bit). | 00:46 |
| octavius | Getting the following error: | 00:46 |
| octavius | Info: Annotating ports with timing budgets for target frequency 40.00 MHz | 00:46 |
| octavius | ERROR: cell type '$mem_v2' is unsupported (instantiated as 'soc0.processor_internal.processor.icache_0.itlb_tags') | 00:46 |
| octavius | 375 warnings, 1 error | 00:46 |
| octavius | make: *** [Makefile:275: microwatt_out.config] Error 255 | 00:46 |
| octavius | This is the design utilisation on ECP5: | 00:46 |
| octavius | Info: Logic utilisation before packing: | 00:47 |
| octavius | Info: Total LUT4s: 42698/83640 51% | 00:47 |
| octavius | Info: logic LUTs: 37246/83640 44% | 00:47 |
| octavius | Info: carry LUTs: 4084/83640 4% | 00:47 |
| octavius | Info: RAM LUTs: 912/41820 2% | 00:47 |
| octavius | Info: RAMW LUTs: 456/20910 2% | 00:47 |
| octavius | Info: Total DFFs: 26330/83640 31% | 00:47 |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 00:48 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 00:49 | |
| lkcl | octavius, you're using the wrong version of yosys. | 00:49 |
| lkcl | https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=hdl-tools-yosys;h=5b54555e527669039e32d945d15236f39b04629f;hb=8ba3bb16c61de637199bb80ba3b4d5861538f00f#l33 | 00:50 |
| lkcl | i use this: | 00:51 |
| lkcl | $ yosys --version | 00:51 |
| lkcl | Yosys 0.13 (git sha1 eb5f9d9de, clang 9.0.1-12 -fPIC -Os) | 00:51 |
| programmerjake | if you're curious, that bug, which only started in versions of yosys after what we use, is likely https://github.com/YosysHQ/yosys/issues/3205 | 00:52 |
| *** octavius <octavius!~octavius@92.40.168.253.threembb.co.uk> has quit IRC | 00:52 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 01:00 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 01:11 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 01:11 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 01:49 | |
| *** Ritish <Ritish!~Ritish@2409:4070:2cc6:4e1f:f4e5:8c5:aeea:b7cf> has joined #libre-soc | 04:22 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 04:30 | |
| *** Ritish <Ritish!~Ritish@2409:4070:2cc6:4e1f:f4e5:8c5:aeea:b7cf> has quit IRC | 05:43 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 06:42 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 06:53 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 06:54 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 07:06 | |
| *** Gayatri <Gayatri!~Gayatri@27.4.5.50> has joined #libre-soc | 07:50 | |
| *** Gayatri <Gayatri!~Gayatri@27.4.5.50> has quit IRC | 07:52 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 07:59 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 08:51 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.52.184> has joined #libre-soc | 08:52 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 09:12 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 09:44 | |
| *** midnight <midnight!~midnight@user/midnight> has quit IRC | 11:28 | |
| *** midnight <midnight!~midnight@user/midnight> has joined #libre-soc | 11:29 | |
| *** octavius <octavius!~octavius@92.40.169.188.threembb.co.uk> has joined #libre-soc | 11:34 | |
| octavius | Just checked, my yosys is also 0.13 (I used the hdl-tools-yosys as usual): | 11:35 |
| octavius | Yosys 0.13 (git sha1 eb5f9d9de, clang 7.0.1-8+deb10u2 -fPIC -Os) | 11:35 |
| octavius | But my clang is different | 11:35 |
| octavius | Checking clang version I get | 11:37 |
| octavius | clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final) | 11:37 |
| markos | 7? 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 ppc64le | 11:41 |
| markos | that would actually be a nice task | 11:42 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.52.184> has quit IRC | 11:44 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 11:46 | |
| octavius | markos, that's kind of where I was heading with my experimenting so far. | 11:47 |
| markos | cool | 11:47 |
| octavius | To have a stable chroot for fpga image building, power binary compilation, etc. | 11:48 |
| *** octavius <octavius!~octavius@92.40.169.188.threembb.co.uk> has quit IRC | 13:11 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 13:16 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 13:42 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 14:01 | |
| lkcl | markos, the amount of time it would take would be several WEEKS, followed by massive disruption for several MONTHS... for everyone | 14:31 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 14:32 | |
| lkcl | stabilising 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 |
| markos | not saying it should be done at the expense of other more important stuff, but it would certainly pay off in the end | 14:32 |
| lkcl | i'm not repeating that. | 14:32 |
| markos | debian 10 will soon be oldstable | 14:32 |
| lkcl | great! | 14:32 |
| markos | actually, wrong | 14:32 |
| markos | it's already oldstable | 14:32 |
| markos | 11 is current stable | 14:32 |
| markos | 12 will soon be next stable, and 10 will be oldoldstable | 14:33 |
| lkcl | if it "disappears" we find a mirror somewhere else. | 14:33 |
| lkcl | still have no problem with that | 14:33 |
| lkcl | really. | 14:33 |
| lkcl | it's not being upgraded, it's ... well... "Stable". | 14:33 |
| markos | we 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 others | 14:33 |
| programmerjake | imho we should spend the time to upgrade... | 14:33 |
| lkcl | no, no, no folks. | 14:33 |
| lkcl | no. | 14:34 |
| markos | give me a good reason why not | 14:34 |
| lkcl | i'm not going to say "no" again. | 14:34 |
| lkcl | time. | 14:34 |
| lkcl | we have not got time | 14:34 |
| markos | not saying you should do it | 14:34 |
| markos | but for an experienced person, this should not be more than a couple of weeks | 14:34 |
| lkcl | and the disruption - which i've witnessed every single message where all of you have not - has been immense | 14:34 |
| lkcl | i have had to be the one answering 10, 15, 20, 30 messages | 14:34 |
| markos | you're missing the point | 14:34 |
| lkcl | no, it really won't be | 14:35 |
| markos | current compilers used are already ancient | 14:35 |
| lkcl | the nixos developers took *over two months* | 14:35 |
| lkcl | that's not a problem at all | 14:35 |
| lkcl | if the tools work, the tools work | 14:35 |
| lkcl | if you need something else, you install it from source | 14:36 |
| markos | of course it is, if you want to get support for a new architecture upstream, eventually, you have to follow the moving target | 14:36 |
| lkcl | yes, and that's perfectly fine too: follow the moving target by installing its source code within the stable base | 14:36 |
| lkcl | pinned (as we do) through explicit installation of the specific git tag | 14:36 |
| markos | which may have newer dependencies than your current system provides | 14:36 |
| lkcl | which is also not in the least bit a problem | 14:36 |
| lkcl | under which circumstances *those* get installed from source, too | 14:36 |
| lkcl | which is also not in the least bit a problem | 14:37 |
| markos | which means you'll end up installing half the world from newer source on an ancient base system | 14:37 |
| lkcl | great! | 14:37 |
| markos | sorry, I will definitely not do that | 14:37 |
| lkcl | and when - and only when - it gets to 75% it will become a problem | 14:37 |
| lkcl | *you* don't have to - it's a matter of "run the script and sit back" | 14:37 |
| markos | have done that multiple times in the past, and it's a PITA, you have no idea of the amount of work involved here | 14:37 |
| lkcl | i don't know if you've seen some of the scripts for e.g. f4fpga? | 14:37 |
| markos | it's one thing to follow a compiler | 14:37 |
| markos | and quite another to follow a full system | 14:38 |
| markos | might as well install gentoo | 14:38 |
| lkcl | markos, i've been following the messages for two years | 14:38 |
| lkcl | where you've been part-time | 14:38 |
| markos | I'm not saying it has to be done now | 14:38 |
| lkcl | the number of messages "i tried installing X and it didn't work" is overwhelming for me | 14:38 |
| markos | but you have to add it in the tasks | 14:38 |
| markos | exactly why this will be more imperative in the future | 14:39 |
| lkcl | because nobody else has been helping (except occasionally jacob) | 14:39 |
| markos | debian 10 was oldstable which will be ok for a while yet | 14:39 |
| markos | but not for long | 14:39 |
| markos | I did maintain a full repo for a full distro based on Debian for previous companies in the past | 14:40 |
| markos | so please trust me on this | 14:40 |
| markos | because they -again- did not want to base directly off a recent debian base | 14:40 |
| markos | soon, the amount of work involved will outweigh the risk | 14:41 |
| markos | the risk of having a few problems from a migration that is | 14:41 |
| markos | so my advise on this, is please consider adding a task for at least investigating an upgrade | 14:42 |
| lkcl | i 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 |
| lkcl | the answer's no. *i* am not doing it. | 14:42 |
| markos | and please refrain from being always so adamant in rejecting a valid idea | 14:42 |
| markos | I never said you should do it | 14:42 |
| lkcl | the issue i have even with it being raised is that i have to check it | 14:43 |
| *** octavius <octavius!~octavius@92.40.169.188.threembb.co.uk> has joined #libre-soc | 14:43 | |
| lkcl | and i have to worry about the risk it will cause | 14:43 |
| lkcl | and | 14:43 |
| lkcl | and | 14:43 |
| lkcl | and | 14:43 |
| programmerjake | we 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 code | 14:44 |
| lkcl | it's too much | 14:44 |
| octavius | Can we please leave this conversation for another time | 14:44 |
| markos | yes, that's exactly what I am suggesting, investigate and consider the risk, in an objective and calm manner | 14:44 |
| lkcl | that might work - it just leaves who is hosting the binaries? (it's not going to be the libre-soc.org server) | 14:44 |
| markos | if it is indeed too much, then ok, reject it, but you reject it outright without even discussing it | 14:45 |
| octavius | Do 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 version | 14:45 |
| markos | programmerjake, that's exactly the goal | 14:45 |
| programmerjake | octavius: sorry, idk | 14:45 |
| octavius | ok | 14:45 |
| markos | VMs would be easier for some people, but a working repo would be the next best thing | 14:45 |
| lkcl | markos, 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 requests | 14:46 |
| lkcl | and then they don't actually do anything useful | 14:46 |
| octavius | Does anyone have a working chroot, where they can successfully build microwatt and substitute with libre-soc? | 14:46 |
| lkcl | after i spend days-to-weeks helping them | 14:46 |
| lkcl | having stabilised the existing devscripts i am NOT going to subject myself to a destabilised system yet again | 14:47 |
| markos | lkcl, 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 years | 14:47 |
| markos | so you would never have to touch a line yourself | 14:47 |
| lkcl | will you also commit to the 2 years of answering the "support" requests? | 14:47 |
| lkcl | that's the real issue | 14:47 |
| lkcl | the continual inevitable questions, just as the one that happened yesterday | 14:48 |
| programmerjake | i 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 |
| markos | that'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/null | 14:48 |
| lkcl | that doesn't work for a "reproducible build" scenario | 14:48 |
| lkcl | where you HAVE to produce IDENTICAL GDS-II files | 14:49 |
| lkcl | unfortunately | 14:49 |
| markos | consider this, right now you have only a few such requests because the project is low-profile still | 14:49 |
| lkcl | if you have two engineers that have different GDS-II files | 14:49 |
| markos | if it starts picking up speed, you will have tons more such requests | 14:49 |
| lkcl | and it is 3 days before the Foundry Deadline | 14:49 |
| markos | and I promise you it will be unmanageable | 14:49 |
| markos | but point them to a repo and 90% of the problems will be solved | 14:49 |
| markos | or a working dev VM | 14:49 |
| lkcl | there will be more people, they can be requested to solve the issues and submit a patch to fix it | 14:50 |
| programmerjake | by having precompiled yosys, etc. it helps with reproducibility because people are less likely to compile a different version | 14:50 |
| lkcl | if they don't then yes, their bug gets /dev/null'd | 14:50 |
| markos | programmerjake, exactly | 14:50 |
| lkcl | programmerjake, who is hosting them? | 14:50 |
| lkcl | it's not going to be *.libre-soc.org | 14:50 |
| programmerjake | why not? i'd expect the pkgs to be <200MB... | 14:51 |
| lkcl | aside from overwhelming the hosting (both in space and network bandwidth) | 14:51 |
| lkcl | it makes the server a much higher value hacking target | 14:51 |
| markos | space is something I would also provide, or toshywoshy, heck I have almost 100TB of storage | 14:51 |
| lkcl | unless they are GPG-signed | 14:51 |
| lkcl | which then in turn means that we then need GPG keys | 14:51 |
| lkcl | which in turn need to be published as a keyring | 14:51 |
| lkcl | etc. | 14:52 |
| markos | lkcl, well that's a good proposal in any case | 14:52 |
| lkcl | etc. | 14:52 |
| lkcl | etc. | 14:52 |
| lkcl | etc. | 14:52 |
| lkcl | etc. | 14:52 |
| programmerjake | if server space is an issue, red semi or nlnet can fund $10/mo to get more space on that server | 14:52 |
| programmerjake | gpg keys are something we need to get anyway... | 14:52 |
| lkcl | and i have to manage it. | 14:52 |
| lkcl | no | 14:52 |
| lkcl | please stop | 14:52 |
| lkcl | i can't cope | 14:52 |
| markos | lkcl, 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 |
| lkcl | the "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 them | 14:53 |
| markos | hardly anything I mentioned is only doable by you | 14:54 |
| programmerjake | i could run a new pkgs server, though it might be better to have someone else since i have no experience creating/hosting package archives | 14:55 |
| markos | I have bootstrapped full debian on a new architecture in the past, twice, and ran an private debian autobuilder for 2 companies as well | 14:56 |
| markos | so I have a pretty good idea of what's needed, if we ever had to do such a thing | 14:56 |
| markos | but we probably won't need something as needy | 14:56 |
| markos | we just need a private repo on top of debian stable | 14:56 |
| markos | s/private/public | 14:57 |
| markos | anyway, you obviously don't want to discuss this further, but please keep an open mind about this in a future meeting | 14:59 |
| lkcl | in all honesty, i don't. and - being honest again: i am absolutely dreading that future meeting | 15:00 |
| markos | so you're saying you will keep using an ancient base system for ever? you will never upgrade because it takes time? | 15:02 |
| markos | I'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 reasons | 15:04 |
| markos | they were afraid the software would not even work on newer systems and there would be many changes needed | 15:04 |
| markos | but we -our team in Belgium- needed the newer debian base for other features and could not afford backport everything back to oldstable | 15:05 |
| markos | and it was a stale situation | 15:05 |
| markos | nothing would move | 15:05 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 15:05 | |
| markos | and I took the initiative and took a system and upgraded it to the newer stable | 15:05 |
| markos | installed our software on top | 15:05 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.164.141> has joined #libre-soc | 15:05 | |
| markos | and in less than 30 minutes, I had a working system, turns out only a couple of dependencies were broken | 15:06 |
| markos | in 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 once | 15:06 |
| markos | it goes without saying that we did a full upgrade on all systems after that and fixed all problems in a few weeks | 15:07 |
| markos | and both teams were happy | 15:07 |
| markos | </story> | 15:08 |
| lkcl | so, 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 script | 15:08 |
| lkcl | using the same git tag as the one i had compiled in debian/testing | 15:09 |
| markos | so why the resistance? | 15:09 |
| programmerjake | well, i've been testing with newer versions to some extent, no breakage that i recall... | 15:09 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.164.141> has quit IRC | 15:21 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.174> has joined #libre-soc | 15:22 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.174> has quit IRC | 15:33 | |
| octavius | programmerjake, 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 too | 17:25 |
| programmerjake | march 4th 2022, i haven't tried since then | 17:28 |
| octavius | Could 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 version | 17:33 |
| octavius | Maybe some of the debian apt packages have been updated since then | 17:33 |
| octavius | Also a log of installed pkg's (apt list --installed) in pastebin would be good to compare | 17:36 |
| programmerjake | oh, i installed it on ubuntu, not in a chroot...lemme get you git commits... | 17:46 |
| programmerjake | yosys eb5f9d9de61411d22944c105cf3800f121f90666 | 17:47 |
| programmerjake | nextpnr 0a70b9c992c06a7553725b3742052eb95abd5f20 | 17:49 |
| programmerjake | prjtrellis 3ae21cf6a07f3883fafa5bf31e9104dfa6c9a63f | 17:49 |
| programmerjake | i 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 all | 17:57 |
| programmerjake | i 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 |
| programmerjake | that isn't necessarily what libre-soc needs tho... | 17:59 |
| octavius | Ok, nextpnr in the dev-scripts is different, so I'll try the one you used, | 18:54 |
| octavius | also where does dfuprog come from I didn't find it in apt | 18:55 |
| programmerjake | oh, i forgot... | 19:03 |
| programmerjake | lemme look | 19:03 |
| lkcl | dfuprog is in the dev-env-setup scripts | 19:03 |
| lkcl | octavius: remember to use "grep" on the contents of repositories to find keywords. | 19:03 |
| lkcl | https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=fpga-boot-load-prog-install;h=526c1deb90dbab4b41262e12bb59d9f490680f42;hb=8ba3bb16c61de637199bb80ba3b4d5861538f00f#l14 | 19:04 |
| octavius | Ah yes, I apologise | 19:04 |
| lkcl | that was find-able with "grep dfu" | 19:04 |
| octavius | Interesting, I ran that script | 19:04 |
| lkcl | notice we pin at version 0.11 | 19:04 |
| lkcl | hmmm | 19:04 |
| lkcl | it runs "make install" | 19:04 |
| lkcl | by default everything should be in /usr/local/bin | 19:05 |
| lkcl | is "/usr/local/bin" in your $PATH env var? | 19:05 |
| lkcl | sometimes in a chroot it won't be | 19:05 |
| octavius | yes | 19:05 |
| octavius | I have dfu-prefix/suffix/util, but not prog | 19:05 |
| lkcl | dfuprog... dfuprog... | 19:05 |
| lkcl | what the heck *is* dfuprog, and why are you needing it? | 19:06 |
| octavius | And searching for dfuprog on the internet didn't yield results (other than a forum post about windows) | 19:07 |
| programmerjake | i did apt install dfu-util from ubuntu focal | 19:07 |
| lkcl | is it this one? https://dfu-programmer.github.io/ | 19:07 |
| programmerjake | dfuprog is the name of the target in microwatt's makefile | 19:07 |
| lkcl | programmerjake, urr | 19:07 |
| lkcl | ahh | 19:07 |
| lkcl | i never use it | 19:07 |
| programmerjake | the actual program it uses is dfu-util from apt | 19:07 |
| programmerjake | originally from http://dfu-util.sourceforge.net | 19:08 |
| lkcl | i bypass that and use a more standard ecp5-well-known method for uploading bitstreams | 19:08 |
| lkcl | but for orangecrab... what did i use.. | 19:08 |
| lkcl | yyeah i think i might have used dfu-util directly, by reading some of greg davill's posts | 19:08 |
| octavius | grep'ing for dfuprog I find nothing in microwatt repo (verilator_trace commit) | 19:08 |
| programmerjake | https://github.com/antonblanchard/microwatt/blob/da5d3ded3c2e442cc12bfe86c077124f68a372e2/Makefile#L274 | 19:09 |
| lkcl | ahh it's a makefile target name. | 19:09 |
| lkcl | the *actual* program needed is indeed dfu-util | 19:09 |
| lkcl | thx programmerjake | 19:09 |
| octavius | Ah ok jacob, that's a different commit to our's though | 19:10 |
| programmerjake | i just grabbed the latest commit off github for the link | 19:10 |
| programmerjake | it's not what i used when building | 19:11 |
| programmerjake | well, i'll be offline for a while -- taking my phone apart to replace the battery...hopefully i don't break it | 19:12 |
| octavius | good luck :) | 19:12 |
| programmerjake | ttyl | 19:12 |
| programmerjake | thx! | 19:12 |
| *** octavius <octavius!~octavius@92.40.169.188.threembb.co.uk> has quit IRC | 19:46 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 20:05 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!