IRC logs for #openrisc Monday, 2014-05-05

--- Log opened Mon May 05 00:00:34 2014
sfahi everyone02:06
sfaI'm currently trying to create a target system in fusesoc right now for the Mojo board.02:06
sfaIt's a Spartan 6 LX9-2 board02:07
sfaAs I am working on this, I see that I need to set aside some space for ROM02:07
sfathe board doesn't have any external RAM or Flash.02:08
sfadoes this mean that the Mojo board is not suitable unless I add some flash to it?02:08
sfaAlso, will Or12k or mor1kx fit on the LX9 chip?02:09
-!- FreezingAlt is now known as FreezingCold02:54
stekernsfa: should be possible to fit it, olofk has a board port in the works with that FPGA04:36
stekernpoke53281: I meant 'implementation' wise, considering that the first pentiums already had some 'advanced' techniques that we are not using. Like superscalarity etc.04:41
stekernbut I think olofk did some experiments synthesizing mor1kx cappuccino for virtex6, and he got it to 200MHz04:45
poke53281Yes, that's true. Wondering, what is the most limiting part here. Memory access? TLB?05:07
stekernmy guess is that the tests memory footprunt is so small that neither play a big part05:09
pgavinstekern: sorry about the mess with the or32 branch05:10
pgavinwhat I get for trying to do 8 things at a time :)05:11
stekernso, at least for the integer tests, it'd be mostly dependent on how many IPC you can push out ;)05:11
stekernpgavin: no worries, you're quickly responding to them at least ;)05:11
pgavinI try :)05:12
stekern...and at least (AFAICT) it's not like or1ksim is broken, just the testsuite05:13
pgavinyeah, I think the simulator itself was ok05:13
pgavinI forgot we didn't add the or1knd stuff to the or32 branch05:14
stekernI'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
stekernor are there other differences?05:16
pgavinI think jeremy wants it for some clients he has or something05:19
pgavinnot sure05:19
stekernslightly 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 code05:20
stekerndo you know anything about that?05:20
pgavinI'll take a look but I thought it was 100% working05:20
stekernok, since this is C-code, it *could* of course be a regresion in our gcc too05:21
stekern(just to make clear, this is completely unrelated to your latest commits)05:23
pgavinI think it might be a gcc regression05:26
pgavinI have the newest commits on or1ksim but the last commit on my gcc tree is about 8 months ago05:27
pgavinand the whole or1ksim testsuite works with that gcc05:27
pgavinalthough I suppose there may be a big in the testsuite that isn't revealed by the older gcc version05:29
stekernok, I'll dig a bit into this then05:30
pgavinupdating my gcc tree now05:30
stekernfwiw, this is the mul.exp log:
stekernthe culprit of the error is the 'll_mulu overflowsexit(0)' iirc05:31
pgavinI'm not sure where that message is coming from05:32
pgavinthe 'exit(0)' part is from the simulator05:32
pgavinbut the rest is weird05:32
stekernit's in testsuite/test-code-or1k/support/support.c05:33
stekernbut that's as far as I've looked at it up until now, no idea what's going wrong there05:35
pgavinI'm rebuilding gcc now, I'll try it out again once it's built05:36
stekerngreat, thanks05:36
stekernthat ll_mulu actually have nothing to do with the test itself (all test cases pass), it's just used to read the timer05:47
stekernand the reason the test fails is that dejagnu is thrown off by the 'll_mulu overflows'05:48
stekernthis 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
pgavinsorry, was afk07:07
pgavinbut gcc is compiled07:07
pgavinand or1ksim seems to pass here07:07
stekernhmm, ok07:09
stekernthere's a lot of odd things going on here =)07:09
pgavinI used the or1k-elf configuration to build the testsuite07:09
pgavinare you also using or1k-elf?07:09
pgavinor the linux port?07:09
stekernfor instance, stuff seems to be compiled with -fPIC07:10
pgavinI don't think it should be using PIC07:10
pgavinbecause it's running on bare metal07:11
stekernno, it definitely shouldn't ;)07:11
stekernbut it does... I'm on to investigating why07:11
stekernhow do you configure or1ksim, just ./configure --target=or1k-elf07:11
pgavin--disable-shared :)07:12
pgavinbut that's the only flag07:12
pgavinshould probably make that default07:12
pgavinor figure out how to make it not propagate into the testsuite07:12
pgavinI had to add some other stuff to configure to prevent similar problems with other flags07:13
pgavinbut PIC is handled specially by autoconf07:13
pgavinerm, automake & libtool I guess07:13
olofkFirst day on parental leave! Unfortunately it starts with an ear infection and fever07:18
olofk...and kids really don't like antibiotics :(07:19
stekernyeah, the --disable-shared fixes it07:20
pgavinI think adding AC_DISABLE_SHARED to testsuite/test-code-or1k/ will fix it07:20
pgavinand will allow a shared libsim07:21
pgavinnot that it matters much07:21
stekernno, but it seems 'wrong' to not allow that07:21
olofk_franck_, stekern: Could someone commit this? I don'thave access to my workstation07:22
olofkahh.. this =
stekernpgavin: AC_DISABLE_SHARED in seems to fix it, yes07:35
pgavinI was thinking if it were possible to eliminate libtool from the testsuite entirely, that would be best07:36
pgavinI don't know if that's possible though07:36
pgavinbut at least that fixes it07:36
stekernI still have a couple of test failures though, e.g. dhry in or1ksim07:37
stekernand the int-* tests in libsim07:38
pgavinyes, I'm getting that too now07:38
stekernok, but not with your old gcc?07:39
pgavinthe old one is gone now :)07:39
pgavincan probably rebuild it, if I can remember the commit I was at07:39
pgavinwith --disable-shared on the top configure I get no errors07:40
pgavinI get the errors with AC_DISABLE_SHARED and with no flags to configure07:40
stekernok, I was just testing with --disabel-shared07:40
pgavinAC_DISABLE_SHARED doesn't seem to be working right07:44
stekernhmm... I still get the errors with --disable-shared07:44
pgavindid you make clean in between configures?07:45
stekernI did rm -rf * in the build dir07:46
stekerndoh... I had some debug printfs left in support.c07:47
pgavinoops :)07:48
stekernok, now everything passes07:48
pgavinI think the solution is to replace LTLIBRARIES with just LIBRARIES for the testsuite code07:52
pgavinthat didn't work07:57
stekernwtf happened...07:59
pgavinstill passing fPIC for some reason08:00
stekern_franck__: you applied this, right?
_franck__what did I break ?08:00
stekernnothing, I did08:00
pgavinI made a mistake08:01
stekernwhen I pushed 57, git crashed and now 56 is gone08:01
_franck__oups, I'll commit it again08:02
stekern_franck__: wait... let me fix my mess08:02
stekernI'll pick up your branch and then add veprbl's pull request upon that08:03
stekern_franck__: can you check that everything looks like it should now?08:06
_franck__it looks good08:09
pgavinIt's like libtool has some sort of conspiracy against disabling fPIC08:09
pgavinI replaced LTLIBRARIES with LIBRARIES and _la_ with _a_ in the makefiles and it's not working08:10
pgavinI think I found something that works, but it's late here now so I'll commit it to the repo tomorrow08:29
pgavinwell, it works better anyways08:29
pgavinstill have failures08:29
stekernwell, at least the work-around with --disable-shared works08:48
olofkI'm considering forking the milkymist repo to add .core files directly there08:51
olofkThen we could just add it as another cores_root in fusesoc.conf08:52
olofkAnother idea is to improve handling of repos with multiple cores08:53
stekern...and the great benefit would be?08:53
olofkWell, currently we can pick cores with the urlprovider, or the githubprovider08:54
olofkThe githubprovider will clone the whole repo for every core08:54
stekernI mean, to fork the milkymist repo08:54
olofkThere are some nice cores in there08:55
stekernright, I think "Another idea" is how you fix it, and "The first idea" is how you work around it ;)08:55
olofkThat is correct :)08:55
olofkA third idea is to clone the repo into a lot of single-core repos08:55
olofkThen I don't have to fix FuseSoC08:56
stekernwhat if the .cache would just cache 'per' repo?08:57
olofkYeah, that's basically the "Another idea" :)08:58
stekernbut, it doesn't look hard... on the paper at least ;)08:59
olofkNo, it should be doable08:59
olofkJust have to make sure it doesn't clash with some ideas I have for versioning09:00
stekernI 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
stekernthat'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 core09:03
stekernso, basically,  you can have several versions of the same core in cache09:04
olofkMultiple versions is something that I want support for.09:15
olofkMy first gentoo-inspired idea was to just store it under <core_name>-<version>09:15
olofkWith checksums or something to test the integrity09:16
olofkBut that should probably work fine with multi-core repos as well09:16
stekernyes, I think that simple <core_name>-<version> approach will work pretty well09:17
stekernperhaps <core_name>-<source>-<version> though09:18
stekernbecause, 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 mor1kx09:19
stekernchecksums seems hard, wouldn't you need to fetch the core to check that then?09:20
olofkIs 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 cache09:21
olofkchecksums could perhaps be added in the core file09:21
olofkA sum of all source files09:21
olofkAfter they have been potentially patched09:21
stekernI 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 automated09:24
stekernjust for fun ;)10:01
_franck__it says "stekern talks to him/herself a lot" ;)10:07
stekernI think this was fun:10:10
stekernjuliusb is a very aggressive person. He/She attacked others 2 times.10:10
stekernFor example, like this: * juliusb slaps his forehead10:10
olofkDo we have any fresh precompiled toolchains? Don't want to torment my poor netbook too much11:40
LoneTechoh, I am unremarkable in the statistics11:40
olofkLoneTech: The statistics only measure quantity, not quality :)11:41
autuuspoke53281: could i have a link to you're github repo where you uploaded the nodejs port of openrisc?11:48
stekernolofk: I think the ones we prepared for orconf2013 are the latest11:53
olofkstekern: ah yes. Those should be good enough12:11
stekernblueCmd: I think we should aim to upstream the sim/ dir asap, or is there anything that speaks against that?12:28
olofkI refuse. It's against my religion12:39
olofkBut as with all religious matters, my voice can be bought :)12:39
stekernolofk: do you trade it for a beer?13:26
olofkstekern: Good idea. I hadn't realized the extent of my powers13:27
olofkSome part of my internet connection is weird. I have to continously ping some server, otherwise I'm getting an insane latency in my irssi session13:30
olofkCould it be that some part of the connection decides to wait until there is enough data to send/receive?13:31
stekernoh no... I can see where this is going, I can suddenly see fusesoc pull requests being traded for beer as well13:31
wallentoolofk: ubuntu 14.04?13:48
olofkwallento: ubuntu 14.04?14:10
olofkwallento: 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 people14:12
sfastekern: thanks :)14:49
poke53281But 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
poke53281But the browsers and node.js behave in a different way.16:08
autuuspoke53281: ok, is there a link to git yet?16:29
poke53281I sent it already:
poke53281the two additional files are in js/nodejs17:05
poke53281you start it by running jor1k.js with node17:06
skip__poke53281: did you make jor1k?17:07
skip__awesome :)17:11
skip__I'm trying something similar, I'm making a c++ program to do the same17: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 correctly17:13
autuusokay, 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
poke53281delay slots exceptions are a little bit tricky because you have to change the instruction pointer and the SPR registers accordingly.18:06
poke53281But 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.cpp19:06
stekern_franck_: sure, that probably makes sense19:08
_franck_ok, I'll do that19:08
blueCmdstekern: sure, if you feel like it's something that is well-tested and works19:21
blueCmdI haven't used it I think so I don't know19:21
blueCmdolofk: the dates works for me, and it will give me a chance to visit the Munich office19:31
stekernblueCmd: ok, I'll take a look at what kind of changeset it is then.19:32
stekernbut I'll prepare this atomic stuff first19:33
blueCmdstekern: thanks x219:33
stekern(it touches the sim/ dir, that's why I started think about that)19:34
stekernany respond on the cgen patch btw?19:34
blueCmdI might want to ping the maintainer directly19:34
blueCmdI will do that now19:35
stekernyeah, it's not a very vibrant project19:35
stekernI think they had one commit last year, and it was to update some copyright notices in the ChangeLogs or something like that19:35
blueCmdyep19:36, 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
blueCmdstekern: right, I think I forgot the latter for the TLS bugfix19:47
stekernIn practice, I think the heads-up mail is mostly to our benefit, if we're lucky someone will review and suggest improvements ;)19:49
blueCmdstekern: I would send it after pushing the commit though19:50
blueCmdbecause when you have made the commit and done "git send-email" you want to push it quickly or you will have merge conflicts in ChangeLog19:50
blueCmdhaving a changelog is soo weird19:50
stekernhmm, yeah, maybe. both seems to be common practices though, at least that's what my brief browsing through the binutils ml showed19:51
blueCmdfor sim/ I would certainly send an email19:52
stekernyes, I think that touches generic files too19:53
stekernbut I'm mostly preparing for the atomic patch now19:53
stekerngot to write some weird changelog entries ;)19:54
skip__anyone know how might have been resolved?19:58
stekernskip__: 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,0x020:01
stekernah, you mean how it was resolved in some buggy implementation that 'borken-mmu' code was for20:02
stekernno idea, it might be from the Jura period20: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 point20:04
stekernlet's walk through your problem instead, and solve that without looking at old buggy implementations ;)20:04
stekernyou mean, they are in different pages, but map to the same tlb set?20:12
skip__yes :)20:13
olofkWhat the hell? Firefox autocompletes 'ti' to, and what is most amazing of all... that URL doesn't seem to exist20:16
blueCmdolofk: hah20:18
olofkI'm very tempted to register that address now :)20:19
stekernskip__: 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 FreezingCold23:03
--- Log closed Tue May 06 00:00:36 2014

Generated by 2.15.2 by Marius Gedminas - find it at!