IRC logs for #openrisc Tuesday, 2014-04-29

--- Log opened Tue Apr 29 00:00:06 2014
--- Day changed Tue Apr 29 2014
stekernjuliusb: I think october have been a good time, so we should aim for that I think03:48
stekernblueCmd: so, was that the complete fix for the TLS stuff?03:49
stekernerr, nm03:50
stekernwait until I have got some coffee...03:50
stekernblueCmd: 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
stekernI 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 you05: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
juliusbolofk_: I am indeed back. a teleconf is a good idea07:08
juliusbstekern: October sounds good07:08
wallentojulisb: thanks07:09
wallentoregarding ORCONF2014 I think we can host it in Munich next time07:09
stekernwallento: that sounds great07:12
wallentowe 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 time07:13
wallentoits September 20 to October 507:14
wallentoORCONF 2013 was October 5 and 607:14
stekernyes, I think clashing with Oktoberfest should be avoided07:15
juliusbSounds like a good idea. As long as there is *some* beer left over in Munich for us, then that'll be fine :)07:37
stekernso, that would make october 11-12 a potential date07:42
juliusbyep, that'd work for me07:43
wallentosame here, there is always enough beer in Munich ;)07:44
olofk_juliusb: Hey, shouldn't that be ? ;)07:50
blueCmdstekern: 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
juliusbbrilliant olofk_ 07:51
olofk_But feel free to ignore anything I say. It's not like it's my birthday or anything...07:51
blueCmdfor 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 priority07:51
juliusbhmm, you might say that even if it wasn't...07:51
juliusbbut, possibly it is! is it?07:51
olofk_Yes! :)07:52
juliusbwell happy birthday mate!07:52
stekernblueCmd: yes, I remember, all came back to me after I had got some coffe ;)07:52
olofk_hmm... this web chat client is strange07:54
blueCmdwallento: wow! ive been dreaming of multicore openrisc07:55
stekernhappy birthday olofk_07:55
blueCmdlets get that a stable thing, really awesome!07:55
blueCmdolofk_: gz! :D07:55
olofk_stekern: Thank you. It feels like I have lived for 100000 years today07:55
wallentoblueCmd: bad dreams? ;)07:57
wallentospeaking 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 top07:59
blueCmdwallento: no! :) I would be delighted to help implement this in or1ksim and linux07:59
blueCmdoh, that could be cool as well08:01
blueCmddo you have anything in mind with it?08:01
wallentoit's for a research project here08:04
stekern(fiasco) that sounds interesting08:05
wallentoI 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 SMP08:07
blueCmdneither do I, which is what's exciting :)08:09
blueCmdso. stekern, should we upstream newlib as well? does it make any sense?08:11
blueCmdand libgloss maybe?08:12
stekernI think a lot comes "for free" from underlying structures, but there's definitely work that needs to be done.08:12
stekernand it's not like SMP Linux is an uncommon thing, so there's loads of examples from other archs to take from ;)08:14
wallentoI would also think so08:14
blueCmdyeah,  like TLS08:15
blueCmdhaha, hopefully not08:15
blueCmdTLS is implement differently everywhere, I suspect SMP might be as well08:15
blueCmdtime to go to work08:15
stekernI'm very interested in running SMP Linux as well, so count me in on the collaboration on that.08:16
wallentoproblem is a bit on the simulator/emulator side08:16
wallentoi work on mor1kx cache coherency08:16
wallentobut doing this in qemu or or1ksim is challenging I believe08:17
stekernyeah, I don't know if it'd even make sense to do it in qemu08:18
stekernor1ksim is another story08:18
wallentowe had some archc/systemc simulator work before, but it turned out to be a dead end08:20
wallentoi did some work on or1ksim before (~2009)08:21
stekernI recall that08:21
wallentomaybe I can get a student to take this up and work on some basic coherency mechanism08:21
wallentoas or1ksim is an instruction set simulator, doing this should be easy, just doing direct manipulation from one cache to the other08:22
stekernthat'd be great I think08:23
blueCmdin userspace qemu, no that doesn't make any sense08:40
blueCmdI don't know if we have full system emulation in qemu08:40
blueCmd(if we do, I need to look at it ASAP :P)08:40
olofk_wallento: How about using verilator?08:42
wallentoyes, thats what we do at the moment08:42
wallentoand what i prefer08:43
wallentoi just mean in a sense of not making further parts of OpenRISC unusable in the long term08:43
olofk_ah ok08:43
wallentoi don't know, how many people use what08:44
jungmaey guys, I have a whishbone to TLM2.0 Transactor ready, to use it with a verilated OR ...  where can I upload this?08:44
wallentodoes anybody have an overview? even for me, who somehow understands wide parts of openrisc, it is entirely confusing at the moment08:44
wallentoqemu, mor1kx, or32, or1k, linux, or1ksim and all this..08:45
jungmawallento: yes :)08:45
wallentonot to speak where to find was08:45
jungmaits indeed confusing08:45
olofk_jungma: Cool. I would like to take a look at it and see how we can fit it into FuseSoC and orpsoc-cores08: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
jungmaolofk_: 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 it08:49
wallentoyeah, 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 version08:50
wallentoon some wiki subpage08:50
stekernagreed, we try to centralize information here:
stekernbut, admittedly, the situation is suboptimal to say the least08:52
wallentoi know, but i think it needs a distinction between users and developers i think08:52
wallentothat can also make the wiki simpler i think08:53
stekernright, that's probably true08:54
wallentoso that people that want to "try out" OpenRISC have a starting point without understanding everything08:54
wallentolike the upper part on the landing page08:54
wallentobut once you click on GNU toolchain..08:55
stekernheh, yeah... as I said, the problem is known...08:55
wallentoonce I got my mor1kx work done, I will try to assemble something as such08: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
stekernthat'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
stekerna musl port in the works09:04
stekernmultiway caches for mor1kx09:05
blueCmdolofk_: glibc was ported last year :)09:20
blueCmdfor the community page, I still think a media wiki on would be better09:21
stekernI think the content off the media wiki might be more important than the location ;)09:28
blueCmdstekern: sure, but it's a pain to edit stuff currently IMO09:29
stekernperhaps, but why would another media wiki make it easier?09:30
wallentoprincipally i think: wiki can be edited by anybody and is edited by nobody or somebody once09:30
wallentobut 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
blueCmdstekern: 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 confusing09:33
blueCmdit also contains a lot of old stuff, but that's just cleanup job away09:34
jungmai 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 instructions09:34
stekernblueCmd: your points are also fair, I agree on all three09:35
blueCmdjungma: yes, MediaWiki allows you to create really nice frontpages I think09:35
stekern...but, I still think the content is what we should concentrate on first hand09:35
blueCmdI don't see why we cannot do both09:36
blueCmd(I guess concentrating on two things might be a oxymoron)09:36
stekernah, well, we seem to have a hard time to concentrate on one thing at them moment (the content)09:38
jungmathe problem is, that wikis get automatically outdated, if nobody takes care about the content09:38
stekernand, 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
blueCmdstekern: it is? oh my god what have they done with it! :)09:41
stekernpersonally, I wouldn't mind the entry page being at though09:41
blueCmdbut it makes sense, it's not the markup I'm afraid of - it's the execution09:42
stekernbut 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
jungmathe problem is, as a new user i go to and i see this:09:43
jungmaLast updated 2012-01-04 20:50:22 CET09:43
jungmaand then i think the project is dead09:44
jungmasame counts for this page:
jungma SVN Updated: Feb 24, 201109:45
jungmamaybe redirect to this opencores wiki and start editing the content there...09:46
blueCmdstekern: would you mind removing and forking instead ?09:47
stekernnot at all09:47
stekernI think you can create the or1k-glibc yourself though09:47
wallentofor the first I will try to assemble this:
wallentofeel free to complete :)09:48
stekernI'll remove the or1k-eglibc though09:48
blueCmdI'm just a member, not an owner so I don't think I can09:48
blueCmdah right,, maybe I can create09:48
stekernit's intended that you can09:48
blueCmdI was focusing on the destruction09:48
stekernhaha, be creative, not destructive ;)09:48
blueCmdit worked09:48
jungmathis is a cool example for a landing page:
stekernit'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 their09:50
blueCmdhm, is 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 content10:00
stekernwallento: that looks good, and should be relatively easy to maintain10:00
olofk_It's already confusing enough with, and I really really don't want to move information around without a solid plan10:00
olofk_But I agree that the stuff on OpenCores is ugly10:00
olofk_But let's move it when we have something more solid then10:01
olofk_Because every new location we use to host additional stuff tends to be outdated quite soon10:01
olofk_New people seem to notice the guides at or Kevin Mehall's stuff first10:03
olofk_Both guides are already slightly outdated10:03
_franck_web_that's why there should be only one. Others, old ones,  might redirect to the new one10:03
olofk__franck_web_: Speaking of which, could you update your elec4fun article to mention FuseSoC instead of ORPSoC :)10:04
stekernhaha, burn!10:05
_franck_web_danm, should have closed my big mouth :)10:07
jungmaso if you need help designing a cool state-of-the-art landing page don't hesitate to ask ;)10:33
amscat /dev/random > index.html10:34
jungmathis might have mor information than the current pages :D10:35
stekernolofk_: we've got to come up with a way for the cache to realise that it should be invalid when the provider is changed11:37
stekernwallento: 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
wallentono, but i can check it11:54
wallentoit runs, but the trace monitor does not work, a quick hack of course.. I will check it11:58
wallentoah, it is not there :)11:59
wallentoverilator simulation seems different from verilog simulation12:01
stekernI can poke around it bit if you don't have a burning desire yourself ;)12:07
stekern*a bit12:07
stekernit looks cool with 2 mor1kx instances in gtkwave at least =)12:08
wallentoi am nearly finished with a dirty hack12:10
stekernwallento: ah, only l.nop 4 putc works(?)12:23
wallentoi see12:23
stekernI added a hack in tb.cpp to print those for cpu0 and then I got output12:23
wallentoi will commit a small trace monitor in a few minutes12:23
wallentofor both12:23
stekernI didn't gate it on any stall signals, but:
stekernis the uart disabled on purpose?12:29
wallentonot really, did not understand at first glance ;)12:29
wallentothe double characters are from top->wb_clk_i = !top->wb_clk_i;12:30
stekernok... 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
wallentoBefore using uart, you need to lock printf accesses12:31
wallentoi 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
stekernyes, 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 instead12:32
stekern(lock uart_putc) ok, yeah, that makes sense12:35
stekernI thought that was already done, but for l.nop 4 you can of course ignore that issue12:36
wallentoyou can update orpsoc-cores on multicore-demo12:36
wallentoin my project we essentially do everything via the traceport12:36
stekernI see ;)12:36
wallentoso, push finally worked12:38
wallentodon't judge me by this commit ;)12:40
wallentoI also adopted the instructions:
stekernyeah, I saw the commit. I actually have a similar hack (but for single core) locally here12:42
stekernin the mor1kx-generic system12:43
stekerncombining and cleaning up both our hacks and it's probably something we should commit ;)12:44
wallentoyes, definetely :) I have something similar lying around, I will search for it later12:44
stekernbut otoh, with the synthisizable trace monitor they might be both be redundant12:45
wallentoi think you can do a lot more in simulation as for example with mor1x_monitor12:45
stekerntrue, and it's a lot easier to hack in some debug stuff in tb.cpp than in rtl12:50
wallentoasciinema, nice one12:57
wallentonever heard of it12:57
olofk_wallento: I like this line in your build scripts :) wget -O hello.c13: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 FuseSoC13:05
stekernolofk: yes, with the l.nop 4 support wallento 'hacked' into his tb.cpp it works fine with verilator14:49
stekernolofk, _franck_: does this ring any bells?
stekernseems like tries to create the .h file before the self.sim_root is created16:09
stekernerr, scratch that...16:14
blueCmdstekern: 201 references to __sync and 3 to __atomic in the packages that are failing to build currently16:16
stekernblueCmd: about time to add support for them then ;)16:42
blueCmdstekern: as soon as you're done with the specification :)16:46
stekernah... well, I'd say what you need for that is already 'set in stone'16:57
stekerni.e the instruction names and encodings16:57
stekernand implementation16:58
stekernwhat's left is to paint it octarine16: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
stekernwith older ones, I think it's pre-xml and set $pc= et al support17:01
stekern'with older ones' I meant... a lot of kids running around me right now... bbl17:04
stekernbah, that just got even more confusing... let me try again =)17:07
stekernand when I say older ones, it's a version 'pre-xml' and 'set $pc=' support17:09
blueCmdstekern: ack!17:14
stekern_franck_: scratch that, now the new one works too...17:27
blueCmdstekern: you will have to upstream your atomics in binutils ASAP if I'm gonna start building packages with it though :)17:29
blueCmdsince I'm using a nice and clean binutils straight from the upstream now17:30
blueCmdstekern: 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 address18:04
blueCmdI think my coreutils might be broken18:05
blueCmdyep, downgrading it worked18:06
blueCmdstekern: when you built gstreamer, did you do anything special then?18:53
blueCmd fails18:53
blueCmdyep, a patch is needed - hack build it is :)19:33
stekernyeah, all sorts of voodoo and hoodoo iirc...19:34
blueCmdthis is clearly production ready for space19:35
stekernit's there if you want to grab it19:37
stekernah, right... the patch needed is actually in newer versions of that package19:40
stekern(upstream atomic patch) don't worry, I will19:45
blueCmdstekern: ah right, I'm building it currently - thanks anyway (gstreamer)20:07
stekernyeah, it wasn't as much voodoo involved as I remembered. xaw3d was the tricky one (due to xutils-dev)20:08
blueCmdstekern: review please:
blueCmdI'm a bit worried about the million tmp RTXs20:11
blueCmdbut they're needed and I cannot create them inside the switch20:12
blueCmdgiving them a more meaningful name is also hard20:12
stekern'inside the switch' <- I don't get that?20:13
stekerncoding style nit on 16 and 21, missing space before (20:16
blueCmdgcc was very angry if I moved the declaration of the variables to the case: context20:16
stekerneven with: case: contex { rtx tmp; tmp = gen_reg_rtx (Pmode); break }20:17
blueCmdI cannot sweat I used the {}20:18
stekernwithout it I can swear it will not work ;)20:18
blueCmdI'll try20:18
blueCmdah, ok20:18
blueCmdI don't get the bracket indentation in gcc, it's weird20:19
stekerngnu coding style is barock all over20:19
stekernyou've got the brackets wrong on 18 and 22 now when you mention it20:20
blueCmdyes, I'm fixing that - thansk20:21
stekernuse emacs and do c-set-style gnu is easiest way to get it right I think20:21
blueCmdemcas is not easy :)20:24
blueCmd PTAL20:24
_franck_or you can use "indent"20:25
_franck_without any parameter, it default to gnu C style20:25
stekernemacs is easy, you type in text and it appears on screen, how hard is that? =)20:26
stekernvi is a lot harder, you have to find the magic 'i' key before text starts appearing on the screen20:27
blueCmdhah, vim <320:28
stekernyeah, when I say vi, I usually mean vim20:29
blueCmda lot of people that say they use vi, put infront of vi and not vim will be very very lost :P20:30
stekernhaha, true20:30
blueCmdI just spotted that ncurses built from my old pre-Debian toolchain is compiled like:20:31
blueCmdor1k-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 tset20:32
blueCmdnotice anything?20:32
stekernwe had a admin at the university I attended that insisted on only installing vi (no m) on the *nix servers20:32
stekern"why? that's the only editor you'll ever need" was his response when someone requested something else.20:33
stekernI see a _FILE_OFFSET_BITS=6420:34
blueCmdwhich is a relief20:34
blueCmdbecause it means that it is not set in glibc but in the app20:34
stekernright, that's what I said the other day, without realising the meaning of it20:35, doesn't that mean that pkg-config does *not* define that?20:37
blueCmdstekern: yes, this supports that20:37
blueCmdstekern: or that it uses a library that doesn't20:37
stekernI'll check what happens in my readdir test cases if I define it20:37
stekern   10b8:       04 00 6e 9f     l.jal 1cb34 <__readdir64>20:43
stekernhow silly that I didn't figure that out...20:44
stekernat least everything falls into place now how the define-magic in glibc works, and things make a lot more sense20:48
stekernonly thing left to do to close that whole chapter is to figure out where/why some things are compiled without that define20:53
stekernbecause, you saw it somewhere else than in pkg-config, right?20:53
blueCmdyes, apt-key20:54
stekern# apt-key20:56
stekernrun-parts: failed to open directory /etc/apt/trusted.gpg.d: Value too large for defined data type20:56
stekernwell, apt-key is a script20:58
stekernthat (not so surprisingly) runs run-parts21:01
blueCmdan right21:01
blueCmdso I guess run-parts doesn't like it :)21:01
stekern...or no, it doesn't21:02
blueCmdnow.. so where are these __sync supposed to be implemented?21:03
blueCmd seems to be arm64's patch to support it21:08
blueCmd mips seems quite close to what we have21:11
stekerndoesn't look completely trivial...21:13
blueCmdwell MIPS doesn't look too bad21:13
blueCmdwe could implement it using libgcc, but I much prefer if it could be implemented in gcc builtins21:14
blueCmdm68k uses libgcc apparently (since they use syscalls)21:14
blueCmdI might want to revise that statement..21:17
blueCmdthis is the new they are using:
blueCmdlook at atomic_compare_and_swap21:18
blueCmdwe 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 mips6421:19
blueCmdthe first patch looks simpler, I'll use that as guide I think21:21
stekernyes, it's probably best to just start in one end and try to go for the simplest solution possible21:21
stekern_franck_: there _is_ some fishy stuff going on with debugging21:22
stekernwith single stepping21:22
_franck_I know that strange things  happened sometimes. It's on my todo list21:23
stekernsometimes (it seems to be 'session' bounded) a si will just set the target of running21:23
_franck_we can know debug this pretty easily with jtag_vpi and mor1kx_generic21:23
stekerni.e. it never stalls21:23
stekernright, do you want to guide me a bit through that?21:24
_franck_let's try it21:24
_franck_that's what I replied to some guy who was asking some help21:26
blueCmdstekern: it failed to generate docs, I might just use your dpkgs21:26
blueCmdfor gstreamer21:26
_franck_stekern: Edit ./tcl/board/or1k_generic.cfg and change set set TAP_TYPE VJTAG to21:26
_franck_TAP_TYPE MOHOR.21:26
_franck_is no longer needed21:26
_franck_you can do -c "set TAP_TYPE MOHOR"21:27
stekernblueCmd: I think it failed at first for me too21:27
blueCmdstekern: yeah, I just don't want to mess around with it :P21:27
blueCmdright now21: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
blueCmdstekern: now the trojans and viruses you put there is included21:29
stekernmy paycheck from NSA will be a big one this month21:30
stekern_franck_: but, that's for icarus, what you pasted. right?21:31
_franck_it is21:31
stekernwell, I can try with that for starters21:32
_franck_Jose T. de Sousa did some work to make it work with Verilator:21:33
stekernyeah, well, I can't get that repo to compile at all with verilator with the current fusesoc21:36
_franck_mor1kx_monitor.v:42: Include file test-defines.v not found -->  this is new, I didn't have this before21:36
_franck_I discovered that while doing my neek port21:36
_franck_it it that broken ?!21:36
_franck_let me try21:37
stekernthe directory /home/stefan/openrisc/orpsocv3/build-jjts/build/de0_nano_sim/sim-verilator/bench/verilator/ doesn't exist when it tries to write that file21:38
stekernI think the problem is that the 'filename' is bench/verilator/orpsoc-defines.h21:38
stekernand bench/verilator is non-existing21:39
stekernok, I need to build openocd with jtag_vpi support too21:42
blueCmdwho needs norwegian?21:44
blueCmd swedish is much better21:44
stekern_franck_: what's the ./configure knob for jtag_vpi?21:46
_franck_I guess21:46
stekernlet's try ;)21:47
_franck_./configure --help21:47
stekern$ ./configure --help |grep vpi --enable-jtag_vpi       Enable building support for JTAG VPI21:48
blueCmd"So which version do you have on jackd2?"21:48
blueCmd"Oh, it's the good old"21:48
stekernah, that one I need for scummvm21:49
_franck_stekern: adding the missing test-defines.v file solves the problem21:49
stekernwhich (of all our) problem(s)? =)21:49
_franck_yes all, my car is fixed now too ;)21:50
_franck_well no, I just restart fusesoc and sometimes it starts the sim, sometimes not21:51
_franck_need to look again21:51
stekernoh no... I still have this weird libtool problem with openocd that I haven't figured out..21:51
blueCmdopenocd! 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 things21:53
stekern...add support for reading them via the spr space in mor1kx21:53
stekernthe spr bus is in no way connected to the reg file currently21:53
blueCmdstekern: 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 example21:54
blueCmdright npc works21:54
blueCmdbut reg r10 doesn't21:54
blueCmd(or didn't rather, I don't have the test setup atm)21:54
stekernyes. IRC, the interactive notepad, with automatic save21:55
blueCmdhard to edit stuff though21:55
stekernhah, have you ever seen me do any typos!?!?21:56
_franck_where does "test-defines.v" comes from ?21:59
_franck_I have it locally but can't remember where I found it22:00
stekernit's an old orpsocv2 thing22:00
stekernit's autogenerated there22:00
blueCmdstekern: go to and click the "Build-Attempted" link22:01
blueCmd(the link for that page is huge so I cannot paste it here)22:01
blueCmdthat's a really really nice page, it shows the tail of all the failed packages build logs22:01
_franck_stekern: ok, because bench/verilog/mor1kx_monitor.v includes it22:02
stekernah, nice22:03
blueCmdolofk: 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 stuff22:03
stekern_franck_: -c "set TAP_TYPE MOHOR" doesn't seem to work22:07
_franck_ps2 won't be supported on my neek board :( I would need to get the scope home to see what's going on22:08
stekern...if you put the -c in the wrong place in the command line22:08
_franck_that's what I was about to say :)22:08
stekernotherwise it works perfectly! =)22:08
stekernWarn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1001). Workaround: increase "set remotetimeout" in GDB22:10
stekernI guess that's due to the slowness of the simulation22:10
_franck_do what it says :)22:10
_franck_right, it's because it is slow22:11
blueCmdrunning gdb into a simulation of a CPU is pretty badass22:11
_franck_last time I had or1ksim accessing a register in a RTL simulated design thru openocd22:14
blueCmdnice! :)22:14
_franck_or1ksim can now access real or simulated hardware22:15
_franck_it works with a PIO at least ;)22:15
blueCmdthat could be an awesome thing to support in or1ksim out of the box22: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 thing22:17
blueCmdyes, that would be cool22:18
blueCmdstekern: do you need pulseaudio for scummvm?22:24
blueCmddpkg-deb: building package `pulseaudio' in `../pulseaudio_5.0-1_or1k.deb'.22:26
stekernand libsdl (which depends on pulseaudio)22:27
blueCmddo you know mafm?22:28
blueCmdhe pops in here from time to time and helps me build packages (he probably built the majority of the packages by now)22:28
blueCmdhe just happens to be the maintainer of a lot of sdl packages22:28
blueCmdand he wants to get it running on or1k22:29
blueCmdso that's a great fit :)22:29
blueCmdso sdl-mixer1.2 depends on libmikmod-dev -> libopenal-dev -> libroar-dev -> libao-dev -> pulse22:37
blueCmdlibao is scheduled for build, so maybe that will solve itself (fingers crossed!)22:37
blueCmdargh, right. we need to port libgc as well. and fix __attribute__((destructor)) for krb522:37
stekernwhat's the problem with __attribute__((destructor))22:49
blueCmdit apparently doesn't fire at exit22:49
blueCmdhah, wut?22:50
stekernfire at exit22:50
stekernhmmm, that sounds familiar somehow22:51
blueCmdI had som problems with atexit and stuff when doing glibc, and possibly when doing DWARF222:51
blueCmdthat's a useful one22: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 ./configure22:56
blueCmdatomics are everywhere!22:56
blueCmdor rather needed everywhere22:56
blueCmdi'd better get started on that. fusesoc core api will have to wait22:57
stekernthere I'm saying something about constructors/destructors22:58
stekernno context to what it's about though22:59
stekernbut I'm 100% sure I have investigated some kind of problem related to __attribute__((destructor))23:00
stekerngetting closer23:01
stekernpoke53281: do you remember this?23:02
poke53281Hi stekern23:02
poke53281Yes, we had some problems with the constructors and destructors in C and C++. They were not called.23:03
poke53281because the linker could not find the correct symbols.23:03
stekernah, now it all comes back to me23:03
poke53281I think the problem were really simple. lower case vs. upper case.23:04
stekernblueCmd: <- change those to _init and _fini23:06
poke53281Yes, exactly.23:06
stekernand here's the mail with the rationale behind it:
blueCmdoh! great, thanks a million!23:10
--- Log closed Wed Apr 30 00:00:27 2014

Generated by 2.15.2 by Marius Gedminas - find it at!