| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 00:00 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 00:01 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 02:58 | |
| *** octavius <octavius!~octavius@92.40.168.89.threembb.co.uk> has joined #libre-soc | 10:03 | |
| *** midnight <midnight!~midnight@user/midnight> has quit IRC | 10:52 | |
| *** midnight <midnight!~midnight@user/midnight> has joined #libre-soc | 10:53 | |
| lkcl | ghostmansd, apologies with media/ i realised that because it uses pysvp64asm i set you on a red herring | 12:43 |
|---|---|---|
| lkcl | you actually do want crypto/ which *does* (thanks to markos) use binutils-sv | 12:44 |
| markos | thanks to ghostmansd actually | 12:56 |
| lkcl | :) | 13:13 |
| lkcl | cesar, you seen this? https://www.bbc.co.uk/news/science-environment-65243132 | 13:39 |
| ghostmansd | lkcl, I will check crypto too | 16:55 |
| ghostmansd | and media should be fixed anyway, we might opt to bind it to another task later, though, if it's OK | 16:56 |
| ghostmansd | On pre-insndb and master branches, we now fail with `ValueError: invalid literal for int() with base 10: '16+3'` | 17:00 |
| ghostmansd | Happens with code like `sv.add/dm=r10 *t, *ip, *ip+3` | 17:00 |
| ghostmansd | lkcl, it seems that I'm able to build the code with `make -C crypto/chacha20/ BINDIR=/tmp` | 17:07 |
| ghostmansd | What should I do next? I have no idea what I should do with these .bin files... | 17:08 |
| markos | ghostmansd, what do you want to test? I could help you | 17:11 |
| ghostmansd | Well, Luke asked me to (quote) "make sure chacha20 works at least" with recent binutils :-) | 17:12 |
| ghostmansd | But I have no idea what "works" mean | 17:13 |
| markos | oh, try running ./test-chacha20 :) | 17:13 |
| markos | it will take a few minutes but in the end it should just report "Cryptographic tests passed" or something similar | 17:13 |
| ghostmansd | Ah, that's why I missed it | 17:13 |
| ghostmansd | It's placed outside of BINDIR | 17:14 |
| markos | try SILENCELOG=1 otherwise it will print the world | 17:14 |
| ghostmansd | `ModuleNotFoundError: No module named 'pypowersim' Error importing module` | 17:14 |
| ghostmansd | sigh, here we go again :-) | 17:14 |
| ghostmansd | I likely have sources outdated by some months | 17:15 |
| markos | argh | 17:15 |
| markos | that's my fault | 17:15 |
| markos | in ../../media/pypowersim_wrapper/pypowersim_wrapper_common.h | 17:15 |
| markos | L43: PyUnicode_FromString("/home/markos/src/openpower-isa/src/openpower/decoder/isa/"); :) | 17:16 |
| ghostmansd | lol | 17:16 |
| markos | I should probably fix the path to be relative one | 17:16 |
| markos | it's just I had a problem with relative paths in the beginning with python so I changed it to absolute, and forgot to fix it afterwards | 17:17 |
| ghostmansd | ~/src/openpower-isa/media/pypowersim_wrapper$ make | 17:18 |
| ghostmansd | /usr/bin/ld: cannot find -lgtest | 17:18 |
| ghostmansd | and I guess I have to use our custom gtest? | 17:18 |
| ghostmansd | or repos will be sufficient? | 17:18 |
| markos | you need to install libgtest-dev | 17:19 |
| ghostmansd | ok, let me re-run dev-env stuff | 17:19 |
| markos | ok | 17:19 |
| ghostmansd | I have everything outdated anyway | 17:19 |
| markos | which version of debian are you running, it needs a "relatively" recent, eg the buster version won't do iirc | 17:20 |
| ghostmansd | buster is exactly the stuff I have :-) | 17:21 |
| ghostmansd | don't we have this pinned in scripts? | 17:21 |
| markos | in general everything else works, I just had to backport libgtest | 17:21 |
| ghostmansd | tbh, our env is so silly that even dokkah looks better... | 17:22 |
| markos | hm, wait, libgtest isn't used by chacha20 | 17:22 |
| markos | this is for the media stuff | 17:22 |
| ghostmansd | it's not for chacha20 | 17:22 |
| ghostmansd | I tried to rebuild pypowersim wrapper | 17:22 |
| markos | ah the example? | 17:22 |
| ghostmansd | after switching from markos to ghostmansd :-) | 17:22 |
| ghostmansd | perhaps, no idea | 17:23 |
| ghostmansd | I simply type `make` whenever I see makefiles, lol | 17:23 |
| markos | yes, that's just a pypowersim example, it's not needed | 17:23 |
| markos | :D | 17:23 |
| markos | for testing the binutils with svp64 it's not needed at all | 17:23 |
| markos | it's only a demo of pypowersim wrapper | 17:23 |
| ghostmansd | sigh | 17:23 |
| ghostmansd | I already removed everything in src... | 17:24 |
| ghostmansd | :-D | 17:24 |
| ghostmansd | anyway, I have to update repos and other stuff at some point eventually | 17:24 |
| ghostmansd | so this is inevitable evil | 17:24 |
| ghostmansd | $ ./install-hdl-apt-reqs | 17:25 |
| ghostmansd | E: Unable to locate package gcc-8-powerpc64le-linux-gnu | 17:25 |
| ghostmansd | f*ck, will we EVER get something which works immediately? | 17:25 |
| ghostmansd | > All Libre-SOC dev dependenices should now be installed | 17:30 |
| ghostmansd | anyway it was able to build it | 17:30 |
| ghostmansd | markos, yet another part | 17:33 |
| ghostmansd | $ ./crypto/chacha20/test-chacha20 | 17:33 |
| ghostmansd | FileNotFoundError: [Errno 2] No such file or directory: '/usr/local/lib/python3.7/dist-packages/openpower/isatables/sprs.csv' | 17:33 |
| markos | that is something else | 17:37 |
| ghostmansd | I see these tables inside openpower-isa | 17:38 |
| markos | you need a working installed environment though | 17:38 |
| ghostmansd | But `sudo python3 setup.py install` doesn't do the trick | 17:38 |
| markos | yeah, you need to run install-hdl-apt-reqs as sudo | 17:39 |
| markos | but I somehow agree, our dev environment is quite fragile at the moment | 17:39 |
| ghostmansd | `dev-env-setup/hdl-dev-repos` was run successfully | 17:40 |
| ghostmansd | hm, perhaps install develop will work... | 17:41 |
| markos | ah right | 17:42 |
| ghostmansd | yeah it works | 17:42 |
| ghostmansd | OK, so `install` IS broken | 17:42 |
| markos | which install exactly? | 17:42 |
| ghostmansd | `python3 setup.py install` | 17:42 |
| ghostmansd | ^ that one is broken | 17:43 |
| ghostmansd | `python3 setup.py develop` | 17:43 |
| ghostmansd | ^ this seems to work | 17:43 |
| markos | according to the readme file, you need to run 'python3 setup.py develop' and 'make generate' | 17:43 |
| ghostmansd | OK I'm able to launch the test, finally | 17:43 |
| markos | great | 17:43 |
| markos | it *should* work | 17:43 |
| ghostmansd | `If "python3 setup.py install" is used it is a pain: edit, then install. edit, then install. It gets extremely tedious, hence why "develop" was created.` | 17:43 |
| ghostmansd | That's the guide from HDL_workflow | 17:44 |
| ghostmansd | but "it is a pain" does not imply "hence we break it" | 17:44 |
| markos | well, as I said, it's a fragile dev environment | 17:44 |
| markos | ideally these packages should be autogenerated and people would just apt install them | 17:44 |
| ghostmansd | I know Luke's opinion about containers... Do we have other options? | 17:44 |
| markos | I share the same opinion about containers, they suck | 17:45 |
| markos | yes, packages | 17:45 |
| ghostmansd | I mean, other than having a bunch of scripts which require anyone to go through this tedious process? | 17:45 |
| markos | auto-generated packages using CI | 17:45 |
| ghostmansd | I don't like containers too | 17:45 |
| markos | with specific milestones for stable releases | 17:45 |
| ghostmansd | But even they are better that something this fragile | 17:45 |
| markos | but daily/nightly builds for everything else | 17:46 |
| markos | and from those it should be possible to even ship ready made VMs for people to use for development | 17:46 |
| markos | right now the list of people working on this is small so we can manage | 17:46 |
| markos | but if/when this list grows, there is no way this is sustainable | 17:47 |
| ghostmansd | Yes, ready VMs would be the best choice, with one giant script with a huge GUI button and text "make stuff work" | 17:47 |
| ghostmansd | (that would almost fit the definition of container) | 17:47 |
| markos | so we *will* have to provide a way of reproducible builds | 17:47 |
| markos | I'm not against the idea of containers, but I absolutely loathe dockers | 17:47 |
| markos | we should invest some time now to make such a system work, rather than later | 17:49 |
| markos | I've had huge flamewars in the past about dockers in a company I worked for, turns out I was right in pretty much every aspect, you name it, security, performance, ease of use, external dependencies, etc, and eventually they got rid of dockers entirely, after I was gone | 17:52 |
| markos | so anytime I hear someone mention dockers as a solution I get winded up | 17:52 |
| ghostmansd | Cryptographic tests passed! | 17:55 |
| markos | \o/ | 17:55 |
| markos | great work, as usual! | 17:56 |
| markos | I don't think I've ever thanked you enough, without your work, all this wouldn't have been possible | 17:56 |
| markos | I know lkcl prefers doing stuff on the simulator, but you can't code projects larger than a unit test there :) | 17:58 |
| ghostmansd | thank you for your kind words! | 18:11 |
| markos | ghostmansd, which media test fails with recent binutils? | 18:28 |
| ghostmansd | markos, `/tmp/out0 data/audio/mp3/mp3_1_data/out0 differ: char 1, line 1` | 18:30 |
| ghostmansd | lkcl said it might be caused by the fact that setvl was updated recently | 18:30 |
| ghostmansd | But it might be wrong; we have never checked binutils assembly for many instructions. It was implemented in dark times when we had old assembler, and, whilst I updated binutils, the assembler has been changing, too. | 18:31 |
| markos | ah mp3 I've completely reworked recently but haven't committed as it's incomplete, but I only worked on mp3_1 | 18:31 |
| ghostmansd | Then I arrived at the scene and rewrote the assembler from scratch... | 18:32 |
| ghostmansd | Meanwhile Luke changed and renamed and removed and added modes and specifiers... | 18:32 |
| ghostmansd | I think it's synced in terms of parsing, but no guarantees it works for all instructions. | 18:32 |
| ghostmansd | That's mostly what https://bugs.libre-soc.org/show_bug.cgi?id=1003 is about. | 18:32 |
| ghostmansd | I want to take at least tests we have in src/openpower/sv/trans/test_pysvp64dis.py... | 18:33 |
| ghostmansd | ...and make sure that binutils generate the same code our assembly does. | 18:33 |
| ghostmansd | Likely this will require massive updates on binutils side, because 1) our assembly is totally different than it was and can no longer be used as source; 2) many parts of binutils assembly can already be generated from Python, and not written by hand. | 18:34 |
| ghostmansd | Or, well, at least we can reuse generated bits at most. | 18:35 |
| ghostmansd | markos, BTW, if you want to be able to check these tests, you'll need media-binutils branch in openpower-isa, otherwise stuff won't run. | 18:35 |
| markos | I'm currently under great time pressure the following couple of weeks so I cannot help testing binutils, but things should be better after that | 18:39 |
| ghostmansd | That's OK, I'll have to do it anyway :-) | 18:41 |
| ghostmansd | I still have a hope that one day this task will be completed | 18:41 |
| ghostmansd | Never surrender! | 18:42 |
| markos | :) | 18:42 |
| *** tplaten <tplaten!~tplaten@195.52.23.60> has joined #libre-soc | 18:42 | |
| tplaten | I'm trying to understand the DQSBUFM.o_BURSTDET signal, which is ECP5 only. | 18:58 |
| tplaten | Litedram also supports other kinds of FPGAs and reads back a test pattern. | 18:59 |
| tplaten | In sdram_write_read_check_test_pattern a first phase is written, then it reads back from a different one. | 18:59 |
| tplaten | In litex-boards/litex_boards/targets/build/orangecrab/software/include/generated/sdram_phy.h I read #define SDRAM_PHY_WRPHASE 1 and #define SDRAM_PHY_RDPHASE 0. | 18:59 |
| ghostmansd | lkcl, I'm not sure about the next task. I'd like to take 1003, since it's the logical continuation of binutils and asm works, but IIRC it's not approved. Also that'd be plethora of work: rewrite portions of binutils with the generated code we have now and check that at least test_pysvp64dis tests work. | 19:22 |
| ghostmansd | On python asm/disasm side, I think we only need to support % convention (i.e. treat %r/%f/etc. the same way binutils do). Another stuff is having our mode selection tables encoded in some text file. Nothing else comes to my mind, to be honest. | 19:23 |
| ghostmansd | For 976, I think it's done in scope mentioned by task, unless there are other things we'd like to handle simultaneously as well. | 19:25 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=1003 the MoU still needs signing, but any work done yes will actually get paid | 19:50 |
| lkcl | oh yes. i'd really like the modes to be a csv file, it means autogeneration of other "stuff" becomes easier as well | 19:51 |
| lkcl | in particular power_svp64_rm.py is... a royal nuisance. | 19:51 |
| lkcl | yes don't ever use "python3 setup.py install", only "python3 setup.py develop". | 19:59 |
| lkcl | i never used install. | 19:59 |
| lkcl | tplaten: very puzzling to write at one phase then read another. unless... ahh, they are different wires. | 20:01 |
| lkcl | so there is the strong possibility that different phase-offsets are genuinely needed for send and receive | 20:01 |
| lkcl | because the *receiver* - the actual DRAM IC (!) might have the exact same kind of phase-lock problem as the ECP5!!! | 20:01 |
| tplaten | Maybe, I'll continue tomorrow. | 20:04 |
| *** tplaten <tplaten!~tplaten@195.52.23.60> has quit IRC | 20:05 | |
| *** octavius <octavius!~octavius@92.40.168.89.threembb.co.uk> has quit IRC | 21:15 | |
| sadoon[m] | No jinxing hopefully, I think I finally got mini-buildd stable enough to start working on sffs, next thing I'm about to do is figure out how to force the compiler flags | 22:10 |
| sadoon[m] | Oh and I'm just noticing acl2 takes even more time to build than firefox which I didn't think was possible | 22:11 |
| sadoon[m] | @lkcl do you think I should build the base debootstrapable packages first or just for the full main repo? | 22:12 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!