| --- Log opened Mon May 05 00:00:34 2014 | ||
| sfa | hi everyone | 02:06 |
|---|---|---|
| sfa | I'm currently trying to create a target system in fusesoc right now for the Mojo board. | 02:06 |
| sfa | It's a Spartan 6 LX9-2 board | 02:07 |
| sfa | As I am working on this, I see that I need to set aside some space for ROM | 02:07 |
| sfa | the board doesn't have any external RAM or Flash. | 02:08 |
| sfa | does this mean that the Mojo board is not suitable unless I add some flash to it? | 02:08 |
| sfa | Also, will Or12k or mor1kx fit on the LX9 chip? | 02:09 |
| -!- FreezingAlt is now known as FreezingCold | 02:54 | |
| stekern | sfa: should be possible to fit it, olofk has a board port in the works with that FPGA | 04:36 |
| stekern | poke53281: I meant 'implementation' wise, considering that the first pentiums already had some 'advanced' techniques that we are not using. Like superscalarity etc. | 04:41 |
| stekern | but I think olofk did some experiments synthesizing mor1kx cappuccino for virtex6, and he got it to 200MHz | 04:45 |
| poke53281 | Yes, that's true. Wondering, what is the most limiting part here. Memory access? TLB? | 05:07 |
| stekern | my guess is that the tests memory footprunt is so small that neither play a big part | 05:09 |
| stekern | *footprint | 05:09 |
| pgavin | stekern: sorry about the mess with the or32 branch | 05:10 |
| pgavin | what I get for trying to do 8 things at a time :) | 05:11 |
| stekern | so, at least for the integer tests, it'd be mostly dependent on how many IPC you can push out ;) | 05:11 |
| stekern | pgavin: no worries, you're quickly responding to them at least ;) | 05:11 |
| pgavin | I try :) | 05:12 |
| stekern | ...and at least (AFAICT) it's not like or1ksim is broken, just the testsuite | 05:13 |
| pgavin | yeah, I think the simulator itself was ok | 05:13 |
| pgavin | I forgot we didn't add the or1knd stuff to the or32 branch | 05:14 |
| stekern | I'm not even sure what's the point of the or32- branch? is it just to run the testsuite with the or32- toolchain? | 05:16 |
| stekern | or are there other differences? | 05:16 |
| pgavin | um | 05:19 |
| pgavin | I think jeremy wants it for some clients he has or something | 05:19 |
| pgavin | not sure | 05:19 |
| stekern | slightly related though, there are a couple of tests (8 or so) in the or1k- branch that fails. I took a brief look at one of them and it seemed related to how the or1k-elf- toolchain built some mul code | 05:20 |
| stekern | do you know anything about that? | 05:20 |
| pgavin | hm | 05:20 |
| pgavin | I'll take a look but I thought it was 100% working | 05:20 |
| stekern | ok, since this is C-code, it *could* of course be a regresion in our gcc too | 05:21 |
| pgavin | ok | 05:22 |
| stekern | (just to make clear, this is completely unrelated to your latest commits) | 05:23 |
| pgavin | I think it might be a gcc regression | 05:26 |
| pgavin | I have the newest commits on or1ksim but the last commit on my gcc tree is about 8 months ago | 05:27 |
| pgavin | and the whole or1ksim testsuite works with that gcc | 05:27 |
| pgavin | although I suppose there may be a big in the testsuite that isn't revealed by the older gcc version | 05:29 |
| pgavin | *bug | 05:29 |
| stekern | ok, I'll dig a bit into this then | 05:30 |
| pgavin | updating my gcc tree now | 05:30 |
| stekern | fwiw, this is the mul.exp log: pastie.org/9141272 | 05:30 |
| stekern | the culprit of the error is the 'll_mulu overflowsexit(0)' iirc | 05:31 |
| pgavin | I'm not sure where that message is coming from | 05:32 |
| pgavin | the 'exit(0)' part is from the simulator | 05:32 |
| stekern | right | 05:32 |
| pgavin | but the rest is weird | 05:32 |
| stekern | it's in testsuite/test-code-or1k/support/support.c | 05:33 |
| pgavin | ok | 05:33 |
| stekern | but that's as far as I've looked at it up until now, no idea what's going wrong there | 05:35 |
| pgavin | I'm rebuilding gcc now, I'll try it out again once it's built | 05:36 |
| stekern | great, thanks | 05:36 |
| stekern | that ll_mulu actually have nothing to do with the test itself (all test cases pass), it's just used to read the timer | 05:47 |
| stekern | and the reason the test fails is that dejagnu is thrown off by the 'll_mulu overflows' | 05:48 |
| stekern | this makes no sense at all... according to the trace output from or1ksim, ll_mulu isn't called at all. and the only call site is in read_timer, but adding printfs in read_timer never prints anything... | 06:48 |
| pgavin | sorry, was afk | 07:07 |
| pgavin | but gcc is compiled | 07:07 |
| pgavin | and or1ksim seems to pass here | 07:07 |
| stekern | hmm, ok | 07:09 |
| stekern | there's a lot of odd things going on here =) | 07:09 |
| pgavin | I used the or1k-elf configuration to build the testsuite | 07:09 |
| pgavin | are you also using or1k-elf? | 07:09 |
| pgavin | or the linux port? | 07:09 |
| stekern | for instance, stuff seems to be compiled with -fPIC | 07:10 |
| stekern | or1k-elf | 07:10 |
| pgavin | I don't think it should be using PIC | 07:10 |
| pgavin | because it's running on bare metal | 07:11 |
| stekern | no, it definitely shouldn't ;) | 07:11 |
| stekern | but it does... I'm on to investigating why | 07:11 |
| pgavin | k | 07:11 |
| stekern | how do you configure or1ksim, just ./configure --target=or1k-elf | 07:11 |
| stekern | ? | 07:11 |
| pgavin | --disable-shared :) | 07:12 |
| pgavin | but that's the only flag | 07:12 |
| pgavin | should probably make that default | 07:12 |
| pgavin | or figure out how to make it not propagate into the testsuite | 07:12 |
| pgavin | I had to add some other stuff to configure to prevent similar problems with other flags | 07:13 |
| pgavin | but PIC is handled specially by autoconf | 07:13 |
| pgavin | erm, automake & libtool I guess | 07:13 |
| olofk | First day on parental leave! Unfortunately it starts with an ear infection and fever | 07:18 |
| olofk | ...and kids really don't like antibiotics :( | 07:19 |
| stekern | yeah, the --disable-shared fixes it | 07:20 |
| pgavin | I think adding AC_DISABLE_SHARED to testsuite/test-code-or1k/configure.ac will fix it | 07:20 |
| pgavin | and will allow a shared libsim | 07:21 |
| pgavin | not that it matters much | 07:21 |
| stekern | no, but it seems 'wrong' to not allow that | 07:21 |
| pgavin | yep | 07:21 |
| olofk | _franck_, stekern: Could someone commit this? I don'thave access to my workstation | 07:22 |
| olofk | ahh.. this = https://github.com/openrisc/orpsoc-cores/pull/57 | 07:23 |
| stekern | pgavin: AC_DISABLE_SHARED in configure.ac seems to fix it, yes | 07:35 |
| pgavin | I was thinking if it were possible to eliminate libtool from the testsuite entirely, that would be best | 07:36 |
| pgavin | I don't know if that's possible though | 07:36 |
| pgavin | but at least that fixes it | 07:36 |
| stekern | I still have a couple of test failures though, e.g. dhry in or1ksim | 07:37 |
| stekern | and the int-* tests in libsim | 07:38 |
| pgavin | yes, I'm getting that too now | 07:38 |
| stekern | ok, but not with your old gcc? | 07:39 |
| pgavin | um | 07:39 |
| pgavin | the old one is gone now :) | 07:39 |
| stekern | =) | 07:39 |
| pgavin | can probably rebuild it, if I can remember the commit I was at | 07:39 |
| pgavin | with --disable-shared on the top configure I get no errors | 07:40 |
| pgavin | I get the errors with AC_DISABLE_SHARED and with no flags to configure | 07:40 |
| stekern | ok, I was just testing with --disabel-shared | 07:40 |
| pgavin | AC_DISABLE_SHARED doesn't seem to be working right | 07:44 |
| stekern | hmm... I still get the errors with --disable-shared | 07:44 |
| pgavin | hm | 07:44 |
| pgavin | did you make clean in between configures? | 07:45 |
| stekern | I did rm -rf * in the build dir | 07:46 |
| pgavin | k | 07:46 |
| stekern | doh... I had some debug printfs left in support.c | 07:47 |
| pgavin | oops :) | 07:48 |
| stekern | ok, now everything passes | 07:48 |
| pgavin | I think the solution is to replace LTLIBRARIES with just LIBRARIES for the testsuite code | 07:52 |
| stekern | ok | 07:56 |
| pgavin | that didn't work | 07:57 |
| stekern | wtf happened... | 07:59 |
| pgavin | still passing fPIC for some reason | 08:00 |
| stekern | _franck__: you applied this, right? https://github.com/openrisc/orpsoc-cores/pull/56 | 08:00 |
| _franck__ | what did I break ? | 08:00 |
| stekern | nothing, I did | 08:00 |
| pgavin | I made a mistake | 08:01 |
| stekern | when I pushed 57, git crashed and now 56 is gone | 08:01 |
| pgavin | heh | 08:02 |
| _franck__ | oups, I'll commit it again | 08:02 |
| stekern | _franck__: wait... let me fix my mess | 08:02 |
| stekern | I'll pick up your branch and then add veprbl's pull request upon that | 08:03 |
| stekern | _franck__: can you check that everything looks like it should now? | 08:06 |
| _franck__ | it looks good | 08:09 |
| stekern | great | 08:09 |
| pgavin | It's like libtool has some sort of conspiracy against disabling fPIC | 08:09 |
| pgavin | I replaced LTLIBRARIES with LIBRARIES and _la_ with _a_ in the makefiles and it's not working | 08:10 |
| stekern | haha | 08:10 |
| pgavin | I think I found something that works, but it's late here now so I'll commit it to the repo tomorrow | 08:29 |
| pgavin | well, it works better anyways | 08:29 |
| pgavin | still have failures | 08:29 |
| stekern | well, at least the work-around with --disable-shared works | 08:48 |
| olofk | I'm considering forking the milkymist repo to add .core files directly there | 08:51 |
| olofk | Then we could just add it as another cores_root in fusesoc.conf | 08:52 |
| olofk | Another idea is to improve handling of repos with multiple cores | 08:53 |
| stekern | ...and the great benefit would be? | 08:53 |
| olofk | Well, currently we can pick cores with the urlprovider, or the githubprovider | 08:54 |
| olofk | The githubprovider will clone the whole repo for every core | 08:54 |
| stekern | I mean, to fork the milkymist repo | 08:54 |
| olofk | There are some nice cores in there | 08:55 |
| stekern | right, I think "Another idea" is how you fix it, and "The first idea" is how you work around it ;) | 08:55 |
| olofk | That is correct :) | 08:55 |
| olofk | A third idea is to clone the repo into a lot of single-core repos | 08:55 |
| olofk | Then I don't have to fix FuseSoC | 08:56 |
| olofk | :) | 08:56 |
| stekern | what if the .cache would just cache 'per' repo? | 08:57 |
| olofk | Yeah, that's basically the "Another idea" :) | 08:58 |
| stekern | yup | 08:58 |
| stekern | but, it doesn't look hard... on the paper at least ;) | 08:59 |
| olofk | No, it should be doable | 08:59 |
| olofk | Just have to make sure it doesn't clash with some ideas I have for versioning | 09:00 |
| stekern | I think that shouldn't be a problem, since the cached version of the whole repo just have to then be a certain version to be a cache 'hit' | 09:01 |
| stekern | that's something we anyway need, since now it'll be a cache hit even if you have changed the repo from which you are pulling the core | 09:03 |
| stekern | so, basically, you can have several versions of the same core in cache | 09:04 |
| olofk | Multiple versions is something that I want support for. | 09:15 |
| olofk | My first gentoo-inspired idea was to just store it under <core_name>-<version> | 09:15 |
| olofk | With checksums or something to test the integrity | 09:16 |
| olofk | But that should probably work fine with multi-core repos as well | 09:16 |
| stekern | yes, I think that simple <core_name>-<version> approach will work pretty well | 09:17 |
| stekern | perhaps <core_name>-<source>-<version> though | 09:18 |
| stekern | because, where I had troubles was when I tried out wallento's multicore stuff, and it wanted to pick the same version, but from a different repo, of mor1kx | 09:19 |
| stekern | checksums seems hard, wouldn't you need to fetch the core to check that then? | 09:20 |
| olofk | Is that a common case, or would it be enough with a fusesoc cache clean? | 09:20 |
| stekern | ...which kinda would defeat the whole purpose of the cache | 09:21 |
| olofk | checksums could perhaps be added in the core file | 09:21 |
| olofk | A sum of all source files | 09:21 |
| olofk | After they have been potentially patched | 09:21 |
| stekern | I don't know if it's a common case, but it for sure can create subtle 'bugs' | 09:22 |
| stekern | (checksums) if you do that, you'd want it to somehow be automated | 09:24 |
| olofk | True... | 09:24 |
| stekern | http://oompa.chokladfabriken.org/openrisc/stats.html | 10:01 |
| stekern | just for fun ;) | 10:01 |
| _franck__ | it says "stekern talks to him/herself a lot" ;) | 10:07 |
| stekern | ;) | 10:10 |
| stekern | I think this was fun: | 10:10 |
| stekern | juliusb is a very aggressive person. He/She attacked others 2 times. | 10:10 |
| stekern | For example, like this: * juliusb slaps his forehead | 10:10 |
| olofk | Do we have any fresh precompiled toolchains? Don't want to torment my poor netbook too much | 11:40 |
| LoneTech | oh, I am unremarkable in the statistics | 11:40 |
| olofk | LoneTech: The statistics only measure quantity, not quality :) | 11:41 |
| autuus | poke53281: could i have a link to you're github repo where you uploaded the nodejs port of openrisc? | 11:48 |
| stekern | olofk: I think the ones we prepared for orconf2013 are the latest | 11:53 |
| olofk | stekern: ah yes. Those should be good enough | 12:11 |
| stekern | blueCmd: I think we should aim to upstream the sim/ dir asap, or is there anything that speaks against that? | 12:28 |
| olofk | I refuse. It's against my religion | 12:39 |
| olofk | But as with all religious matters, my voice can be bought :) | 12:39 |
| stekern | olofk: do you trade it for a beer? | 13:26 |
| olofk | stekern: Good idea. I hadn't realized the extent of my powers | 13:27 |
| olofk | Some part of my internet connection is weird. I have to continously ping some server, otherwise I'm getting an insane latency in my irssi session | 13:30 |
| olofk | Could it be that some part of the connection decides to wait until there is enough data to send/receive? | 13:31 |
| stekern | oh no... I can see where this is going, I can suddenly see fusesoc pull requests being traded for beer as well | 13:31 |
| wallento | olofk: ubuntu 14.04? | 13:48 |
| olofk | wallento: ubuntu 14.04? | 14:10 |
| olofk | wallento: btw, we should get the orconf2014 ball rolling quite soon. Need to confirm the date, and it would be good to know the size of the venue so we can start inviting people | 14:12 |
| sfa | stekern: thanks :) | 14:49 |
| poke53281 | autuus: https://github.com/s-macke/jor1k/tree/nodejs | 15:59 |
| poke53281 | But keep in mind, that I don't get the full speed of node.js yet. It seems very hard to achieve an endless loop that is responsive. Normally you use the function setTimeout with zero waiting time. | 16:08 |
| poke53281 | But the browsers and node.js behave in a different way. | 16:08 |
| autuus | poke53281: ok, is there a link to git yet? | 16:29 |
| skip__ | hi | 16:43 |
| poke53281 | I sent it already: https://github.com/s-macke/jor1k/tree/nodejs | 17:05 |
| poke53281 | the two additional files are in js/nodejs | 17:05 |
| poke53281 | you start it by running jor1k.js with node | 17:06 |
| skip__ | poke53281: did you make jor1k? | 17:07 |
| poke53281 | Yes | 17:10 |
| skip__ | awesome :) | 17:11 |
| skip__ | I'm trying something similar, I'm making a c++ program to do the same | 17:12 |
| skip__ | it gets 200k instructions into linux at the moment, before hitting an exception in a delay slot, have to think how to implement those correctly | 17:13 |
| autuus | okay, cool, thanks! | 17:36 |
| poke53281 | @skip__: I optimized the hell out of the website. I never believed to come that far and even manage 75MIPS. Looks, like you have still a long way to go. | 18:03 |
| poke53281 | delay slots exceptions are a little bit tricky because you have to change the instruction pointer and the SPR registers accordingly. | 18:06 |
| poke53281 | But in C++ you should get at least twice the speed in comparison of my Javascript implementation. | 18:07 |
| _franck_ | stekern: what do you think of moving verilator jtag server files to your verilator_tb_utils core directory ? | 19:05 |
| _franck_ | I mean jtag_vpi.cpp that I would rename jtagServer.cpp | 19:06 |
| stekern | _franck_: sure, that probably makes sense | 19:08 |
| _franck_ | ok, I'll do that | 19:08 |
| blueCmd | stekern: sure, if you feel like it's something that is well-tested and works | 19:21 |
| blueCmd | I haven't used it I think so I don't know | 19:21 |
| blueCmd | olofk: the dates works for me, and it will give me a chance to visit the Munich office | 19:31 |
| stekern | blueCmd: ok, I'll take a look at what kind of changeset it is then. | 19:32 |
| stekern | but I'll prepare this atomic stuff first | 19:33 |
| blueCmd | stekern: thanks x2 | 19:33 |
| stekern | (it touches the sim/ dir, that's why I started think about that) | 19:34 |
| blueCmd | right | 19:34 |
| stekern | any respond on the cgen patch btw? | 19:34 |
| blueCmd | nope | 19:34 |
| stekern | *response | 19:34 |
| stekern | :( | 19:34 |
| blueCmd | I might want to ping the maintainer directly | 19:34 |
| blueCmd | I will do that now | 19:35 |
| stekern | yeah, it's not a very vibrant project | 19:35 |
| stekern | I think they had one commit last year, and it was to update some copyright notices in the ChangeLogs or something like that | 19:35 |
| blueCmd | yep | 19:36 |
| stekern | ...so, if I understand the commit policy to binutils-gdb, we are allowed to push stuff that only touches or1k files without asking permission first. But we should still send a 'heads-up' mail that states what we're about to commit. Right? | 19:41 |
| blueCmd | stekern: right, I think I forgot the latter for the TLS bugfix | 19:47 |
| stekern | In practice, I think the heads-up mail is mostly to our benefit, if we're lucky someone will review and suggest improvements ;) | 19:49 |
| blueCmd | stekern: I would send it after pushing the commit though | 19:50 |
| blueCmd | because when you have made the commit and done "git send-email" you want to push it quickly or you will have merge conflicts in ChangeLog | 19:50 |
| blueCmd | having a changelog is soo weird | 19:50 |
| stekern | hmm, yeah, maybe. both seems to be common practices though, at least that's what my brief browsing through the binutils ml showed | 19:51 |
| blueCmd | for sim/ I would certainly send an email | 19:52 |
| stekern | yes, I think that touches generic files too | 19:53 |
| stekern | but I'm mostly preparing for the atomic patch now | 19:53 |
| stekern | got to write some weird changelog entries ;) | 19:54 |
| blueCmd | hah! | 19:55 |
| skip__ | anyone know how http://git.openrisc.net/cgit.cgi/jonas/linux/commit/arch/openrisc/kernel/head.S?id=13487cb53a4052ec451fbc6c40593ff0b8412316 might have been resolved? | 19:58 |
| stekern | skip__: how do you mean resolved? | 20:00 |
| skip__ | I think I have a similar problem, the two instructions c01beffc: l.jal c01be664, c01bf000: l.ori r7,r20,0x0 | 20:01 |
| stekern | ah, you mean how it was resolved in some buggy implementation that 'borken-mmu' code was for | 20:02 |
| stekern | no idea, it might be from the Jura period | 20:03 |
| skip__ | so in my little simulator, the delay slot instruction has an itlb miss exception, and the tlb is populated, then it returns to the l.jal instruction, but the page for both instructions map to the same tlb set, so it gets stuck at that point | 20:04 |
| stekern | let's walk through your problem instead, and solve that without looking at old buggy implementations ;) | 20:04 |
| skip__ | yes | 20:04 |
| stekern | you mean, they are in different pages, but map to the same tlb set? | 20:12 |
| skip__ | yes :) | 20:13 |
| olofk | What the hell? Firefox autocompletes 'ti' to tithub.com, and what is most amazing of all... that URL doesn't seem to exist | 20:16 |
| blueCmd | olofk: hah | 20:18 |
| olofk | I'm very tempted to register that address now :) | 20:19 |
| stekern | skip__: but, aren't those addresses in your example in the same page? | 20:22 |
| skip__ | that is a good point :) | 20:33 |
| -!- FreezingAlt is now known as FreezingCold | 23:03 | |
| --- Log closed Tue May 06 00:00:36 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!