IRC logs for #openrisc Saturday, 2014-07-12

--- Log opened Sat Jul 12 00:00:15 2014
stekernah, the reason why pthread_robust fails was at least easy to find out, we don't implement futex_atomic_cmpxchg_inatomic in our kernel port, so set_robust_list doesn't work07:38
blueCmd_one of the big hassles I had with porting glibc is that the testsuite requires you to compile it on the test target09:25
blueCmd_hopefully you don't have that problem stekern09:25
blueCmd_having a good test suite to test against would have made the job so much easier than to compile programs and debug when some random app crashes :P09:26
stekernblueCmd_: well, the testsuite kind of expects you to run it on the target, but it's just driven by a simple Makefile, so it's easy to change that assumption09:56
stekerncurrently, I just use the Makefile to build the files and just a script to run them on the target (since I don't have make in my simple rootfs)09:59
blueCmd_right, I tried to do the same in glibc09:59
blueCmd_was about to kill myself09:59
stekernthe testsuite isn't really musl specific btw, so you should be able to run it against glibc too09:59
blueCmd_stekern: cool, I was hoping that would be the case10:03
blueCmd_stekern: olofk: would you guys be OK with me adding a "type=axi4" and "type=axi4-lite" (default would be "type=wishbone" ofc) to wb_intercon?10:06
stekernsgtm10:10
blueCmd_*sigh* I'd wish olofk would reconsider submodules in orpsoc-cores10:49
stekernI bet he'd be happy to have that added alongside the current options11:15
stekernactually, doesn't it just work if you add a submodule and omit the provider?11:18
stekernyou have to manually update them of course...11:18
blueCmd_stekern: yes, that will work - but it's not a technical question, it's a political one :)11:28
stekernoh, politics... boring! ;)11:54
-!- Netsplit *.net <-> *.split quits: clopez, _franck_, shorne, rah, jungma, jonmasters, knz, javax, jeremy_bennett, dalias, (+4 more, use /NETSPLIT to show all of them)12:06
-!- Netsplit over, joins: trem, _franck_, ssvb_, jeremy_bennett, rah, mboehnert, maxpaln, shorne, jungma, clopez (+4 more)12:07
stekernblueCmd_: btw, would you mind updating your CLONE_SETTLS patch and reposting it?13:03
blueCmd_:)13:03
blueCmd_3:rd times the charm I guess13:03
blueCmd_time's13:03
stekernyour violating the 80 column rule in the comment too, might fix that at the same time13:05
stekerns/your/you're13:05
blueCmd_I am? that's unlike me13:05
blueCmd_which version do you want me to base the patch on?13:06
stekernumm, what do you mean?13:07
blueCmd_also, IIRC you had a patch against this because it didn't work or something like that13:08
blueCmd_very faintly remember something like that13:08
blueCmd_stekern: I base my development against 3.16 currently13:08
blueCmd_jonas's repo is @ 3.13 I think13:08
stekernyes, take what's in my smp branch13:09
stekernand apply that to linus tree or something13:11
stekernas long as it applies cleanly against mainline, your 3.16 tree is probably fine13:12
blueCmd_right,  userregs->gpr[10] = userregs->gpr[7] - that was the issue13:13
stekernyup13:20
blueCmd_stekern: where do I break 80 char?13:21
blueCmd_ah, maybe it's because my tabstop=213:22
blueCmd_stekern: https://github.com/bluecmd/or1k-linux/commit/5407ab8ce13f2c3f85e733c5d6b5cca5fb35f728.patch13:28
blueCmd_I haven't checked if it applies cleanly to your version  though13:29
stekernthat's not important13:29
stekernmore important is to poke Jonas into pushing it forward upstream ;)13:32
blueCmd_done13:38
blueCmd_we also want that signal patch upstream13:38
blueCmd_https://github.com/bluecmd/or1k-linux/commit/e18325ddcae9e9304137176318285e2742de707113:39
stekernyou might want to add a [PATCH v2] to indicate it's updated too13:39
blueCmd_stekern: [PATCH v3]*13:39
blueCmd_I cared the first and the second time :)13:40
blueCmd_verilator does not like wb_intercon.. a lot of width warnings that hurts my eyes13:41
stekernyes, we should remind him about that signal patch too14:01
stekernI thought the width mismatches were all taken care about by now...14:02
blueCmd_http://7f3299788b81b29a.paste.se/14:03
blueCmd_I filed a bug with bmartini for verilog-arbiter14:03
stekernhave to wait until that appears in the log before I can check it14:04
stekernor when I get home, whatever happens first14:05
stekernthe shift thing is at least easy to avoid14:28
stekernblueCmd_: you know there's git send-email, right? :p14:43
blueCmd_stekern: yes, I use that the first two times :)14:44
blueCmd_If I was sure that the 3:rd time will be the last one, I might have put some more effort into it14:44
daliasstekern, re: tests, it would be really nice if nsz's makefile had an easier way to separate building/running the tests14:46
daliasthat's something on the agenda to work on, eventually :-p14:46
stekernblueCmd_: fair enough, I would have found it *less* work to just git send-email it, that's why I asked14:48
blueCmd_stekern: I'm not sure I have SMTP configured on that particular machine14:48
blueCmd_also addressing both malinglists and jonas is much simpler in gmail than doing with send-email14:49
stekerndalias: it's straight forward enough to hack around so it's not a huge deal, but it'd be nice nevertheless14:49
stekernah, I have them as aliases anyway ;)14:50
blueCmd_stekern: you're not promiscious enough14:52
blueCmd_stekern: olofk https://github.com/openrisc/orpsoc-cores/pull/7414:56
blueCmd_stekern: you might want to add your avalon stuff to that as well15:02
blueCmd_or I can do it, if you want it15:03
stekernblueCmd_: ah, cool. be my guest if you feel like it ;)15:42
blueCmd_stekern: almost done :P15:42
blueCmd_stekern: I don't have the tools test your sockit I think, if I send you a patch - could you apply it and see if it makes sense?15:58
blueCmd_or rather, I'll let you update sockit I guess, might be some special things I guess15:59
stekernoh, sure16:01
blueCmd_stekern: if you apply https://github.com/openrisc/orpsoc-cores/pull/74 to your orpsoc-cores and do this: http://1726b3c4499ca129.paste.se/16:03
blueCmd_that should leave you with only some address splicing by looking at your code16:03
blueCmd_olofk: I think you should merge https://github.com/openrisc/orpsoc-cores/pull/26 - it's a good pull request and it's straight forward16:09
stekernI'd change that key1 to button1 before though17:06
stekern(and I think I suggested that when the patch was posted too)17:07
blueCmd_jeremy_bennett: olofk: do you have any way to access revision history for or1k/or32 gcc before 2009?17:17
blueCmd_juliusb committed gcc-4.2.2 to the old SVN repository "Adding binutils, gcc, uClibc patched source and patches" 2009, but I want to know what happened before then17:18
blueCmd_hah, bmartini fixed the warnings in verilog-arbiter17:53
stekernblueCmd_: http://opencores.org/websvn,listing?repname=or1k&path=%2For1k%2Ftrunk%2Fgcc%2Fgcc-3.4.4%2F#path_or1k_trunk_gcc_gcc-3.4.4_17:53
stekernand backwards from that17:53
blueCmd_stekern: I try to shard by asking other people so I don't overwork you17:54
blueCmd_don't make me PM them :P17:54
blueCmd_but thanks :)17:54
stekerndon't worry, my index finger is still strong enough to paste a link ;=17:56
stekern)17:56
blueCmd_stekern: will you hate me if I merge a pull request to gcc?18:12
blueCmd_I think I messed up with the last rebase thing as you told me, it's talking forever for it to do the rebase18:13
blueCmd_maybe I'll just recreate my tree and rebase it from there. yeah, that'll be better18:15
blueCmd_there18:24
stekernumm, what are you trying to do?19:17
stekernmerging is usually the right thing to do, so I wouldn't hate you for that ;)19:17
stekernthat said, if you messed up your tree that you want to merge in, you should probably fix that before you merge it19:18
stekernah, I see now.19:22
stekernI think either way would have been fine19:24
blueCmd_stekern: the reason it was taking forever was 1) that my tree was weird and 2) the loadavg was 500 :)23:51
--- Log closed Sun Jul 13 00:00:17 2014

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!