| sadoon[m] | Hi | 01:53 |
|---|---|---|
| sadoon[m] | Oh thank God, new account and I fiddled for hours just to get my rooms back | 01:54 |
| sadoon[m] | How's everyone | 01:54 |
| programmerjake | hi | 01:54 |
| *** sadoon_albader[4 <sadoon_albader[4!~sadoonhal@2001:470:69fc:105::1:efee> has left #libre-soc | 02:01 | |
| Veera[m] | lkcl: Hi. I tried doing python3 setup.py develop for prjxray installation, but fails with python fasm not installed. I mean at first installation run it fails to install, but subsequent invocation it succeeds. I tried installing fasm using pip3 it works. Do you mind if I do this way? | 06:20 |
| programmerjake | a lot of python projects aren't intended to be used with `setup.py develop`, so `pip install .` should be fine imho | 06:22 |
| Veera[m] | It is that lkcl always says setup.py develop first somehow he hates pip3 | 06:27 |
| Veera[m] | pip3 is uninstallable. but setup.py install is not | 06:28 |
| Veera[m] | The first script I developed used pip3. But when lkcl ran he changed it to setup.py develop | 06:28 |
| programmerjake | setup.py develop has the advantage (just like `pip install -e .`) of linking your files into python's installed packages rather than copying your files, allowing you to modify your files without needing to reinstall after every modification | 06:35 |
| programmerjake | afaict setup.py and pip will install the exact same dependencies, so that part of why luke doesn't like pip (poor security practices when downloading packages) isn't any better with setup.py | 06:37 |
| programmerjake | so, other than poor security practices when downloading packages, maybe the rest of why he dislikes pip is familiarity and personal preference? idk ... security is all i remember him mentioning | 06:40 |
| Veera[m] | But also with pip installed packages version changes. Though we can specify exactly which version we need. | 06:44 |
| Veera[m] | It needs more command work | 06:45 |
| Veera[m] | Any idea, usually when he responds to irc | 06:45 |
| programmerjake | hmm, he'll probably respond when he wakes up, in 2-5hr | 07:02 |
| lkcl | setup.py ends up unfortunately calling pip3 which is extremely bad security practice given that pypi.org is a central point of failure, a high-value hacking target, and there's absolutely no GPG-signing of packages. | 11:17 |
| lkcl | multiple levels of compromise | 11:18 |
| lkcl | Veera[m] i don't "hate" it - that's assigning an irrational emotion to a logical analysis of security risk. | 11:19 |
| lkcl | then there is also the fact that arbitrary and random versions of software get installed, without consent. | 11:19 |
| lkcl | that _is_ particularly irritating | 11:19 |
| lkcl | Veera[m], if you've got a solution that "gets the job done", then go for it, as long as it's documented why it's being done | 11:20 |
| lkcl | sadoon[m], yeah good | 11:20 |
| lkcl | what's with the new account? | 11:31 |
| lkcl | Veera: once you're in to cerberus, just "ssh silicon". | 11:43 |
| lkcl | i've added you to sudoers with no password needed | 11:44 |
| lkcl | and i've set up an /etc/udev/rules.d entry to make the ft232 uart on the arty permissions 0666 | 11:45 |
| lkcl | there's an existing schroot nextpnr-xilinx, if you can leave that there (it works, so doesn't need breaking :) | 11:46 |
| Veera[m] | lkcl: I can login to silicon, but could not find any further what to do. So schroot will work. I will try! | 11:56 |
| Veera[m] | so how to load the final bitstream to arty? | 11:57 |
| Veera[m] | Do we have to scp the bitstream to server and using loader program the uart? | 11:58 |
| lkcl | "xc3sprog -c nexys4 top.bit" is the command that's already encoded into nmigen | 12:08 |
| lkcl | you can see that iin.... 1 sec... | 12:08 |
| lkcl | where the heck is it... | 12:10 |
| lkcl | ah _ha_ https://gitlab.com/nmigen/nmigen-boards/-/blob/master/nmigen_boards/arty_a7.py#L217 | 12:10 |
| lkcl | pull up 2 ssh terminals and run "minicom -D /dev/ttyUSB1" in one of them | 12:11 |
| lkcl | then in the other, schroot -c nextpnr-xilinx | 12:11 |
| lkcl | sorry | 12:11 |
| lkcl | sudo bash | 12:11 |
| lkcl | su - coriolis2 | 12:11 |
| lkcl | *then* schroot | 12:11 |
| lkcl | cd src | 12:12 |
| lkcl | cd ls2 | 12:12 |
| lkcl | cd build | 12:12 |
| lkcl | then run that xc3sprog command | 12:13 |
| lkcl | back on the 2nd ssh terminal running minicom you should see the microwatt hello | 12:14 |
| lkcl | btw if "pip3 install ." *and then* "python3 setup.py develop" does the trick, then pffh, great, don't worry about it. | 12:17 |
| Veera[m] | Ok. I will give a try. | 12:38 |
| lkcl | remember i modified nmigen to match the locations /usr/local/nextpnr-xilinx/etc.etc so you don't need to adjust the script for that | 12:40 |
| Veera[m] | ok | 12:41 |
| lkcl | oleee! QuadSPI also works on Arty A7! | 12:46 |
| Veera[m] | yey. hyperram left? | 12:50 |
| lkcl | done already! | 12:53 |
| lkcl | so it's now down to flashing the microwatt-5.7 linux kernel / initramfs into the right place, and writing some coldboot firmware to start running | 12:59 |
| lkcl | i.e. copy from QSPI into HyperRAM then jump to it | 13:00 |
| lkcl | programmerjake, i can't recall exactly where you mentioned about bext / bdep, but they're in v3.1 (p106) as Scalar ops | 13:15 |
| lkcl | or were you referring to bit-to-byte-permute? | 13:15 |
| lkcl | annoyingly i didn't note the VSX instruction which implements it, i only snapshotted the pseudocode. sigh | 13:32 |
| sadoon[m] | <lkcl> "what's with the new account?" <- I didn't like how matrix.org was abusing their power as the default homeserver to ban people from other legitimate homeservers from joining rooms hosted on their network. Very scummy move. | 15:46 |
| sadoon[m] | Found a seemingly good one that's also not banned from joining matrix.org rooms :) | 15:47 |
| sadoon[m] | And doesn't seem to be active politically in either which direction | 15:47 |
| programmerjake | lkcl: i was just relying on what https://libre-soc.org/openpower/sv/bimanip/ says: | 16:01 |
| programmerjake | > vpdepd VRT,VRA,VRB, identical to RV bitmamip bdep, found already in v3.1 p106 | 16:01 |
| programmerjake | https://libre-soc.org/openpower/sv/bitmanip/ | 16:01 |
| programmerjake | it seemed to imply that vpdepd is the only OpenPower bdep instruction | 16:03 |
| programmerjake | so, if that's not the case, it needs to be rephrased since it's confusing | 16:03 |
| tplaten | The hello_world program reaches main and console_init, then it gets to putchar | 17:57 |
| tplaten | Microwatt has two types of uarts: a standard one and a potato one | 17:58 |
| lkcl | tplaten, yes, SYSCON determines which one it is | 18:04 |
| lkcl | SYSCON is just "some registers addressable through wishbone" | 18:05 |
| lkcl | which have SYStem CONfiguration information such as | 18:05 |
| lkcl | "do i have a UART0? if so what type?" | 18:05 |
| lkcl | "do i have BRAM?" | 18:05 |
| lkcl | "do i have SPI Flash?" | 18:05 |
| lkcl | "what is my SYS_CLK frequency?" | 18:05 |
| lkcl | https://github.com/antonblanchard/microwatt/blob/master/syscon.vhdl | 18:06 |
| lkcl | look in include/microwatt_soc.h and search for SYSCON to match up | 18:07 |
| lkcl | also, use this command to get the raw assembler | 18:08 |
| lkcl | powerpc64le-linux-gnu-objdump -D coldboot.elf > coldboot.as | 18:08 |
| lkcl | then you can check the PC and INSN from the GTKWAVE trace against actual assembler listings | 18:08 |
| lkcl | programmerjake, got it, yes, should be pdepd and pextd not vpdepd | 18:09 |
| lkcl | sorted | 18:09 |
| tplaten | I'll have a look at syscon.vhdl | 18:14 |
| ghostmansd | Hi folks, how are you? | 19:12 |
| ghostmansd | Long time no see | 19:12 |
| ghostmansd | I _hope_ in the nearest time I'd be able to finally dedicate some time to binutils | 19:13 |
| ghostmansd | In fact, I've started checking where I had stopped before, and, truth to be told, it takes time to recall what I did :-) | 19:13 |
| lkcl | ghostmansd, hey good to see you're back | 19:21 |
| lkcl | yyeah that's electrical-vs-chemical memory / neurochemistry | 19:22 |
| lkcl | overnight transfer. tomorrow you'll be fine :) | 19:22 |
| ghostmansd | I'm kinda stuck at fields processing for now, e.g. mapping `5.v, 2.v, 1.v` part from `sv.add./m=r3 5.v, 2.v, 1.v` to RT, RA, RB | 19:27 |
| ghostmansd | At openpower-isa/src/openpower/decoder/power_svp64.py, `opregfields = zip(fields, v30b_regs) # err that was easy`... | 19:29 |
| ghostmansd | The comment states that was easy, but, considering how fields are constructed above, that was _not_ :-D | 19:29 |
| lkcl | :) | 19:33 |
| lkcl | ok 1 sec let me bring up the python stuff.. | 19:33 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=65aa1768fc2cff1a615bbd27c33babdb1a96099b;hb=de70844521d6b6e88e380c729f8384971803454d#l479 | 19:34 |
| ghostmansd | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=65aa1768fc2cff1a615bbd27c33babdb1a96099b;hb=de70844521d6b6e88e380c729f8384971803454d#l421 | 19:35 |
| ghostmansd | That's the line I've been talking about | 19:35 |
| ghostmansd | A lot precedes this "that was easy" | 19:35 |
| lkcl | yes. sorry, was just looking to see if there's an option in gitweb to shorten URLs | 19:37 |
| ghostmansd | At our svp64 branch in binutils (git://sourceware.org/git/binutils-gdb.git), we already have opcodes/ppc-svp64-opc.c which contains SVP64 records | 19:37 |
| lkcl | so the first thing to note is, the format for EXTRA2 and the format for EXTRA3 is slightly different. | 19:38 |
| lkcl | EXTRA2 is 2-bits, one of them is "is this scalar, or is it vector" | 19:38 |
| lkcl | so when "scalar", the reg number (0-127) is split up: | 19:40 |
| lkcl | bits[0..4] ==> directly into the 32-bit field RT/RA/RB | 19:40 |
| lkcl | bit 5 ==> directly into the SECOND bit of EXTRA2 | 19:40 |
| lkcl | notice that that's only 6 bits? and that the reg numbers are supposed to be 7? | 19:41 |
| ghostmansd | You mean sv_etype field at binutils:opcodes/ppc-svp64-opc.c, right? | 19:41 |
| lkcl | send me the link so i can see it | 19:41 |
| lkcl | 1 sec i can find it | 19:41 |
| ghostmansd | 1sec | 19:42 |
| ghostmansd | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=opcodes/ppc-svp64-opc.c;h=89c5ae29b349453dcf5f5d2655ec672ec0067642;hb=refs/heads/svp64#l21 | 19:43 |
| lkcl | yes, sv_etype. that's an EXTRA3 example which is 3-bit | 19:43 |
| lkcl | line 3171 (fdmadds) is EXTRA2 (2-bit) | 19:43 |
| ghostmansd | Aha, OK | 19:44 |
| lkcl | so let's stick with EXTRA2 for now | 19:44 |
| ghostmansd | OK | 19:44 |
| ghostmansd | Let's take some example, e.g. `sv.add./m=r3 5.v, 2.v, 1.v` | 19:44 |
| lkcl | so if you have a ".s" then you take the 1st 5 bits and shove them into the v3.0 scalar | 19:44 |
| lkcl | ok | 19:44 |
| ghostmansd | I see we have 3 fields here, right? | 19:45 |
| lkcl | right, that's ".v" and it's line 42 of ppc-svp64.opc.c which is an EXTRA3 | 19:45 |
| ghostmansd | We split mnemonics by whitespace and then take everything but the first part (except of opcode) | 19:46 |
| lkcl | so 5 == 0b0000101 | 19:46 |
| ghostmansd | Then, we get three fields | 19:46 |
| lkcl | yep. 3 fields, they can be identified as RT, RA, and RB. | 19:46 |
| ghostmansd | Nono, let's go before `.v` and bits | 19:46 |
| lkcl | ah ok sure | 19:46 |
| ghostmansd | First question: RT, RA and RB, where do they come from? | 19:46 |
| lkcl | from the specification | 19:47 |
| ghostmansd | That's out/in1/in2/in3 in https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=opcodes/ppc-svp64-opc.c;h=89c5ae29b349453dcf5f5d2655ec672ec0067642;hb=refs/heads/svp64#l55? | 19:47 |
| lkcl | yes. | 19:47 |
| ghostmansd | Aha, OK, now it becomes clearer | 19:47 |
| lkcl | take a look at this: https://github.com/antonblanchard/microwatt/blob/master/decode1.vhdl#L199 | 19:48 |
| ghostmansd | So we basically clean the string, split by whitespaces, drop colons, then map to out/inX fields? | 19:48 |
| lkcl | that's microwatt's decoder and it's where the names in1, in2, in3 and out come from | 19:48 |
| lkcl | i then turned decode1.vhdl into CSV files, and kept the names (as CSV column names) | 19:49 |
| ghostmansd | OK, so out/in1/in2/in3 fields mapped to chunks in the input | 19:50 |
| lkcl | now, the tricky bit is: the SVP64 prefix alone is *not* enough information to determine the SVP64 field encoding | 19:50 |
| ghostmansd | What happens at https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=65aa1768fc2cff1a615bbd27c33babdb1a96099b;hb=de70844521d6b6e88e380c729f8384971803454d#l355? | 19:50 |
| lkcl | i had to spend about a week "classifying" every single one of the instructions | 19:50 |
| lkcl | forget that for now. it was an experiment in breaking the rules, and it caused every single nightmare i had set the rules to avoid happening :) | 19:51 |
| lkcl | i need to rip out ldst_shift. | 19:52 |
| ghostmansd | :-D | 19:52 |
| lkcl | back to the "classifying". this is what sv_analysis.py does. basically i grouped everything by "register profile" | 19:52 |
| lkcl | because there are only... what... 9 bits (i think) in the EXTRA field, but some instructions have 4 registers, some have 3, some 2, and some only 1 | 19:53 |
| lkcl | so if you want to put a separate SVP64 "register extension" on all 4 registers of e.g. fmadds RT, RA, RC, RB, you have only 2 bits per register | 19:54 |
| lkcl | hence, EXTRA2. | 19:54 |
| lkcl | but | 19:54 |
| lkcl | if you have add RT, RA, RB, then that's 3 registers (in1, in2, out) | 19:54 |
| lkcl | and you can do 3 bits each | 19:54 |
| lkcl | hence, EXTRA3 | 19:54 |
| lkcl | BUT | 19:54 |
| lkcl | how do you know which 3 bits of the EXTRA field map to RT, RA, RB, or CR0, or CR1, or whatever? | 19:55 |
| lkcl | that's where the "SVEXTRA_IDX0/1/2/3" comes in | 19:55 |
| lkcl | see how that works? | 19:55 |
| lkcl | back to the add example | 19:56 |
| lkcl | "add RT, RA, RB" which starts at line 32 | 19:56 |
| lkcl | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=opcodes/ppc-svp64-opc.c;h=89c5ae29b349453dcf5f5d2655ec672ec0067642;hb=refs/heads/svp64#l32 | 19:56 |
| lkcl | RA is marked as "in1" but then look at line 43, it says "in1 is in SVEXTRA_IDX1" | 19:57 |
| lkcl | therefore, the 3-bit EXTRA3 information associated with RA goes into EXTRA[3..5] | 19:57 |
| lkcl | RB is marked as "in2" at line 35, but then look at line 44, it says "in2 is SV_EXTRA_IDX2" | 19:58 |
| lkcl | therefore, the 3-bit EXTRA3 information associated with RB goes into EXTRA[6..8] | 19:58 |
| programmerjake | lkcl, i can buy the arty today, can you double-check the email i sent? | 19:58 |
| ghostmansd | lkcl, makes sense | 20:00 |
| lkcl | RT is marked as "out" (line 37), and at line 46, out is marked "SVEXTRA_IDX0" | 20:00 |
| lkcl | therefore, the 3-bit EXTRA information for RT goes into EXTRA[0..2] | 20:00 |
| lkcl | programmerjake, replied. | 20:00 |
| lkcl | BUT, we're still not done! :) | 20:00 |
| ghostmansd | lkcl, the idx/field processing... | 20:01 |
| ghostmansd | is it here? https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=65aa1768fc2cff1a615bbd27c33babdb1a96099b;hb=de70844521d6b6e88e380c729f8384971803454d#l428 | 20:01 |
| lkcl | notice that at line 40, cr_out is marked as "CR0" | 20:01 |
| lkcl | 1 sec... :) | 20:01 |
| programmerjake | also, hi ghostmansd! | 20:01 |
| ghostmansd | hi programmerjake! | 20:01 |
| ghostmansd | long time no see :-) | 20:01 |
| lkcl | and CR0, at line 49, is *also* marked as "SVEXTRA_IDX0". but, for encode purposes, you only need to fill in the EXTRA[0..8] bits once | 20:02 |
| lkcl | right, yes, idx/field processing: yes it is | 20:02 |
| programmerjake | welcome back! | 20:03 |
| lkcl | lines 428-447 are basically the process i just described, the taking of "SVP64_xxxSEL_XX" and combining it with "SVP64_SVEXTRA_IDXyyy" | 20:04 |
| lkcl | so you do this: | 20:04 |
| lkcl | * take the instruction "add. 5.v, 2.v, 1.v" and identify that RT=5.v, RA=2.v and RB=1.v | 20:05 |
| lkcl | * for RT, look up both out and out2 and see if they are "OUTSEL_RT" | 20:05 |
| lkcl | * if so, then look up the corresponding sv_out (or sv_out2) and find the SVP64_SVEXTRA_xxxx index | 20:06 |
| lkcl | now you have the offset where the split 5-bit and 2/3-bit EXTRA must go. | 20:07 |
| lkcl | for EXTRA3, you have *FOUR* locations | 20:07 |
| programmerjake | lkcl, added it to the bug report, should i buy them now or was there something else you wanted to do first? | 20:07 |
| lkcl | IDX0 ==> EXTRA[0..1] | 20:07 |
| lkcl | IDX1 ==> EXTRA[2..3] | 20:07 |
| lkcl | IDX2 ==> EXTRA[4..5] | 20:07 |
| lkcl | IDX3 ==> EXTRA[6..7] | 20:07 |
| lkcl | and you ignore EXTRA[8] entirely | 20:08 |
| lkcl | sorry, that was EXTRA2 | 20:08 |
| lkcl | for EXTRA3 you have *three* locations: | 20:08 |
| lkcl | IDX0 ==> EXTRA[0..2] | 20:08 |
| lkcl | IDX1 ==> EXTRA[3..5] | 20:08 |
| lkcl | IDX2 ==> EXTRA[6..8] | 20:08 |
| lkcl | programmerjake, no should be good. | 20:09 |
| ghostmansd | lkcl, thank you so much! have to check the code more and think about how it works a bit more | 20:10 |
| programmerjake | k | 20:10 |
| ghostmansd | at least now I have an idea where to start from | 20:10 |
| lkcl | where get_extra_gpr() fits in is: there are two different encodings, scalar and vector | 20:10 |
| lkcl | scalar is split, in python, as: | 20:10 |
| lkcl | 5bitfield, extra = regnum[0..5], regnum[5:] | 20:11 |
| lkcl | and vector is split, in python, as: | 20:11 |
| lkcl | extra, 5bitfield = regnum[0:2], regnum[2:] | 20:12 |
| lkcl | but, butbutbut | 20:12 |
| lkcl | for EXTRA2 you have to *truncate* (throw away) some of those bits! | 20:12 |
| lkcl | because you only have 1 bit available! | 20:13 |
| lkcl | one bit of EXTRA2 is "scalar/vector" bit, and that leaves only 1 spare bit | 20:13 |
| lkcl | for EXTRA3 there is still 1 bit for "scalar/vector" but there are *two* bits for storing the "extra" regnum-extension-info | 20:13 |
| lkcl | that's where these asserts come in: | 20:14 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=65aa1768fc2cff1a615bbd27c33babdb1a96099b;hb=de70844521d6b6e88e380c729f8384971803454d#l485 | 20:14 |
| lkcl | for EXTRA2, the scalar range is only 0..63 because there's only 1 bit | 20:15 |
| lkcl | and the vector range is r0 r2 r4 r6 .... r126 | 20:15 |
| lkcl | (the comment is wrong, it's increments of 2 not 4) | 20:15 |
| lkcl | basically the entire thing is a massive bodge :) | 20:20 |
| lkcl | meeting 7min | 21:53 |
| lkcl | toshywoshy, cesar lxo programmerjake markos ^ | 21:53 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!