--- Log opened Sun May 11 00:00:43 2014 | ||
blueCmd | stekern: ah, cool - thanks. didn't think of using xor for a negate like that | 06:17 |
---|---|---|
stekern | I use it all the time to calculate two's complement in speedcrunch ;) | 08:12 |
stekern | xor(12345;0xffffffff)+1 | 08:12 |
blueCmd | I feel I'm probably missing a lot of stuff in my define_insns - they are much smaller and easier to read than the other arches | 08:32 |
blueCmd | which tend to mean it will explode when -O is used | 08:32 |
rfajardo | Hello everyone, I am trying to run a compiled Linux under or1ksim. When bringing the loopback device up, I get a flood of “Warning: Ethernet packet length 0 too small.”. Any ideas why? | 08:35 |
blueCmd | which Linux are you using? (as in, where did you get it?) | 08:36 |
rfajardo | git clone git://git.openrisc.net/jonas/linux | 08:39 |
rfajardo | Maybe I need something in my rxfiles and txfiles… not sure. I should grab some Embecosm’s application notes. | 08:46 |
blueCmd | right, that should work | 08:46 |
blueCmd | looback device = lo right? | 08:46 |
blueCmd | for lo you shouldn't need tx and rx, it doesn't leave the kernel | 08:47 |
rfajardo | sounds reasonable. | 08:52 |
rfajardo | Embecosm’s EAN2 says that or1ksim does not play well with Linux’s Ethernet . | 08:52 |
blueCmd | or1ksim works just fine | 08:53 |
rfajardo | I must certainly say that I’m on OS X :P | 08:53 |
blueCmd | as long as you use jonas's repository | 08:53 |
blueCmd | what gcc are you using? | 08:53 |
rfajardo | stable linux | 08:54 |
rfajardo | gcc version 4.5.1-or32-1.0rc4 (OpenRISC 32-bit toolchain for or32-linux (built 20140421)) | 08:54 |
blueCmd | that's quite ancient, don't know if it matters though | 08:54 |
blueCmd | 4.9.0 is the latest we have I think | 08:55 |
rfajardo | I have heard that you cannot compile Linux with the current toolchain. | 08:55 |
blueCmd | hm? should work just fine | 08:55 |
blueCmd | where did you hear this? | 08:55 |
rfajardo | I have indeed compiled the development version and failed to compile Linux. This occurs because the current toolchain requires libintl to be linked into it and Linux does not like it. | 08:55 |
rfajardo | stekern | 08:56 |
rfajardo | http://pastebin.com/zz8TTMi3 | 08:56 |
rfajardo | my explanation above is wrong though. | 08:57 |
rfajardo | “The reason why it's not working with the or1k-linux-* toolchains is that it builds libgcc.a with -fPIC (and it has to do that)” | 08:58 |
blueCmd | rfajardo: pretty sure that was fixed in https://github.com/openrisc/or1k-gcc/commit/bdd3ad496930c61218ea683b9fd3dbcc093b9a14 though | 08:58 |
stekern | rfajardo: yes, we just fixed that | 08:59 |
stekern | but it's unrelated to your problem with the loopback device, I don't think I've ever seen that | 09:00 |
rfajardo | I should just give up this darn osx. | 09:03 |
rfajardo | But since you go further and further, you end up thinking you’re just about to arrive :). | 09:04 |
blueCmd | stekern: I'm thinking gcc alignment | 09:04 |
blueCmd | that was changed, I don't know if he has anything in his system that might have been built with the alignment/padding removed | 09:05 |
rfajardo | Nice that you fixed that :). | 09:05 |
rfajardo | blueCmd, do you think I should try with the development version of GCC? | 09:09 |
rfajardo | And is gcc alignment? | 09:09 |
stekern | blueCmd: ok, let's start over from scratch on the Linux "SMPing", this is the first commit towards that: http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp&id=ae421650e81dabc4f9cddb3f705f81acf2f19c10 | 09:14 |
stekern | we'll need to properly bring up the "spr scratch" reg though | 09:16 |
stekern | I'm thinking maybe if we define that it could be possible to implement another GPR set without having the whole "fast context" thing... | 09:17 |
blueCmd | rfajardo: yes, please try with the latest shiniest | 09:18 |
stekern | *"spr scratch" reg discussion | 09:18 |
blueCmd | stekern: looks fair | 09:19 |
stekern | the ifdefs didn't become as hideous as I had imagined neither | 09:20 |
stekern | ...but only because I extended the SPR_ISRs from 2 to 8... | 09:21 |
rfajardo | thanks blueCmd, I will try it soon enough | 09:23 |
rfajardo | gotta run now. Take care folks. See you soon. | 09:23 |
blueCmd | logging off from IRC? what is this, the 1980s? | 09:24 |
blueCmd | :) | 09:24 |
juliusb | how do I respond in-line to a comment on the github: https://github.com/openrisc/or1k-src/pull/7 | 09:32 |
juliusb | I want to respond to the comment about the "patching" | 09:32 |
juliusb | My guess is that there was a test for the presence of a peripheral at some point by inserting a jump instruction in the bus exception vector so that when the access occurred, the exception was redirected to a function which indicated it wasn't there, and then cleaned up and continued with that knowledge | 09:37 |
juliusb | I vaguely remember either writing or working with something like that | 09:38 |
juliusb | and hence the comment about disabling the cache or something, at that point, so that writing the new instruction would work | 09:38 |
juliusb | Anyway, I wanted to write ^^^^ on the github page but can't figure out how to respond inline like stekern did :-/ | 09:38 |
stekern | juliusb: you put your mouse over the line you want to comment, and then on the left side there's a "talk bubble" with a plus sign in it, press that | 09:53 |
juliusb | ahh, too easy, thanks. I was looking for the comment button on the main page there | 09:59 |
blueCmd | stekern: if you have time, could you please test http://openrisc.debian.net/tmp/atomic-compare-exchange-1 (there are a couple of files named atomic-compare-exchange in that directory), run them and report exit codes? | 10:10 |
blueCmd | I had a set back in my development environment so I need to set up a new NFS and or1ksim host, which I don't have time to do just now | 10:10 |
stekern | blueCmd: sure | 10:13 |
stekern | root@or1k-debian:~# ./atomic-compare-exchange-1 | 10:14 |
stekern | Aborted | 10:14 |
stekern | ah, sorry "directory"... | 10:15 |
stekern | it downloads a file when I open that link | 10:15 |
blueCmd | yes | 10:16 |
blueCmd | it's a file | 10:16 |
stekern | ok... you m | 10:16 |
stekern | eant in the /tmp dir | 10:17 |
blueCmd | yes | 10:17 |
blueCmd | sorry if I was unclear | 10:17 |
stekern | when you spoke about directory | 10:17 |
blueCmd | try -3 | 10:17 |
stekern | root@or1k-debian:~# ./atomic-compare-exchange-3 | 10:18 |
stekern | Aborted | 10:18 |
blueCmd | ah I see. it's going to abort anyway, I don't care about the memory model and it does some stupid things and expect failures | 10:18 |
blueCmd | stekern: I updated -1 with traces | 10:22 |
blueCmd | also updated -3 with traces | 10:25 |
stekern | root@or1k-debian:~# ./atomic-compare-exchange-1\ \(2\) | 10:26 |
stekern | 23 | 10:26 |
stekern | 26 | 10:26 |
stekern | 30 | 10:26 |
stekern | Aborted | 10:26 |
blueCmd | oh, nice! | 10:26 |
blueCmd | try again plz! | 10:29 |
stekern | same | 10:39 |
blueCmd | really? hm | 10:39 |
blueCmd | for both -1 and -3? | 10:39 |
stekern | (wget is confirmed to work now) | 10:39 |
stekern | root@or1k-debian:~# ./atomic-compare-exchange-3 | 10:40 |
stekern | 22 | 10:40 |
stekern | 25 | 10:40 |
stekern | 29 | 10:40 |
stekern | Aborted | 10:40 |
blueCmd | stekern: mind redownloading them? | 10:45 |
blueCmd | I haven't changed anything since last time, but rebuilt them and rebuilt gcc | 10:45 |
stekern | no problem, but the result is the same | 10:52 |
blueCmd | hm. the test that is failing is in that case: | 10:52 |
blueCmd | first this one is successfully executed: __atomic_compare_exchange_n (&v, &expected, max, STRONG , __ATOMIC_RELAXED, __ATOMIC_RELAXED) | 10:53 |
blueCmd | this is then what follows: __atomic_compare_exchange_n (&v, &expected, 0, STRONG , __ATOMIC_ACQUIRE, __ATOMIC_RELAXED) | 10:53 |
blueCmd | hm. the test says that the later should fail | 10:55 |
blueCmd | expected contains the old valud of v, i.e. 0 | 10:57 |
blueCmd | that it prints 30 confirms that expected is 0 | 10:57 |
blueCmd | v is then max = ~0 | 10:57 |
blueCmd | that means that cas(v, 0, 0) should fail since v != 0 | 10:58 |
blueCmd | but it doesn't fail | 10:58 |
blueCmd | stekern: you should give me shell access to the thing you're testing on ;) | 11:01 |
stekern | I'll try running it in or1ksim too, this is on real hw | 11:04 |
stekern | fix login-as-normal-user and I will ;) | 11:04 |
blueCmd | l.sfeq r4,r4 # cmpxchg: cmp | 11:04 |
blueCmd | I think that has something to do with it :P | 11:05 |
stekern | I suppose that's not intended ;) | 11:06 |
blueCmd | hah, no | 11:06 |
blueCmd | oh well, "the latency is too damn high" to code on this bus anymore | 11:14 |
blueCmd | good progress though | 11:14 |
stekern | is it a short bus? | 11:18 |
blueCmd | stekern: haha | 11:20 |
blueCmd | stekern: there! try again :) | 13:10 |
blueCmd | I only recompiled -1 and -3 | 13:12 |
stekern | blueCmd: sure, will do. right when I'm back home | 13:37 |
blueCmd | stekern: I configured or1ksim and running it with static binaries and embedded initramfs | 14:11 |
blueCmd | for me -1 runs to "40" | 14:11 |
blueCmd | -3 runs to 104 | 14:11 |
juliusb | does a fusesoc usage guide exist anywhere? | 15:23 |
juliusb | doc/ in the sorce? | 15:23 |
olofk | juliusb: Not really. We got Andrew Back's article, the orconf2013 workshop stuff and _franck_'s blog post | 15:24 |
olofk | doc just contains the format specification of the .core and .system files | 15:24 |
juliusb | cool, OK. I'm looking at it for chiphack in a couple of weeks, so I'll try to do what I can | 15:24 |
juliusb | where would be the preferred location/format for a usage guide? | 15:24 |
olofk | Good question | 15:24 |
olofk | In fusesoc/doc I guess. I'm not that picky about formats, so markdown, asciidoc, latex is fine | 15:25 |
olofk | Or Microsoft Works | 15:26 |
olofk | Best not-compatible-with-anything-not-even-with-itself office suite I have ever used | 15:26 |
juliusb | I'll do my best ;) | 15:27 |
olofk | And I must say that starting work on a user guide is awesome. Please pester me with questions if I can help out | 15:28 |
juliusb | Oh yeah, you didn't need to ask me to do that ;) | 15:28 |
olofk | I suspected as much :) | 15:28 |
juliusb | I've already modified the INSTALL file. It wasn't obvious that I had to do the autoreconf ./configure etc. stuff if I was going to use it in developer mode (not install it ) | 15:29 |
juliusb | but I'm too stupid to remember how to work with git to submit it :-/ | 15:30 |
olofk | Hmm.. do you really need to do that? | 15:30 |
juliusb | I'll figure it out | 15:30 |
juliusb | yeah fresh out of git there was no fusesoc file | 15:30 |
olofk | I'm using "python /path/to/fusesoc.in" | 15:30 |
juliusb | just fusesoc.in and it refused to run | 15:30 |
juliusb | ah right | 15:30 |
olofk | Ah yes. You can't run it because of the unexpanded env stuff | 15:31 |
juliusb | I did autoreconf -i, ./configure && make, then I could export PATH=$PATH:/path/to/fusesoc/bin | 15:31 |
olofk | Cool. Yeah that works too | 15:31 |
olofk | You could use the tar ball as well. There aren't that many commits since I released it | 15:32 |
juliusb | Ya, true. It is "./configure && make"'d in the tarball? | 15:32 |
olofk | yesp | 15:32 |
olofk | yes | 15:32 |
juliusb | kk, i'll make a note | 15:32 |
olofk | I've been thinking about making a .deb for the released versions | 15:34 |
olofk | Apart from the EDA tools, I think that python and SVN would be the only deps | 15:34 |
juliusb | and git? | 15:35 |
olofk | Actually no | 15:35 |
juliusb | oh wow | 15:36 |
olofk | You can just ask github to give you a tarball for any state of the tree, so I figured that would be more lightweight and could drop the git dep | 15:36 |
juliusb | Ah cool, handy. | 15:37 |
juliusb | so I go and run the wb_bfm test. All good. how come it prints out nothing but a success message? I want the gory details man. | 15:37 |
juliusb | ... and there's no indication of such an option in fusesoc sim --help | 15:37 |
olofk | Yes. That's pretty fucked up since it takes some time to run it | 15:38 |
olofk | There's no fucking clue that it's doing anything | 15:38 |
olofk | Run the wb_ram tb instead. It's at least a bit more fun to watch | 15:39 |
juliusb | another Q - is it possible to compile the doc .txt files? They look like asciidoc or something | 15:40 |
olofk | No, run wb_intercon test bench instead. That one gives a bit more output | 15:40 |
olofk | Yes. It's asciidoc | 15:41 |
olofk | html is the default output. You should be able to generate a PDF as well via docbook or something, but I haven't tried that | 15:41 |
olofk | As usual it probably takes the route via latex | 15:41 |
juliusb | do the scripts know how to make it though? | 15:42 |
olofk | Which scripts? | 15:42 |
juliusb | the make flow which is in there | 15:42 |
olofk | The fusesoc make flow? | 15:43 |
juliusb | ya, like I can't go "make doc" to make it compile the documentation it seems | 15:43 |
olofk | ah no. Sorry. Hadn't thought of that actually | 15:43 |
juliusb | want me to lodge a feature request? | 15:43 |
olofk | Please do. That's probably the way we want it | 15:43 |
juliusb | i like github. That's such a nice, simple, integrated way to track this sort of stuff | 15:46 |
olofk | Yeah. They have a lot of nice extra features | 15:47 |
olofk | I like the markdown integration. I've started dropping README.md files in the cores for quick documentation | 15:47 |
veprbl | Do we really need this autoconfig magic in fusesoc? | 15:51 |
veprbl | Is it really working? I think there is no point in remembering all these python paths because libpython still has to be found somehow... | 15:51 |
veprbl | For example I'm using RHEL based distro with python2.7 from scl repos (installed in /opt) | 15:53 |
olofk | All right then. My blog has been updated http://olofkindgren.blogspot.se/2014/05/openrisc-health-report-april-2014.html | 15:53 |
veprbl | I do ./configure and it's all warm and fuzzy | 15:53 |
veprbl | #!/usr/bin/env /opt/rh/python27/root/usr/bin/python | 15:53 |
veprbl | sys.path[0:0] = ['/usr/local/lib/python2.7/site-packages'] | 15:53 |
veprbl | but once I disable scl environment it just goes | 15:54 |
veprbl | % /opt/rh/python27/root/usr/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory | 15:54 |
veprbl | olofk: And I've never seen anything like that in any python program. Did you invent all that by yourself? | 15:55 |
stekern | blueCmd: 104 and 40 here too | 15:58 |
_franck_ | veprbl: FWIW I use a RHEL based distro. When I use fusesoc, I install python2.7 in /bla/bla then "export PYTHON=/bla/bla/python2.7" then ./configure | 15:59 |
veprbl | If it's all pure python, I would imagine that it will be managed by setuptools/distutils/pip | 16:00 |
veprbl | _franck_: yes, I understand that. SCL is a fancy way to do the same. but if you take away that env var it will break and ./configure magic probably was made for this | 16:03 |
juliusb | is there any way to expose what fusesoc is doing to the terminal? like the exact commands its running? | 16:04 |
juliusb | also, is there only one testbench per core it can run? is it possible to run the core sim but with a different test? | 16:04 |
veprbl | juliusb: maybe some echo in Launcher@fusesoc/utils.py will help | 16:07 |
olofk | veprbl: I thought that was the standard way of doing it actually. I looked through a couple of autoconf powered python projects | 16:11 |
olofk | juliusb: All external commands are wrapped in a launcher in utils.py. Easiest way would be to make the Launcher class put the command in the log | 16:15 |
juliusb | cool yep. I'm hacking some bits and pieces into Launcher's run function | 16:16 |
juliusb | Ah, I love it. Seriously easy FPGA image building :) | 16:24 |
olofk | And currently only one tb is supported. Three solutions come in mind | 16:59 |
olofk | 1) Add a command line option to select alternative tb | 16:59 |
olofk | 2) Create an additional core with only a tb that depnds on the first core | 17:00 |
olofk | 3) Use plusargs to select tb at runtime | 17:00 |
olofk | 3 is of course the coolest option, but will probably need the most hackery in the RTL | 17:00 |
juliusb | well, yeah, it would require you elaborate all testbench RTL, which probably isn't the end of world | 17:02 |
olofk | juliusb: If you want som plusargs inspirations, you can look at the wb_intercon testbench where you can set --transactions=<number of transactions> | 17:02 |
olofk | Yeah, I think it's an ok trade off as well. Just keep the unused stuff in reset and kill the clocks to bring down the number of simulation events | 17:03 |
olofk | veprbl: I originally planned to use setuptools/distutils/pip/pypy/distribute/easy_install... but the problem was exactly that. Packaging in python is a fucking mess. A few lines of autoconf stuff turned out to be way more sane | 17:04 |
olofk | s/pypy/pypi | 17:05 |
veprbl | olofk: could you be more specific: what was the problem that was solved? | 17:07 |
veprbl | I mean we definitely want "make install" or "python setup.py" or "pip install fusesoc", but the part with fusesoc.in is just confusing | 17:19 |
blueCmd | stekern: cool, thanks | 17:33 |
blueCmd | (qemu) I wonder if we can implement ll/sc as simple load/store and always set the flag for l.swa | 17:35 |
stekern | hmm, yeah... at least in usermode | 17:46 |
stekern | but doesn't mips et al implement their counter parts? | 17:46 |
stekern | heh.. http://www.tldp.org/HOWTO/SMP-HOWTO-3.html | 18:26 |
stekern | "MIPS, m68k and ARM does not support SMP; the latter two probly won't ever." | 18:27 |
stekern | blueCmd: are you ready for todays SMP milestone in form of a commit? | 18:50 |
stekern | well, ready or not, here we go: http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp&id=44ba9499db6fdd99e492ca066a423594080183a0 | 18:51 |
stekern | next milestone - fix the torrent of build errors that happens when that is enabled | 18:52 |
stekern | a lot are related to atomics | 18:52 |
olofk | veprbl: This fixes the problem where the fusesoc modules is installed in a path that is not in PYTHONPATH | 19:43 |
olofk | Default make install without setting PREFIX installs fusesoc into /usr/local/ somewhere, and python won't normally look there, so the fusesoc binary can't find the fusesoc module | 19:47 |
olofk | But I'm all for finding a better method. I totally agree that it would be great to get rid of fusesoc.in | 19:47 |
blueCmd | stekern: woha woha woha | 21:46 |
blueCmd | that commit. it changes too much | 21:46 |
blueCmd | and where are the tests? how do I know it works? | 21:46 |
blueCmd | this is not agile / webscale / ms-pl | 21:46 |
blueCmd | stekern: I couldn't find any real "aha, that's how they do it" looking at MIPS - since qemu doesn't support threads anyway I figured that it might work just fine anyway | 21:48 |
--- Log closed Mon May 12 00:00:44 2014 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!