| --- Log opened Tue Apr 29 00:00:06 2014 | ||
| --- Day changed Tue Apr 29 2014 | ||
| stekern | juliusb: I think october have been a good time, so we should aim for that I think | 03:48 |
|---|---|---|
| stekern | blueCmd: so, was that the complete fix for the TLS stuff? | 03:49 |
| stekern | err, nm | 03:50 |
| stekern | wait until I have got some coffee... | 03:50 |
| stekern | blueCmd: as you say, it seems stable enough and it fixes an issue. and as far as I can see, the patch seems correct. | 05:14 |
| stekern | I don't think nick clifton approved git access for me, but I don't know if we need that, it's probably enough that we channel patches through you | 05:16 |
| olofk_ | juliusb: We talked about having a teleconf, now when it's halfway between orconfs. | 06:07 |
| olofk_ | juliusb: Are you back from behind the iron curtain now, btw? | 06:11 |
| juliusb | olofk_: I am indeed back. a teleconf is a good idea | 07:08 |
| juliusb | stekern: October sounds good | 07:08 |
| wallento | julisb: thanks | 07:09 |
| wallento | regarding ORCONF2014 I think we can host it in Munich next time | 07:09 |
| stekern | wallento: that sounds great | 07:12 |
| wallento | we have to be careful regarding the date due to Oktoberfest, which has two faces: On the one hand one or the other would like to visit it, on the other hand hotels are awfully expensive and sometimes fully booked during this time | 07:13 |
| wallento | its September 20 to October 5 | 07:14 |
| wallento | ORCONF 2013 was October 5 and 6 | 07:14 |
| stekern | yes, I think clashing with Oktoberfest should be avoided | 07:15 |
| juliusb | Sounds like a good idea. As long as there is *some* beer left over in Munich for us, then that'll be fine :) | 07:37 |
| stekern | haha | 07:39 |
| stekern | so, that would make october 11-12 a potential date | 07:42 |
| juliusb | yep, that'd work for me | 07:43 |
| wallento | same here, there is always enough beer in Munich ;) | 07:44 |
| juliusb | http://opencores.org/or1k/OpenRISC_Project_Meeting#ORCONF_2014 | 07:49 |
| olofk_ | juliusb: Hey, shouldn't that be orconf.org#ORCONF_2014 ? ;) | 07:50 |
| blueCmd | stekern: fix was 3 things: 1) the binutils fix 2) the gcc fix and 3) disallow fPIc/fno-PIC code (no patch, i just did stuff to the make files for mpfr there) | 07:50 |
| olofk_ | http://orconf.org/#ORCONF_2014 | 07:50 |
| juliusb | brilliant olofk_ | 07:51 |
| olofk_ | But feel free to ignore anything I say. It's not like it's my birthday or anything... | 07:51 |
| blueCmd | for 3 that should probably be solved in binutils as well, I have an idea how to solve itbut havent gotten around to it, I dont think mixing is that common either so its no priority | 07:51 |
| juliusb | hmm, you might say that even if it wasn't... | 07:51 |
| juliusb | but, possibly it is! is it? | 07:51 |
| olofk_ | Yes! :) | 07:52 |
| juliusb | well happy birthday mate! | 07:52 |
| olofk_ | Thanks! | 07:52 |
| stekern | blueCmd: yes, I remember, all came back to me after I had got some coffe ;) | 07:52 |
| olofk_ | hmm... this web chat client is strange | 07:54 |
| blueCmd | wallento: wow! ive been dreaming of multicore openrisc | 07:55 |
| stekern | happy birthday olofk_ | 07:55 |
| blueCmd | lets get that a stable thing, really awesome! | 07:55 |
| blueCmd | olofk_: gz! :D | 07:55 |
| olofk_ | stekern: Thank you. It feels like I have lived for 100000 years today | 07:55 |
| wallento | blueCmd: bad dreams? ;) | 07:57 |
| wallento | speaking of bad dreams: I started porting FIASCO.OC to OpenRISC. It is an L4 microkernel including an L4 runtime environment, where you can run a paravirtualized version of the Linux Kernel L4Kernel on top | 07:59 |
| blueCmd | wallento: no! :) I would be delighted to help implement this in or1ksim and linux | 07:59 |
| wallento | https://os.inf.tu-dresden.de/fiasco/overview.html | 07:59 |
| blueCmd | oh, that could be cool as well | 08:01 |
| blueCmd | do you have anything in mind with it? | 08:01 |
| wallento | it's for a research project here | 08:04 |
| stekern | (fiasco) that sounds interesting | 08:05 |
| wallento | I will come back to you soon regarding the linux port. I already had a look at the basic stuff like head.S, there my comments and patches to or1k-src might be useful regarding exception stacks and ISR0 etc. for the rest I don't know what is necessary to port Linux SMP | 08:07 |
| blueCmd | neither do I, which is what's exciting :) | 08:09 |
| blueCmd | so. stekern, should we upstream newlib as well? does it make any sense? | 08:11 |
| blueCmd | and libgloss maybe? | 08:12 |
| stekern | I think a lot comes "for free" from underlying structures, but there's definitely work that needs to be done. | 08:12 |
| stekern | and it's not like SMP Linux is an uncommon thing, so there's loads of examples from other archs to take from ;) | 08:14 |
| wallento | I would also think so | 08:14 |
| blueCmd | yeah, like TLS | 08:15 |
| blueCmd | haha, hopefully not | 08:15 |
| blueCmd | TLS is implement differently everywhere, I suspect SMP might be as well | 08:15 |
| blueCmd | anyway | 08:15 |
| blueCmd | time to go to work | 08:15 |
| stekern | I'm very interested in running SMP Linux as well, so count me in on the collaboration on that. | 08:16 |
| wallento | problem is a bit on the simulator/emulator side | 08:16 |
| wallento | i work on mor1kx cache coherency | 08:16 |
| wallento | but doing this in qemu or or1ksim is challenging I believe | 08:17 |
| stekern | yeah, I don't know if it'd even make sense to do it in qemu | 08:18 |
| stekern | or1ksim is another story | 08:18 |
| wallento | we had some archc/systemc simulator work before, but it turned out to be a dead end | 08:20 |
| wallento | i did some work on or1ksim before (~2009) | 08:21 |
| stekern | I recall that | 08:21 |
| wallento | maybe I can get a student to take this up and work on some basic coherency mechanism | 08:21 |
| wallento | as or1ksim is an instruction set simulator, doing this should be easy, just doing direct manipulation from one cache to the other | 08:22 |
| stekern | that'd be great I think | 08:23 |
| blueCmd | in userspace qemu, no that doesn't make any sense | 08:40 |
| blueCmd | I don't know if we have full system emulation in qemu | 08:40 |
| blueCmd | (if we do, I need to look at it ASAP :P) | 08:40 |
| olofk_ | wallento: How about using verilator? | 08:42 |
| wallento | yes, thats what we do at the moment | 08:42 |
| wallento | and what i prefer | 08:43 |
| wallento | i just mean in a sense of not making further parts of OpenRISC unusable in the long term | 08:43 |
| olofk_ | ah ok | 08:43 |
| wallento | i don't know, how many people use what | 08:44 |
| jungma | ey guys, I have a whishbone to TLM2.0 Transactor ready, to use it with a verilated OR ... where can I upload this? | 08:44 |
| wallento | does anybody have an overview? even for me, who somehow understands wide parts of openrisc, it is entirely confusing at the moment | 08:44 |
| wallento | qemu, mor1kx, or32, or1k, linux, or1ksim and all this.. | 08:45 |
| jungma | wallento: yes :) | 08:45 |
| wallento | not to speak where to find was | 08:45 |
| wallento | *what | 08:45 |
| jungma | its indeed confusing | 08:45 |
| olofk_ | jungma: Cool. I would like to take a look at it and see how we can fit it into FuseSoC and orpsoc-cores | 08:46 |
| olofk_ | jungma: Could you just put it on github or something in the meantime? | 08:47 |
| olofk_ | And yes. It's all very confusing. The curse of OpenRISC it seems :) | 08:47 |
| jungma | olofk_: yes i will do, or upload it to our project page at university ... | 08:48 |
| olofk_ | jungma: Cool. I would love to have support for it in FuseSoC. Just have to get an idea of what it looks like first. Please tell me when you have a link to it | 08:49 |
| wallento | yeah, that was always there ;) but at least it would be nice to assemble a short overview of the different projects _for developers_, that summarizes the state and where to find the currently developed version | 08:50 |
| wallento | on some wiki subpage | 08:50 |
| stekern | agreed, we try to centralize information here: http://opencores.org/or1k/OR1K:Community_Portal | 08:52 |
| stekern | but, admittedly, the situation is suboptimal to say the least | 08:52 |
| wallento | i know, but i think it needs a distinction between users and developers i think | 08:52 |
| wallento | that can also make the wiki simpler i think | 08:53 |
| stekern | right, that's probably true | 08:54 |
| wallento | so that people that want to "try out" OpenRISC have a starting point without understanding everything | 08:54 |
| wallento | like the upper part on the landing page | 08:54 |
| wallento | but once you click on GNU toolchain.. | 08:55 |
| wallento | ;) | 08:55 |
| stekern | heh, yeah... as I said, the problem is known... | 08:55 |
| wallento | once I got my mor1kx work done, I will try to assemble something as such | 08:56 |
| olofk_ | Slighty related. I'm about to start writing a monthly or quarterly status report on OpenRISC. For this first part I'm planning on writing about what has happened since orconf. | 09:01 |
| stekern | that'd be great, and is completely aligned with the openrisc community philosophy, if you complain about it, fix it ;) | 09:01 |
| olofk_ | I got atomic operations, debian, multicore, new board ports, binutils. Anything I have missed? | 09:02 |
| olofk_ | glibc perhaps? | 09:04 |
| stekern | a musl port in the works | 09:04 |
| stekern | multiway caches for mor1kx | 09:05 |
| blueCmd | olofk_: glibc was ported last year :) | 09:20 |
| blueCmd | for the community page, I still think a media wiki on openrisc.net would be better | 09:21 |
| stekern | I think the content off the media wiki might be more important than the location ;) | 09:28 |
| stekern | -f | 09:28 |
| wallento | +1 | 09:28 |
| blueCmd | stekern: sure, but it's a pain to edit stuff currently IMO | 09:29 |
| stekern | perhaps, but why would another media wiki make it easier? | 09:30 |
| wallento | principally i think: wiki can be edited by anybody and is edited by nobody or somebody once | 09:30 |
| wallento | but its not a really a matter of the tool i think, more about everybody is curious about his stuff and not about selling it properly.. | 09:32 |
| blueCmd | stekern: a fair point, but two impressions I have of the openrisc page today: 1) ugly 2) it has ads 3) its integration with the opencores cluster f*ck is confusing | 09:33 |
| blueCmd | it also contains a lot of old stuff, but that's just cleanup job away | 09:34 |
| jungma | i think a wiki makes only sense for deep internals, for a total beginner it might be cool if there is a nice website with a cool and attractive layout (with logo :P) where one can find simple start instructions | 09:34 |
| stekern | blueCmd: your points are also fair, I agree on all three | 09:35 |
| blueCmd | jungma: yes, MediaWiki allows you to create really nice frontpages I think | 09:35 |
| stekern | ...but, I still think the content is what we should concentrate on first hand | 09:35 |
| blueCmd | I don't see why we cannot do both | 09:36 |
| blueCmd | (I guess concentrating on two things might be a oxymoron) | 09:36 |
| stekern | ah, well, we seem to have a hard time to concentrate on one thing at them moment (the content) | 09:38 |
| jungma | the problem is, that wikis get automatically outdated, if nobody takes care about the content | 09:38 |
| stekern | and, btw, you know that the current community wiki is media wiki, right? (but that doesn't take away the integration and the ads, admitted) | 09:39 |
| blueCmd | stekern: it is? oh my god what have they done with it! :) | 09:41 |
| stekern | personally, I wouldn't mind the entry page being at openrisc.net though | 09:41 |
| blueCmd | but it makes sense, it's not the markup I'm afraid of - it's the execution | 09:42 |
| stekern | but given all the previous pie throwing and drama about where to host stuff, I just can't bring myself to bother enough about another round of that kind of nonsense... | 09:43 |
| jungma | the problem is, as a new user i go to openrisc.net and i see this: | 09:43 |
| jungma | Last updated 2012-01-04 20:50:22 CET | 09:43 |
| jungma | and then i think the project is dead | 09:44 |
| blueCmd | yep | 09:44 |
| jungma | same counts for this page: http://opencores.org/or1k/Main_Page | 09:45 |
| jungma | SVN Updated: Feb 24, 2011 | 09:45 |
| jungma | maybe redirect openrisc.net to this opencores wiki and start editing the content there... | 09:46 |
| blueCmd | stekern: would you mind removing https://github.com/openrisc/or1k-eglibc and forking https://github.com/bluecmd/or1k-glibc instead ? | 09:47 |
| stekern | not at all | 09:47 |
| stekern | I think you can create the or1k-glibc yourself though | 09:47 |
| wallento | for the first I will try to assemble this: http://opencores.org/or1k/OR1K:DevelopmentOverview | 09:48 |
| wallento | feel free to complete :) | 09:48 |
| stekern | I'll remove the or1k-eglibc though | 09:48 |
| blueCmd | I'm just a member, not an owner so I don't think I can | 09:48 |
| stekern | try | 09:48 |
| blueCmd | ah right,, maybe I can create | 09:48 |
| stekern | it's intended that you can | 09:48 |
| blueCmd | I was focusing on the destruction | 09:48 |
| stekern | haha, be creative, not destructive ;) | 09:48 |
| blueCmd | ooh | 09:48 |
| blueCmd | it worked | 09:48 |
| jungma | this is a cool example for a landing page: http://brew.sh/ | 09:50 |
| stekern | it's still not perfect, repos added will be accessible by everybody, so it's still some manual labour involved. but, at least it allows for all members to initiate any repos of their | 09:50 |
| blueCmd | hm, is openrisc.net hosted on a personal internet connection? | 09:59 |
| olofk_ | I agree with stekern that the biggest problem is we don't have enough and too much content | 10:00 |
| stekern | wallento: that looks good, and should be relatively easy to maintain | 10:00 |
| olofk_ | It's already confusing enough with openrisc.net, opencores.org and github.com/openrisc. I really really don't want to move information around without a solid plan | 10:00 |
| olofk_ | But I agree that the stuff on OpenCores is ugly | 10:00 |
| olofk_ | But let's move it when we have something more solid then | 10:01 |
| olofk_ | Because every new location we use to host additional stuff tends to be outdated quite soon | 10:01 |
| olofk_ | New people seem to notice the guides at openrisc.net or Kevin Mehall's stuff first | 10:03 |
| olofk_ | Both guides are already slightly outdated | 10:03 |
| _franck_web_ | that's why there should be only one. Others, old ones, might redirect to the new one | 10:03 |
| olofk_ | _franck_web_: Speaking of which, could you update your elec4fun article to mention FuseSoC instead of ORPSoC :) | 10:04 |
| stekern | haha, burn! | 10:05 |
| _franck_web_ | danm, should have closed my big mouth :) | 10:07 |
| olofk_ | :) | 10:08 |
| jungma | so if you need help designing a cool state-of-the-art landing page don't hesitate to ask ;) | 10:33 |
| ams | cat /dev/random > index.html | 10:34 |
| jungma | this might have mor information than the current pages :D | 10:35 |
| jungma | *e | 10:36 |
| ams | =) | 10:39 |
| stekern | olofk_: we've got to come up with a way for the cache to realise that it should be invalid when the provider is changed | 11:37 |
| stekern | wallento: I got the modelsim demo working here, for fun, I tried running with verilator (since a quick glance suggests there should be some support for that). I haven't looked closer, which I will, but is there some known reason why that doesn't work? | 11:51 |
| wallento | no, but i can check it | 11:54 |
| wallento | it runs, but the trace monitor does not work, a quick hack of course.. I will check it | 11:58 |
| wallento | ah, it is not there :) | 11:59 |
| wallento | verilator simulation seems different from verilog simulation | 12:01 |
| stekern | I can poke around it bit if you don't have a burning desire yourself ;) | 12:07 |
| stekern | *a bit | 12:07 |
| stekern | it looks cool with 2 mor1kx instances in gtkwave at least =) | 12:08 |
| wallento | i am nearly finished with a dirty hack | 12:10 |
| stekern | wallento: ah, only l.nop 4 putc works(?) | 12:23 |
| wallento | yes | 12:23 |
| wallento | i see | 12:23 |
| stekern | I added a hack in tb.cpp to print those for cpu0 and then I got output | 12:23 |
| wallento | i will commit a small trace monitor in a few minutes | 12:23 |
| wallento | for both | 12:23 |
| stekern | I didn't gate it on any stall signals, but: http://pastie.org/9123989 | 12:25 |
| stekern | ;) | 12:25 |
| wallento | :) | 12:27 |
| stekern | is the uart disabled on purpose? | 12:29 |
| wallento | not really, did not understand at first glance ;) | 12:29 |
| wallento | the double characters are from top->wb_clk_i = !top->wb_clk_i; | 12:30 |
| stekern | ok... let me rephrase that question, in the modelsim simulation is the printouts I see going through the trace monitor by l.nop 4? | 12:30 |
| wallento | yes | 12:30 |
| wallento | Before using uart, you need to lock printf accesses | 12:31 |
| wallento | i think there is something like printf_uart, correct? | 12:31 |
| stekern | (double) yes I know, I just wanted to see if there would be any output ;) | 12:31 |
| stekern | yes, that's why I started to suspect that l.nop 4 was used, I saw in the disasm that the uart_putc was never called, but there was a l.nop 4 instead | 12:32 |
| stekern | (lock uart_putc) ok, yeah, that makes sense | 12:35 |
| wallento | okay | 12:35 |
| stekern | I thought that was already done, but for l.nop 4 you can of course ignore that issue | 12:36 |
| wallento | you can update orpsoc-cores on multicore-demo | 12:36 |
| wallento | in my project we essentially do everything via the traceport | 12:36 |
| wallento | :) | 12:36 |
| stekern | I see ;) | 12:36 |
| wallento | so, push finally worked | 12:38 |
| wallento | https://github.com/wallento/orpsoc-cores/commit/cfe50ebecdf77765ae0457fb126d82d51232521c | 12:38 |
| wallento | http://pastie.org/9124089 | 12:39 |
| wallento | don't judge me by this commit ;) | 12:40 |
| wallento | I also adopted the instructions: http://pastebin.com/uDsh5DJE | 12:41 |
| stekern | yeah, I saw the commit. I actually have a similar hack (but for single core) locally here | 12:42 |
| stekern | in the mor1kx-generic system | 12:43 |
| stekern | http://pastie.org/9124057#73 | 12:43 |
| stekern | combining and cleaning up both our hacks and it's probably something we should commit ;) | 12:44 |
| wallento | yes, definetely :) I have something similar lying around, I will search for it later | 12:44 |
| stekern | but otoh, with the synthisizable trace monitor they might be both be redundant | 12:45 |
| stekern | -be | 12:45 |
| wallento | i think you can do a lot more in simulation as for example with mor1x_monitor | 12:45 |
| stekern | https://asciinema.org/a/9182 | 12:49 |
| stekern | true, and it's a lot easier to hack in some debug stuff in tb.cpp than in rtl | 12:50 |
| wallento | asciinema, nice one | 12:57 |
| wallento | never heard of it | 12:57 |
| olofk_ | wallento: I like this line in your build scripts :) wget http://pastebin.com/download.php?i=1dyUnygK -O hello.c | 13:03 |
| olofk_ | stekern: Nice. You got it running under verilator? | 13:04 |
| olofk_ | oh, and yes. Proper cache management is starting to climb up the priority list for FuseSoC | 13:05 |
| stekern | olofk: yes, with the l.nop 4 support wallento 'hacked' into his tb.cpp it works fine with verilator | 14:49 |
| stekern | olofk, _franck_: does this ring any bells? http://pastie.org/9124594 | 15:51 |
| stekern | seems like verilator.py tries to create the .h file before the self.sim_root is created | 16:09 |
| stekern | fix: http://pastie.org/9124642 | 16:10 |
| stekern | err, scratch that... | 16:14 |
| blueCmd | stekern: 201 references to __sync and 3 to __atomic in the packages that are failing to build currently | 16:16 |
| stekern | blueCmd: about time to add support for them then ;) | 16:42 |
| blueCmd | stekern: as soon as you're done with the specification :) | 16:46 |
| stekern | ah... well, I'd say what you need for that is already 'set in stone' | 16:57 |
| stekern | i.e the instruction names and encodings | 16:57 |
| stekern | and implementation | 16:58 |
| stekern | what's left is to paint it octarine | 16:58 |
| stekern | _franck_: trying to confirm what Jose is saying about si, it's not working with newer openocd (I probably haven't tried the latest), but it does with older ones(?) | 17:01 |
| stekern | with older ones, I think it's pre-xml and set $pc= et al support | 17:01 |
| stekern | 'with older ones' I meant... a lot of kids running around me right now... bbl | 17:04 |
| stekern | bah, that just got even more confusing... let me try again =) | 17:07 |
| stekern | and when I say older ones, it's a version 'pre-xml' and 'set $pc=' support | 17:09 |
| blueCmd | stekern: ack! | 17:14 |
| stekern | _franck_: scratch that, now the new one works too... | 17:27 |
| blueCmd | stekern: you will have to upstream your atomics in binutils ASAP if I'm gonna start building packages with it though :) | 17:29 |
| blueCmd | since I'm using a nice and clean binutils straight from the upstream now | 17:30 |
| blueCmd | stekern: did you see this before? | 18:04 |
| blueCmd | # cp -a ./debian/tmp/usr/bin/jack_alias debian/jackd1//usr/bin/ | 18:04 |
| blueCmd | /bin/cp: './debian/tmp/usr/bin/jack_alias': Bad address | 18:04 |
| blueCmd | I think my coreutils might be broken | 18:05 |
| blueCmd | yep, downgrading it worked | 18:06 |
| blueCmd | stekern: when you built gstreamer, did you do anything special then? | 18:53 |
| blueCmd | http://wannabuild.cmd.nu/fetch.php?pkg=gstreamer0.10&arch=or1k&ver=0.10.36-1.2&stamp=1398614963 fails | 18:53 |
| blueCmd | yep, a patch is needed - hack build it is :) | 19:33 |
| stekern | yeah, all sorts of voodoo and hoodoo iirc... | 19:34 |
| blueCmd | this is clearly production ready for space | 19:35 |
| stekern | http://oompa.chokladfabriken.org/openrisc/debs/ | 19:37 |
| stekern | it's there if you want to grab it | 19:37 |
| stekern | ah, right... the patch needed is actually in newer versions of that package | 19:40 |
| stekern | https://bugzilla.gnome.org/review?bug=706462&attachment=252504 | 19:42 |
| stekern | (upstream atomic patch) don't worry, I will | 19:45 |
| blueCmd | stekern: ah right, I'm building it currently - thanks anyway (gstreamer) | 20:07 |
| stekern | yeah, it wasn't as much voodoo involved as I remembered. xaw3d was the tricky one (due to xutils-dev) | 20:08 |
| blueCmd | stekern: review please: http://e334be02134a0ca3.paste.se/ | 20:11 |
| blueCmd | I'm a bit worried about the million tmp RTXs | 20:11 |
| blueCmd | but they're needed and I cannot create them inside the switch | 20:12 |
| blueCmd | giving them a more meaningful name is also hard | 20:12 |
| stekern | 'inside the switch' <- I don't get that? | 20:13 |
| stekern | coding style nit on 16 and 21, missing space before ( | 20:16 |
| blueCmd | gcc was very angry if I moved the declaration of the variables to the case: context | 20:16 |
| stekern | even with: case: contex { rtx tmp; tmp = gen_reg_rtx (Pmode); break } | 20:17 |
| stekern | ? | 20:17 |
| blueCmd | I cannot sweat I used the {} | 20:18 |
| stekern | without it I can swear it will not work ;) | 20:18 |
| blueCmd | I'll try | 20:18 |
| blueCmd | ah, ok | 20:18 |
| blueCmd | I don't get the bracket indentation in gcc, it's weird | 20:19 |
| stekern | gnu coding style is barock all over | 20:19 |
| stekern | you've got the brackets wrong on 18 and 22 now when you mention it | 20:20 |
| blueCmd | yes, I'm fixing that - thansk | 20:21 |
| stekern | use emacs and do c-set-style gnu is easiest way to get it right I think | 20:21 |
| blueCmd | emcas is not easy :) | 20:24 |
| blueCmd | http://47ab245effcbc730.paste.se/ PTAL | 20:24 |
| _franck_ | or you can use "indent" | 20:25 |
| _franck_ | without any parameter, it default to gnu C style | 20:25 |
| stekern | emacs is easy, you type in text and it appears on screen, how hard is that? =) | 20:26 |
| stekern | vi is a lot harder, you have to find the magic 'i' key before text starts appearing on the screen | 20:27 |
| blueCmd | hah, vim <3 | 20:28 |
| stekern | yeah, when I say vi, I usually mean vim | 20:29 |
| blueCmd | a lot of people that say they use vi, put infront of vi and not vim will be very very lost :P | 20:30 |
| stekern | haha, true | 20:30 |
| blueCmd | I just spotted that ncurses built from my old pre-Debian toolchain is compiled like: | 20:31 |
| blueCmd | or1k-linux-gnu-gcc ../objects/tset.o ../objects/transform.o -I../progs -I/home/bluecmd/or1k-devel/tools/ncurses-5.9/progs -DHAVE_CONFIG_H -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DNDEBUG -I. -I../include -I/home/bluecmd/or1k-devel/tools/ncurses-5.9/progs/../include -O2 --param max-inline-insns-single=1200 -static -L../lib -lncurses -dynamic -o tset | 20:32 |
| blueCmd | notice anything? | 20:32 |
| stekern | we had a admin at the university I attended that insisted on only installing vi (no m) on the *nix servers | 20:32 |
| stekern | "why? that's the only editor you'll ever need" was his response when someone requested something else. | 20:33 |
| stekern | I see a _FILE_OFFSET_BITS=64 | 20:34 |
| blueCmd | yes! | 20:34 |
| blueCmd | which is a relief | 20:34 |
| blueCmd | because it means that it is not set in glibc but in the app | 20:34 |
| stekern | right, that's what I said the other day, without realising the meaning of it | 20:35 |
| stekern | ...so, doesn't that mean that pkg-config does *not* define that? | 20:37 |
| blueCmd | stekern: yes, this supports that | 20:37 |
| blueCmd | stekern: or that it uses a library that doesn't | 20:37 |
| stekern | I'll check what happens in my readdir test cases if I define it | 20:37 |
| blueCmd | exciting! | 20:38 |
| stekern | 10b8: 04 00 6e 9f l.jal 1cb34 <__readdir64> | 20:43 |
| stekern | woho! | 20:43 |
| stekern | how silly that I didn't figure that out... | 20:44 |
| blueCmd | cool! | 20:45 |
| stekern | at least everything falls into place now how the define-magic in glibc works, and things make a lot more sense | 20:48 |
| blueCmd | indeed | 20:50 |
| stekern | only thing left to do to close that whole chapter is to figure out where/why some things are compiled without that define | 20:53 |
| stekern | because, you saw it somewhere else than in pkg-config, right? | 20:53 |
| blueCmd | yes, apt-key | 20:54 |
| stekern | yup | 20:56 |
| stekern | # apt-key | 20:56 |
| stekern | run-parts: failed to open directory /etc/apt/trusted.gpg.d: Value too large for defined data type | 20:56 |
| stekern | well, apt-key is a script | 20:58 |
| stekern | that (not so surprisingly) runs run-parts | 21:01 |
| blueCmd | an right | 21:01 |
| blueCmd | ah* | 21:01 |
| blueCmd | so I guess run-parts doesn't like it :) | 21:01 |
| stekern | yes | 21:02 |
| stekern | ...or no, it doesn't | 21:02 |
| blueCmd | now.. so where are these __sync supposed to be implemented? | 21:03 |
| blueCmd | http://gcc.1065356.n5.nabble.com/Patch-0-3-ARM-64-bit-atomic-operations-td545734.html seems to be arm64's patch to support it | 21:08 |
| blueCmd | http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01290.html mips seems quite close to what we have | 21:11 |
| stekern | doesn't look completely trivial... | 21:13 |
| blueCmd | well MIPS doesn't look too bad | 21:13 |
| blueCmd | we could implement it using libgcc, but I much prefer if it could be implemented in gcc builtins | 21:14 |
| blueCmd | m68k uses libgcc apparently (since they use syscalls) | 21:14 |
| blueCmd | I might want to revise that statement.. | 21:17 |
| blueCmd | this is the new sync.md they are using: https://raw.githubusercontent.com/bluecmd/or1k-gcc/master/gcc/config/mips/sync.md | 21:17 |
| blueCmd | look at atomic_compare_and_swap | 21:18 |
| blueCmd | we can probably shave a lot of code off though. apparently that is for both legacy __sync (a lot of __sync_old) and apparently mips and mips64 | 21:19 |
| blueCmd | the first patch looks simpler, I'll use that as guide I think | 21:21 |
| stekern | yes, it's probably best to just start in one end and try to go for the simplest solution possible | 21:21 |
| stekern | _franck_: there _is_ some fishy stuff going on with debugging | 21:22 |
| stekern | with single stepping | 21:22 |
| _franck_ | I know that strange things happened sometimes. It's on my todo list | 21:23 |
| stekern | sometimes (it seems to be 'session' bounded) a si will just set the target of running | 21:23 |
| stekern | off | 21:23 |
| _franck_ | we can know debug this pretty easily with jtag_vpi and mor1kx_generic | 21:23 |
| stekern | i.e. it never stalls | 21:23 |
| stekern | right, do you want to guide me a bit through that? | 21:24 |
| _franck_ | let's try it | 21:24 |
| _franck_ | http://pastie.org/9125374 | 21:25 |
| _franck_ | that's what I replied to some guy who was asking some help | 21:26 |
| blueCmd | stekern: it failed to generate docs, I might just use your dpkgs | 21:26 |
| blueCmd | for gstreamer | 21:26 |
| _franck_ | stekern: Edit ./tcl/board/or1k_generic.cfg and change set set TAP_TYPE VJTAG to | 21:26 |
| _franck_ | TAP_TYPE MOHOR. | 21:26 |
| _franck_ | is no longer needed | 21:26 |
| _franck_ | you can do -c "set TAP_TYPE MOHOR" | 21:27 |
| stekern | blueCmd: I think it failed at first for me too | 21:27 |
| blueCmd | stekern: yeah, I just don't want to mess around with it :P | 21:27 |
| blueCmd | right now | 21:28 |
| stekern | _franck_: I think I'll need to update my openocd for that, let's stick with the .cfg change for now ;) | 21:28 |
| blueCmd | stekern: now the trojans and viruses you put there is included | 21:29 |
| stekern | excellent! | 21:29 |
| stekern | my paycheck from NSA will be a big one this month | 21:30 |
| blueCmd | Hah | 21:31 |
| stekern | _franck_: but, that's for icarus, what you pasted. right? | 21:31 |
| _franck_ | it is | 21:31 |
| stekern | well, I can try with that for starters | 21:32 |
| _franck_ | Jose T. de Sousa did some work to make it work with Verilator: | 21:33 |
| _franck_ | https://github.com/jjts/orpsoc-cores/commit/d05b40eb2f0ddf9ef3a6f124ddc7d1848b73b890 | 21:33 |
| stekern | http://pastie.org/9125384 | 21:35 |
| stekern | yeah, well, I can't get that repo to compile at all with verilator with the current fusesoc | 21:36 |
| _franck_ | mor1kx_monitor.v:42: Include file test-defines.v not found --> this is new, I didn't have this before | 21:36 |
| _franck_ | I discovered that while doing my neek port | 21:36 |
| stekern | http://pastie.org/9124594 | 21:36 |
| _franck_ | it it that broken ?! | 21:36 |
| _franck_ | let me try | 21:37 |
| stekern | the directory /home/stefan/openrisc/orpsocv3/build-jjts/build/de0_nano_sim/sim-verilator/bench/verilator/ doesn't exist when it tries to write that file | 21:38 |
| stekern | I think the problem is that the 'filename' is bench/verilator/orpsoc-defines.h | 21:38 |
| stekern | and bench/verilator is non-existing | 21:39 |
| stekern | ok, I need to build openocd with jtag_vpi support too | 21:42 |
| blueCmd | pff, http://wannabuild.cmd.nu/package.php?p=norwegian&suite=sid | 21:44 |
| blueCmd | who needs norwegian? | 21:44 |
| blueCmd | http://wannabuild.cmd.nu/package.php?p=swedish&suite=sid swedish is much better | 21:44 |
| stekern | kjempeflott | 21:45 |
| blueCmd | haha | 21:46 |
| stekern | _franck_: what's the ./configure knob for jtag_vpi? | 21:46 |
| stekern | --enable-jtag_vpi? | 21:46 |
| _franck_ | I guess | 21:46 |
| stekern | let's try ;) | 21:47 |
| _franck_ | ./configure --help | 21:47 |
| stekern | $ ./configure --help |grep vpi --enable-jtag_vpi Enable building support for JTAG VPI | 21:48 |
| blueCmd | "So which version do you have on jackd2?" | 21:48 |
| blueCmd | "Oh, it's the good old 1.9.9.5+20140404git3d7c67dc~dfsg-1" | 21:48 |
| stekern | ah, that one I need for scummvm | 21:49 |
| _franck_ | stekern: adding the missing test-defines.v file solves the problem | 21:49 |
| stekern | which (of all our) problem(s)? =) | 21:49 |
| blueCmd | ALL! | 21:49 |
| _franck_ | yes all, my car is fixed now too ;) | 21:50 |
| stekern | amazing | 21:50 |
| _franck_ | well no, I just restart fusesoc and sometimes it starts the sim, sometimes not | 21:51 |
| _franck_ | need to look again | 21:51 |
| stekern | oh no... I still have this weird libtool problem with openocd that I haven't figured out.. | 21:51 |
| blueCmd | openocd! regs, am I supposed to be able to read them? is there any hackery required on my part? | 21:52 |
| _franck_ | last time I tried to read regs on the mor1kx, I read weird things | 21:53 |
| stekern | ...add support for reading them via the spr space in mor1kx | 21:53 |
| stekern | the spr bus is in no way connected to the reg file currently | 21:53 |
| blueCmd | stekern: are you writing your TODO list in the channel now again? :) | 21:53 |
| _franck_ | but, you don't need anything special apart that. Just halt the target "halt" the "reg npc" for example | 21:54 |
| blueCmd | right npc works | 21:54 |
| blueCmd | but reg r10 doesn't | 21:54 |
| blueCmd | (or didn't rather, I don't have the test setup atm) | 21:54 |
| stekern | yes. IRC, the interactive notepad, with automatic save | 21:55 |
| blueCmd | hard to edit stuff though | 21:55 |
| stekern | hah, have you ever seen me do any typos!?!? | 21:56 |
| stekern | ...occasionally... | 21:58 |
| _franck_ | where does "test-defines.v" comes from ? | 21:59 |
| _franck_ | I have it locally but can't remember where I found it | 22:00 |
| stekern | it's an old orpsocv2 thing | 22:00 |
| stekern | it's autogenerated there | 22:00 |
| blueCmd | stekern: go to http://wannabuild.cmd.nu/architecture.php?a=or1k&suite=sid and click the "Build-Attempted" link | 22:01 |
| blueCmd | (the link for that page is huge so I cannot paste it here) | 22:01 |
| blueCmd | that's a really really nice page, it shows the tail of all the failed packages build logs | 22:01 |
| _franck_ | stekern: ok, because bench/verilog/mor1kx_monitor.v includes it | 22:02 |
| stekern | ah, nice | 22:03 |
| blueCmd | olofk: have you thought about allowing non-free cores? I'm thinking like creating a core that can create the IP-core files needed to generate XCVR cores and stuff | 22:03 |
| stekern | _franck_: -c "set TAP_TYPE MOHOR" doesn't seem to work | 22:07 |
| _franck_ | ps2 won't be supported on my neek board :( I would need to get the scope home to see what's going on | 22:08 |
| stekern | ...if you put the -c in the wrong place in the command line | 22:08 |
| _franck_ | that's what I was about to say :) | 22:08 |
| stekern | otherwise it works perfectly! =) | 22:08 |
| stekern | Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1001). Workaround: increase "set remotetimeout" in GDB | 22:10 |
| stekern | I guess that's due to the slowness of the simulation | 22:10 |
| _franck_ | do what it says :) | 22:10 |
| _franck_ | right, it's because it is slow | 22:11 |
| blueCmd | running gdb into a simulation of a CPU is pretty badass | 22:11 |
| _franck_ | last time I had or1ksim accessing a register in a RTL simulated design thru openocd | 22:14 |
| _franck_ | https://github.com/fjullien/or1ksim/commit/0befe7d74752066c9663613965b17db0894af93b | 22:14 |
| blueCmd | hah | 22:14 |
| blueCmd | nice! :) | 22:14 |
| _franck_ | or1ksim can now access real or simulated hardware | 22:15 |
| _franck_ | it works with a PIO at least ;) | 22:15 |
| blueCmd | that could be an awesome thing to support in or1ksim out of the box | 22:15 |
| _franck_ | I think we can build openocd as a lib. Then we could link it to or1ksim and git rid of the server/client thing | 22:17 |
| _franck_ | s/git/get | 22:17 |
| blueCmd | yes, that would be cool | 22:18 |
| blueCmd | stekern: do you need pulseaudio for scummvm? | 22:24 |
| stekern | yes | 22:26 |
| blueCmd | dpkg-deb: building package `pulseaudio' in `../pulseaudio_5.0-1_or1k.deb'. | 22:26 |
| stekern | and libsdl (which depends on pulseaudio) | 22:27 |
| blueCmd | do you know mafm? | 22:28 |
| blueCmd | he pops in here from time to time and helps me build packages (he probably built the majority of the packages by now) | 22:28 |
| blueCmd | he just happens to be the maintainer of a lot of sdl packages | 22:28 |
| blueCmd | and he wants to get it running on or1k | 22:29 |
| blueCmd | so that's a great fit :) | 22:29 |
| stekern | ;) | 22:30 |
| blueCmd | so sdl-mixer1.2 depends on libmikmod-dev -> libopenal-dev -> libroar-dev -> libao-dev -> pulse | 22:37 |
| blueCmd | libao is scheduled for build, so maybe that will solve itself (fingers crossed!) | 22:37 |
| blueCmd | argh, right. we need to port libgc as well. and fix __attribute__((destructor)) for krb5 | 22:37 |
| stekern | what's the problem with __attribute__((destructor)) | 22:49 |
| stekern | ? | 22:49 |
| blueCmd | it apparently doesn't fire at exit | 22:49 |
| blueCmd | https://github.com/bluecmd/or1k-debian/issues/15 | 22:49 |
| stekern | http://www.firstsafetysigns.co.uk/WebRoot/BT2/Shops/Store2_002E_Shop1848/45F5/5237/8C52/1E9E/0B60/AC10/3D29/3880/300mmx150mm-Fire-exit-left_m.gif | 22:49 |
| stekern | ? | 22:49 |
| blueCmd | hah, wut? | 22:50 |
| blueCmd | aha | 22:50 |
| stekern | fire at exit | 22:50 |
| blueCmd | haha | 22:50 |
| stekern | hmmm, that sounds familiar somehow | 22:51 |
| blueCmd | I had som problems with atexit and stuff when doing glibc, and possibly when doing DWARF2 | 22:51 |
| blueCmd | http://wannabuild.cmd.nu/package.php?p=cdrom-checker&suite=sid | 22:56 |
| blueCmd | that's a useful one | 22:56 |
| blueCmd | "configure: error: libdrm_radeon depends upon atomic operations, which were not found for your compiler/cpu. Try compiling with -march=native, or install the libatomics-op-dev package, or, failing both of those, disable support for Radeon support by passing --disable-radeon to ./configure | 22:56 |
| blueCmd | atomics are everywhere! | 22:56 |
| blueCmd | or rather needed everywhere | 22:56 |
| blueCmd | i'd better get started on that. fusesoc core api will have to wait | 22:57 |
| stekern | http://juliusbaxter.net/openrisc-irc/%23openrisc.2013-07-13.log.html#t05:35 | 22:58 |
| stekern | there I'm saying something about constructors/destructors | 22:58 |
| stekern | no context to what it's about though | 22:59 |
| stekern | but I'm 100% sure I have investigated some kind of problem related to __attribute__((destructor)) | 23:00 |
| stekern | http://juliusbaxter.net/openrisc-irc/%23openrisc.2013-07-09.log.html#t00:37 | 23:01 |
| stekern | getting closer | 23:01 |
| stekern | poke53281: do you remember this? | 23:02 |
| poke53281 | Hi stekern | 23:02 |
| poke53281 | Yes, we had some problems with the constructors and destructors in C and C++. They were not called. | 23:03 |
| poke53281 | because the linker could not find the correct symbols. | 23:03 |
| stekern | ah, now it all comes back to me | 23:03 |
| poke53281 | I think the problem were really simple. lower case vs. upper case. | 23:04 |
| stekern | blueCmd: https://github.com/openrisc/or1k-glibc/blob/master/ports/sysdeps/or1k/crtn.S <- change those to _init and _fini | 23:06 |
| poke53281 | Yes, exactly. | 23:06 |
| stekern | and here's the mail with the rationale behind it: https://www.mail-archive.com/openrisc@lists.openrisc.net/msg01209.html | 23:08 |
| blueCmd | oh! great, thanks a million! | 23:10 |
| --- Log closed Wed Apr 30 00:00:27 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
