sadoon_albader[m | Hey guys | 07:09 |
---|---|---|
sadoon_albader[m | life has been crazy | 07:09 |
sadoon_albader[m | I'm trying to get back to this and starting to learn things | 07:09 |
sadoon_albader[m | So after installing using the devscripts I couldn't find the decoder in the soc repo | 07:11 |
sadoon_albader[m | On the main page of the project I found this "python3 src/soc/decoder/power_decoder.py" and so I'm confused, shouldn't the decoder be there after the install process or have I messed up somewhere? | 07:11 |
sadoon_albader[m | huh strange, I found it in src/soc/src/soc/decoder | 07:13 |
sadoon_albader[m | Ok I was being stupid nvm | 07:13 |
sadoon_albader[m | It's clearly supposed to be there lol | 07:13 |
programmerjake | most code on the wiki expect you to be in the root directory of whatever git repo the code is for, so in this case, they expect you to be in soc.git's root directory | 07:23 |
sadoon_albader[m | now I know :D | 07:24 |
programmerjake | :) | 07:25 |
tplaten | I had a look at https://bugs.libre-soc.org/show_bug.cgi?id=756, this should be easy to fix. | 09:56 |
tplaten | I guess that the same flags will be used for instruction fetch, so I will have a look at microwatt source code. | 09:57 |
lkcl | i tend to cd soc/src then run editors etc from there | 10:52 |
lkcl | otherwise half the time is spent typing "cd" | 10:53 |
lkcl | tplaten, the idea occurred to me to replace the msr_pr argument with a NamedTuple containing msr.pr, msr.dr, and anything else needed | 10:54 |
lkcl | otherwise we keep jamming in more and more arguments | 10:54 |
lkcl | and you missed a couple on one of the PortInterface unit tests | 10:54 |
tplaten | I'll fix that | 10:54 |
tplaten | Too may, I did a grep | 10:57 |
tplaten | fixed experiment/compldst_multi.py, but not commited yet | 11:04 |
tplaten | I agree with the NamedTuple thing | 11:05 |
tplaten | Instead passing msr_pr=0, I propose something like msr = {'pr': 0, 'dr': 0, 'sf': 1} | 11:32 |
tplaten | I got it | 11:48 |
tplaten | from collections import namedtuple | 11:48 |
tplaten | MSRSpec = namedtuple("MSRSpec", ["dr", "pr", "sf"]) | 11:48 |
tplaten | test_spec = MSRSpec(dr=1,pr=0,sf=1) | 11:48 |
tplaten | print(test_spec) | 11:48 |
lkcl | tplaten: that's the idea | 12:03 |
lkcl | or in the HDL it would be | 12:03 |
lkcl | test_spec = MSRSpec(dr=msr_i[MSR.DR], pr=msr_i[MSR.PR], ....) | 12:04 |
lkcl | ./experiment/compldst_multi.py: comb += pi.msr_pr.eq(oper_r.msr[MSR.PR]) | 12:05 |
lkcl | msr_spec = MSRSpec(dr=oper_r.msr[MSR.DR], pr=oper_r.msr[MSR.PR], ....) | 12:06 |
lkcl | MSRSpec namedtuple should probably go iiin.... mmmm..... power_enums.py | 12:06 |
lkcl | or in consts.py | 12:07 |
lkcl | just after class MSR | 12:07 |
tplaten | I'll correct that, since it landed in src/soc/experiment/pimem.py | 12:08 |
lkcl | ack | 12:09 |
lkcl | it needs to actually be used in the HDL, right down in compldst_multi.py | 12:09 |
lkcl | not just in the unit tests | 12:10 |
lkcl | and ISACaller could potentially use it although it tends to just pass around all SPRs and regs and gets on with it | 12:10 |
tplaten | power_enums.py already imports namedtuple, so I'll add it there, this will be one line change | 12:11 |
tplaten | done: https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=218bb6e7b25bbfaaa86727a620d48b3d0ee94bba | 12:18 |
lkcl | fantastic | 12:19 |
lkcl | i'll look at compldst_multi.py | 12:20 |
lkcl | unless you're already doing it? | 12:20 |
tplaten | No, I will be working on the other things | 12:20 |
lkcl | ok | 12:20 |
lkcl | tplaten, i changed the name in pimem.py of the msr_pr variable to just msr | 12:27 |
lkcl | - def set_wr_addr(self, m, addr, mask, misalign, msr_pr, is_dcbz): | 12:27 |
lkcl | + def set_wr_addr(self, m, addr, mask, misalign, msr, is_dcbz): | 12:27 |
lkcl | everything should still work | 12:27 |
tplaten | I agree, had the same change in mind | 12:27 |
lkcl | ah. compldst_multi.py is now broken because portinterface has msr_pr removed, whoops. | 12:29 |
lkcl | that could be sorted with a temporary variable-name, which, hmmm, RecordObject won't like, hmmm... | 12:30 |
lkcl | ok going into overdrive to sort that out | 12:30 |
lkcl | i think one simple rename has the unit tests sorted (whew) | 12:33 |
tplaten | having a look at the changes from the recent 10 minutes | 12:38 |
lkcl | erm, ermerm... we miiight have had priv_mode inverted in LDSTCompUnit, whoops | 12:38 |
tplaten | I just saw, PR=problem state not to be confused with priv | 12:40 |
lkcl | yes, they're inverted, as best i can tell from the microwatt source | 12:40 |
lkcl | ok just setting pi.virt_mode etc. in LDSTCompUnit. | 12:43 |
lkcl | do another git pull | 12:43 |
lkcl | i need to re-add MSR to the MMU FSM | 12:44 |
lkcl | can you do the conversion of msr_pr everywhere to use msr.pr (etc.) instead? | 12:44 |
lkcl | pimem.py | 12:44 |
lkcl | self.set_rd_addr(m, pi.addr.data, lenexp.lexp_o, misalign, pr) | 12:44 |
lkcl | --> | 12:45 |
lkcl | self.set_rd_addr(m, pi.addr.data, lenexp.lexp_o, misalign, msr) | 12:45 |
lkcl | i removed MSR from the MMU FSM because it was LoadStore1 that was handling it | 12:45 |
lkcl | but, ironically, OP_FETCH_FAILED needs to set mmu.priv_mode/virt_mode directly itself, sigh | 12:46 |
lkcl | tplaten, do do another git pull, i had to import MSRSpec in pimem.py | 12:48 |
tplaten | done | 12:50 |
lkcl | star | 12:54 |
tplaten | I updated test_pi2ls.py | 12:55 |
lkcl | great | 12:55 |
lkcl | File "experiment/test/test_ldst_pi.py", line 48, in mmu_lookup | 12:56 |
lkcl | data, _, _ = yield from pi_ld(dut.submodules.ldst.pi, addr, 4, msr_pr=1) | 12:56 |
lkcl | TypeError: pi_ld() got an unexpected keyword argument 'msr_pr' | 12:56 |
lkcl | there will now be quite a few of these | 12:56 |
lkcl | including fu/ldst/loadstore.py (i will do that one) | 12:57 |
tplaten | I did a grep, there are many of those | 12:58 |
lkcl | indeed :) | 12:58 |
tplaten | currently I am fixing test_dcbz_pi.py | 12:58 |
lkcl | loadstore1.py done | 13:01 |
lkcl | will do pimem.py now | 13:01 |
lkcl | done | 13:02 |
lkcl | test_loadstore1.py next | 13:02 |
lkcl | ah. needs an MSRSpec | 13:02 |
lkcl | done but it doesn't terminate. | 13:09 |
lkcl | need to investigate | 13:09 |
tplaten | having a look at src/soc/experiment/test/test_ldst_pi.py | 13:29 |
lkcl | tplaten, | 14:15 |
lkcl | File "experiment/test/test_ldst_pi_misalign.py", line 30, in <module> | 14:15 |
lkcl | msr_default = MSRSpec(pr=1, dr=0, sf=1) # 64 bit by default | 14:15 |
lkcl | NameError: name 'MSRSpec' is not defined | 14:15 |
tplaten | I'll fix that | 14:16 |
lkcl | done already | 14:16 |
lkcl | but it doesn't terminate | 14:16 |
lkcl | there's something broken now, probably in pi_ld | 14:16 |
lkcl | ahh pr is now inverted | 14:18 |
lkcl | that's what it is | 14:18 |
lkcl | msr_default = MSRSpec(pr=0, dr=0, sf=1) # 64 bit by default | 14:19 |
lkcl | not pr=1 | 14:19 |
lkcl | yep that's it | 14:20 |
tplaten | I did a git pull | 14:20 |
lkcl | i just fixed test_loadstore1.py as well | 14:22 |
lkcl | for the invalid exception case, pr must be 1 | 14:22 |
lkcl | but for the others, pr=0 which sets priv_mode=HI and then the tests work | 14:22 |
markos | hello | 14:24 |
markos | here on invitation by lkcl :) | 14:25 |
tplaten | having a look at test_loadstore1.py | 14:36 |
tplaten | src/soc/experiment/test/test_loadstore1.py: #ld_data, exctype, exc = yield from pi_ld(pi, virt_addr, 8, msr_pr=0) | 14:55 |
tplaten | ill fix that one | 14:55 |
lkcl | markos, oh allo :) | 15:00 |
lkcl | welcome | 15:00 |
markos | thank you | 15:02 |
markos | reading documentation now, there is a lot of information there | 15:02 |
lkcl | indeed. this is not a small project | 15:02 |
lkcl | minerva rv32 is 4,000 lines. | 15:02 |
markos | want to get a working installation first, before I actually commit to anything, I wouldn't want to embarass myself in case I'm in over my head :) | 15:03 |
lkcl | this one is 150,000 with about 25% completion of the target HDL, and increasing | 15:03 |
lkcl | :) | 15:03 |
lkcl | a brain-dead way to achieve that: | 15:04 |
lkcl | https://libre-soc.org/HDL_workflow/devscripts/ | 15:04 |
lkcl | running the schroot scripts, *be careful*. | 15:05 |
markos | you mention debian 10 as dev environment, is that still so or can debian 11 can be used as well? | 15:05 |
lkcl | it has to operate as root, and makes modifications to... | 15:05 |
markos | (on ppc64le) | 15:05 |
lkcl | if you do you're on your own | 15:05 |
lkcl | one way round that is to install debian 11 | 15:05 |
lkcl | then use the schroot script to set up a debian 10 chroot | 15:06 |
markos | ok, I'll just create a debian 10 vm on my talos then | 15:06 |
lkcl | then - and this is where you have to be REALLY careful - bind-mount the home directory (or source subdirectory) into the debian 11 version | 15:06 |
lkcl | i have i think around 4 different schroots at the moment because i run with debian/testing | 15:06 |
lkcl | but kept python 3.7 around | 15:07 |
lkcl | of course, now, nothing will upgrade, hence i now have some programs (klayout) specifically in a chroot | 15:07 |
lkcl | oo you have a TALOS-II? | 15:08 |
markos | yup, with about 150G of RAM :) | 15:08 |
lkcl | niiice | 15:08 |
tplaten | I have a Talos II, and recently started porting Intel Embree to it. Plan to run Embree on the Libre-SOC too. | 15:09 |
lkcl | yet it still falls over if you try to build 3 very large packages at the same time, thanks to the new binutils maintainers ripping out Dr Stallman's "in-memory-only" algorithms in the mid 90s | 15:09 |
lkcl | because 640k^H^H^H^H 4GB should be enough for everyone | 15:09 |
tplaten | The last remaining ones are src/soc/experiment/test/test_compldst_multi.py and src/soc/experiment/pimem.py | 15:10 |
lkcl | nice | 15:10 |
lkcl | tplaten, ack | 15:10 |
lkcl | Ran 1 test in 0.058s | 15:10 |
lkcl | OK | 15:10 |
lkcl | lkcl@fizzy:~/src/libresoc/soc/src/soc$ python3 experiment/test/test_compldst_multi.py | 15:10 |
lkcl | works fine | 15:10 |
tplaten | The test still hangs, I tested with different flags, marked with ? in the commtned out thing | 15:10 |
tplaten | only if I undo the comment out thing | 15:11 |
lkcl | tplaten, did you git pull? it works perfectly here | 15:11 |
lkcl | commit c6cfd46e4c19dfa8c7b36ac39f6c7974df69ff2c | 15:11 |
lkcl | fix test_loadstore1.py with MSR=PR/DR | 15:12 |
lkcl | for invalid test pr=1 but for others pr=0 | 15:12 |
tplaten | I did | 15:12 |
lkcl | hmmm | 15:12 |
tplaten | only if i uncomment the following line: # ld_data, exctype, exc = yield from pi_ld(pi, virt_addr, 8, msr=msr) | 15:12 |
lkcl | where? | 15:12 |
tplaten | else it runs | 15:12 |
tplaten | line 341 | 15:13 |
lkcl | in.. | 15:13 |
lkcl | in which file? | 15:13 |
lkcl | tplaten, which source code file? | 15:15 |
tplaten | soc/src/soc/experiment/test/test_loadstore1.py | 15:15 |
lkcl | ok great | 15:16 |
lkcl | bizarre, i don't understand what's going on, it works fine here (no need to set ldst.instr_fault.eq(0) | 15:17 |
lkcl | no need to coment that out | 15:17 |
lkcl | it does make sense though | 15:17 |
lkcl | no it doesn't, because i capture it. it's only supposed to be set once | 15:19 |
lkcl | (blipped) | 15:19 |
lkcl | if ldst.instr_fault is left HI it will request multiple MMU_LOOKUPs. | 15:20 |
tplaten | Now I have a look at src/soc/experiment/icache.py, I began writing a unit test for it this morning | 15:43 |
markos | in a debian10 lxc right now, I'm getting "Failed sending HTTP request" while cloning the dev-env-setup.git repo, any ideas? | 17:15 |
octavius | Which git clone url are you using? | 17:16 |
octavius | This is the one in my one: gitolite3@git.libre-soc.org:dev-env-setup.git | 17:16 |
markos | https://git.libre-soc.org/git/dev-env-setup.git/ | 17:19 |
octavius | Change it to the gitolite3 one | 17:19 |
octavius | The one you used is a read-only repo, however the HTTP issue might be due to https (I seem to remember having this issue when I started 3 months ago, on debian 10/buster) | 17:21 |
markos | http works, the git needs access to the repo which I do not have yet | 17:22 |
lkcl | octavius, marko, yes, gitolite3 (ssh keys) needs agreeing to the charter, first. | 17:23 |
octavius | Then stick with the public one until lkcl gets you access ;) | 17:23 |
lkcl | if you're using https you miiight need apt-transport-https | 17:23 |
lkcl | apt-get install apt-transport-https | 17:24 |
lkcl | but all the URLs in all the documentation should be http:// | 17:24 |
lkcl | NOT | 17:24 |
lkcl | nttps:// | 17:24 |
lkcl | for exactly this reason | 17:24 |
lkcl | whoever thought that encrypting publicly-accessible ("known plaintext") repositories with HTTPS clearly has f***-all idea about cryptography. | 17:25 |
lkcl | sigh | 17:25 |
lkcl | "eww because it's more sek-ew-aah" | 17:25 |
lkcl | i had a *three* week argument with half a dozen people about that one, once. trying to educate people that putting repos onto HTTPS-only simply makes the client *and server* a high-value hacking target | 17:26 |
octavius | I think a lot of people mis-understand the point of encryption and privacy. Ah so what you're saying is if a hacker sees a plain ol' HTTP server, he wouldn't even bother looking at it? | 17:28 |
lkcl | no, they'll go "yippee" with a MITM attack :) | 17:29 |
lkcl | except if the packages being downloaded have been GPG-signed with offline-inaccessible keys | 17:29 |
lkcl | whereupon they'll go "oh poop, forget it" | 17:29 |
octavius | Do you mean that if HTTPS is downgraded to HTTP, the hacker can fake the connection? | 17:30 |
lkcl | yes. | 17:30 |
octavius | Ah right, because it's all plaintext | 17:30 |
lkcl | but simply having HTTPS does *not* make the data secure... because a hacker can target the server | 17:30 |
lkcl | hack in to it | 17:30 |
markos | it doesn't have to be a hacker, it's called transparent http proxy :) | 17:30 |
lkcl | and *still replace the data being downloaded* | 17:31 |
lkcl | yehyeh :) | 17:31 |
octavius | hehehe | 17:31 |
lkcl | funniest situation i ever saw of a transparent proxy gone wrong was a china ISP | 17:31 |
lkcl | i visited angband.pl and was getting debian packages being downloaded from http://172.16.21.1/angband.pl/debian/.... | 17:32 |
lkcl | i went "wtf" until i realised that they must have been using a home-made transparent HTTP proxy... | 17:32 |
lkcl | as a *perl* script :) | 17:32 |
lkcl | .pl | 17:32 |
lkcl | which their IT staff must have allowed special rules for in their config. | 17:33 |
octavius | Niiice | 17:38 |
octavius | also, thanks for another quaint website, I've collected quite a few now :) | 17:39 |
lkcl | that one sadly the developer kilobyte stopped doing recompiled versions of debian packages without systemd | 17:45 |
lkcl | because of devuan | 17:45 |
lkcl | sigh | 17:45 |
octavius | Ah, he thought it wasn't worth the effort if devuan already has them | 17:46 |
lkcl | correct | 17:46 |
lkcl | not realising that devuan only works on stable-to-stable | 17:46 |
lkcl | and that *his* work worked perfectly well with *standard debian* - even debian/testing systems | 17:47 |
octavius | So does this mean you now have to compile yourself? Or have you found another packager? | 17:47 |
lkcl | no, very annoyingly i was forced into a situation of installing libsystemd0 | 17:48 |
lkcl | then the debian sysvinit services make installing systemd redundant... | 17:48 |
lkcl | but what's particularly irkesome is that systemd continues to "infect" more and more packages | 17:49 |
lkcl | angband.pl was designed to test exactly that situation | 17:49 |
lkcl | to stop people from infecting debian with the assumption that "anything other than systemd init can go f*** itself" | 17:49 |
octavius | Ah, that library provides (essentially) hard dependencies, without the rest of systemd | 17:49 |
lkcl | correct. | 17:49 |
lkcl | and many package maintainers have terminated provision of /etc/init.d/* scripts | 17:50 |
octavius | It does amaze me that having more choice of init systems is generally frowned upon | 17:50 |
lkcl | they'll stop frowning when they see the CVE mitre list of vulnerabilities for systemd | 17:50 |
octavius | Is systemd *really* that good? It provides convinient service creation (if you don't know how to create a symlink) | 17:50 |
lkcl | is Windows NT's service management system *really* that good? | 17:51 |
lkcl | you honestly think it's a good idea that PID 1 be allowed to control your firewall, network, and filesystem mounts? | 17:52 |
octavius | I did struggle when learning gentoo, cause it's usually expected for the user to know about openrc or runit (or other). But that's before I was reading man pages full-time | 17:52 |
octavius | Yes, sounds like a wonderful idea :P | 17:52 |
octavius | Please give me more bloat, that's exactly why I left win in the first place | 17:53 |
lkcl | tobias: wb_get only copes with 64-bit address offsets | 18:17 |
lkcl | so be careful with that one: i got caught out putting data into the dict at 4-byte offsets then wondered why it wouldn't show up | 18:19 |
lkcl | markos, one thing, lauri did request that we not depend on anything outside of the openpower-isa directory | 18:41 |
lkcl | so you should be able to get up and running without soc, ieee754, etc. but you will still need nmigen because the simulator ISACaller depends on it | 18:42 |
lkcl | decoding Power ISA instructions is such a large task we're not duplicating the code that does it | 18:42 |
ghostmansd[m] | lkcl, checked your comments in 550, I hope to continue with it on this week | 18:43 |
lkcl | mikolajw is even doing a nmigen-to-c-converter so we can avoid having to maintain 2 (or more) copies of identical Power ISA decoders | 18:43 |
lkcl | ghostmansd[m], star | 18:43 |
lkcl | markos is a SIMD expert who is evaluating taking over where Lauri was not able to continue due to health | 18:44 |
lkcl | so what you're doing, he could really use (and help test it) | 18:44 |
lkcl | pysvp64asm is the command-line equivalent of what you're doing | 18:45 |
lkcl | which replaces "sv.xxxx" with ".long yyyyyy; v30basmop" | 18:45 |
lkcl | i had to add basic support for gnu-as macros into pysvp64asm | 18:45 |
lkcl | ghostmansd[m], what you did's a pretty good start | 18:46 |
lkcl | likewise mikolajw | 18:47 |
ghostmansd[m] | Thanks! I hope that it will go smoothly. | 18:50 |
lkcl | there are some (new, draft) 32-bit ops that need adding as well btw | 18:52 |
lkcl | ternlogi is one of the latest ones | 18:52 |
lkcl | they'll all need to go under a special "--experimental" option | 18:53 |
lkcl | lxo, hello, if you're around, what's the procedure for that? | 18:53 |
lxo | I'm getting into a call in 3 minutes, and I couldn't figure out what the 'that' refers to. I'll try to figure it out when the meeting is over, some 90 minutes from now | 18:57 |
lxo | but I wouldn't mind if you'd expand what it is that you mean to ask, lkcl | 18:57 |
lxo | if you mean what's the procedure for new opcodes to be regarded as experimental in the GNU assembler, I don't think there is one. each opcode is marked with processor variant identifiers, and that's where this should go IMHO | 19:03 |
markos | lkcl, thanks I'll keep that in mind | 19:04 |
lxo | lkcl, I'm back. was that it? | 20:12 |
lkcl | lxo, nice to hear from you. in essence, yes: there must be a "best practice" for enabling experimental (draft) ISA features in upstream binutils, | 20:24 |
lkcl | i was wondering if you knew what it was? | 20:25 |
programmerjake | iirc, for risc-v, last i knew, the best practice was experimental instructions never go in upstream binutils | 20:27 |
programmerjake | that may have changed since then (several years ago) | 20:28 |
lkcl | mm fun. if so, we're maintaining a binutils fork for NN+ months. joy | 20:28 |
lxo | there's no general rule that applies to all binutils targets, and ppc is particularly tricky because of all the existing variants, but that's the way to go. ELF arch variant bits are in short supply so getting one for experimental stuff may be tricky, but I didn't get the notion that this was what the question was about | 20:29 |
lxo | I'm glad to be able to help, little as it is | 20:30 |
lxo | I shall try to dial in for a meeting one of these days and catch up. I seem to have sorted out my internet service, I might even be able to get video up now :-) | 20:30 |
lkcl | well, svp64 itself is almost certainly going to need one | 20:30 |
lkcl | but not the computer overheating due to over-active WebRTC? :) | 20:31 |
programmerjake | we'll be glad to see you again! | 20:31 |
lxo | I've got an external "cooling fan" now ;-) | 20:32 |
lxo | lkcl, yeah, I suppose there's a process within OpenPower to assign bits for these purposes, it's not something GNU binutils could/should decide on its own | 20:33 |
lkcl | yeah me too. one at the side and one underneath. with annoying blue LEDs | 20:33 |
lkcl | interesting. have to raise that on wednesday | 20:33 |
lxo | but again I think that's not what the question was about, just about binutils-internal marking of instructions, which requires nothing about buy-in from maintainers | 20:33 |
lkcl | well i'm glad it brought this up too | 20:34 |
lxo | I'm using usb 3"-4" fans these days | 20:35 |
lxo | I like to joke that I buy them at a web shop named onlyfans ;-) | 20:37 |
markos | I just got an error running hdl-dev-repos near the end (I think): | 20:38 |
markos | IndexError: list assignment index out of range | 20:38 |
markos | make: *** [Makefile:10: mkpinmux] Error 1 | 20:38 |
markos | is that expected/harmless? | 20:38 |
octavius | The pinmux repo needs to be updated | 20:38 |
octavius | let's see... | 20:38 |
octavius | git submodule update --init | 20:39 |
octavius | call that inside src/soc | 20:39 |
markos | rerun the cmds, fails in make mkpinmux | 20:41 |
octavius | still the same error? | 20:42 |
markos | in commit 20ca612b2600530ce901009b3d1b9ef0e05b7438 | 20:42 |
markos | yes | 20:42 |
markos | full traceback: | 20:42 |
markos | Traceback (most recent call last): | 20:43 |
markos | File "src/pinmux_generator.py", line 101, in <module> | 20:43 |
markos | pm, chip = jsoncreate.pinparse(ps, pinspec) | 20:43 |
markos | File "/home/markos/src/soc/pinmux/src/jsoncreate.py", line 217, in pinparse | 20:43 |
markos | padbank[banknum] = name | 20:43 |
markos | IndexError: list assignment index out of range | 20:43 |
markos | make: *** [Makefile:10: mkpinmux] Error 1 | 20:43 |
markos | (btw, do you use any special pastebin here?) | 20:43 |
octavius | Yeah, this error was fixed. I think the command I gave you is probably missing something | 20:43 |
octavius | Ah, try running it inside src/soc/pinmux | 20:43 |
octavius | The devscript is still pulling an older commit of the repo | 20:44 |
markos | git submodule inside pinmux? | 20:44 |
octavius | That's right | 20:45 |
markos | teh script it does run gmake gitupdate which calls git submodule update --init --recursive --remote | 20:45 |
markos | make not gmake :) | 20:45 |
octavius | Interesting. Did running it manually work though? | 20:46 |
markos | I've never run it before, first time | 20:46 |
markos | after make gitupdate and the command you suggested, I tried to run manually make mkpinmux | 20:47 |
markos | and again the same error | 20:47 |
octavius | Found where we discussed it before: https://libre-soc.org/irclog/%23libre-soc.2021-11-29.log.html | 20:49 |
octavius | * do "git submodule update --init --recursive" | 20:49 |
octavius | If you do a "git log" inside pinmux, can you see the latest commit? | 20:50 |
lxo | FYI, hours ago, today, I updated my browser's User-Agent overrider. now, instead of just changing Linux to GNU, I also change x86_64 to libresoc64 :-) | 20:50 |
octavius | But consider your privacy lxo :P | 20:50 |
lxo | that's a good point, but naming the operating system correctly is enough of a give-away, and not something I'd willingly change back. so I'm encouraging others to also change it (hint, hint ;-) | 20:52 |
octavius | Hehehe | 20:52 |
octavius | Perhaps when I do have a system powerful enough to emulate it, or even a libresoc devboard | 20:53 |
lxo | it's just a user-agent overrider, you don't need actual hardware for that ;-) | 20:54 |
octavius | Ah, so we create a little army of "libresoc64"'s >:) | 20:55 |
markos | 808847daa1773d7636179ea5d49e99b6c7d3a18c | 20:55 |
markos | (inside pinmux) | 20:55 |
octavius | yep, that's latest | 20:55 |
octavius | still breaking? | 20:55 |
markos | I didn't fix anything so yes :) | 20:56 |
octavius | Ok just tried it myself | 20:58 |
octavius | in soc dir: | 20:58 |
octavius | git pull | 20:59 |
octavius | or git pull origin master | 20:59 |
octavius | Then inside pinmux: | 20:59 |
octavius | git pull | 20:59 |
octavius | git pull origin master | 20:59 |
octavius | Now I'm on latest | 20:59 |
octavius | Repeated git pull's because I wasn't sure which one worked XD | 21:00 |
lxo | long story short, one of the banks I use demands lusers to install spyware of the browser identifies as Linux (or Windows, MacOS, etc), but I was told this could be bypassed by setting the OS name in user agent to FreeBSD. I found out GNU also worked ;-) | 21:00 |
markos | octavius, sorry, same result | 21:00 |
markos | latest git commits | 21:01 |
markos | it has an untracked directory ngi_router inside pinmux | 21:01 |
markos | make it's related? | 21:01 |
markos | s/make/maybe | 21:02 |
octavius | Damn, I'm not sure what it is. I know this error was fixed at some point, but I'm getting it as well when I try to build ngi_router | 21:04 |
octavius | the ngi_router directory is a result of this: | 21:05 |
octavius | python3 src/pinmux_generator.py -v -o ngi_router -s ngi_router | 21:05 |
octavius | It is created when given the peripheral spec (what's connected and where to the chip pad | 21:06 |
programmerjake | I'd expect the actual default user agent for firefox on libre-soc's hardware to be similar to "Mozilla/5.0 (X11; Linux ppc64le; rv:84.0) Gecko/20100101 Firefox/84.0" | 21:06 |
lxo | *nod* | 21:07 |
lkcl | markos, comment that out for now (ngi_router) | 22:25 |
lkcl | we updated pinmux recently as you can probably tell | 22:26 |
lkcl | and/or ignore it | 22:29 |
lkcl | pinmux outputs has nothing to do with the simulator | 22:30 |
lkcl | or | 22:30 |
lkcl | go back to this commit: | 22:30 |
lkcl | d96f737c0a53dde983060522 | 22:31 |
lkcl | in the pinmux subdirectory | 22:31 |
lkcl | or | 22:32 |
lkcl | git pull in soc | 22:32 |
lkcl | then cd pinmux | 22:34 |
lkcl | git checkout d96f737c0a53dde983 | 22:34 |
markos | ok, that worked | 22:54 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!