IRC logs for #openrisc Saturday, 2015-01-24

--- Log opened Sat Jan 24 00:00:10 2015
olofkShould we recommend the musl toolchain over uClibc?05:53
olofkAny differences worth knowing?05:54
olofkblueCmd: Is this still valid?
olofkstekern, poke53282, blueCmd: And this?
olofkWould be good to have this page in shape for GSoC09:10
stekernat least no work have been done on VDSO09:30
stekernolofk: I say we should promote musl over uclibc, both for general reasons and openrisc specific ones09:47
olofkstekern: (musl) I assumed that and mentioned that on the build instructions page. Haven't put up info on how to build it yet though10:59
stekernit's pretty simple11:12
stekernbasically just a ./ in musl-cros11:12
olofkDoes the official one work, or should we use your fork?11:25
olofkI put up a gcc snapshot on the opencores ftp btw11:26
stekern works but you have to configure it to use our musl-4.9.x gcc repo11:27
olofkSo just set GCC_URL and GCC_EXTRACT_DIR before running then?11:30
olofkhmm.. where is fetchextract defined? Need to check if it handles ftp addresses with username/password11:32
olofkHave you seen that we got spam on the opencores ftp btw? :)11:32
olofkI don't want to remove it in case it triggers more activity11:33
stekernyou can take a look at the config in my repo11:34
olofkhmm.. getting an archive through github seems like a better choice than the opencores ftp11:36
olofkDo we still want to use the 4.9.0 tag, or is head of or1k branch better?11:36
olofkSame for kernel version. 3.15 or latest?11:38
olofkand musl itself.11:39
olofkOh well. I'll play around a bit11:39
stekernyou should use the musl-4.9.1 branch11:42
stekernbecause I have already applied the musl specific gcc patches to that11:43
stekernusing or1k and letting musl-cross apply the patches might work too though, never tried that though11:43
olofkhmm... what should go in and what should be in
olofkAh, I shouldn't need to touch at all11:47
olofkBuilding now12:03
olofk...still building12:26
olofkcool. it worked. Time to fire up jor1k and test my compiled test program13:59
olofkIs uploading extremely slow?14:03
olofkAnyway, it builds fine and I can compile programs using musl-cross from and these additions to
olofkAnd a statically linked binary runs on jor1k, so I'm considering this fully verified now14:08
olofkblueCmd: Do you have any glibc build instructions?15:05
olofkI still think it's funny that the page on the OpenRISC wiki that was least recently modified is "News" :)15:38
poke53282olofk: I have ported libffi and it is in the official repository.16:59
poke53282So, this entry is not longer valid16:59
poke53282Also I think, that we should probote over libc17:00
poke53282Also I think, that we should promote musl over uclibc17:01
Me1234What happened to or1k.debain.net17:28
Me1234OK, I just wrote the url uncorrectly17:42
poke53282musl porting is in principle finished. No feature is missing and it is tested more.17:42
poke53282So this is a better choice currently for the official toolchain.17:43
olofkpoke53282: Cool. I have updated the GNU toolchain page with musl build instructions and mention that it's preferred over uClibc18:10
olofkAnd I'll remove the libffi item from future work18:10
olofkHas anyone tried to build gobject-introspection for or1k? blueCmd?19:12
olofkThere's a package on at least19:13
poke53282I guess building works. But I don't think, anyone has tested it yet.19:18
olofkThat could be done with a small python script that tries to import something from gi.repository I guess19:21
olofkDoes anyone have a OpenRISC-based Debian available?19:21
poke53282The libffi version, which blueCmd compiled is the incomplete libffi implementation.19:35
poke53282So any test would be useless19:35
olofkAnd gobject-introspection depends in libffi?19:35
poke53282I guess19:35
olofkSo what's the status of libffi then? Do we have or1k-specific stuff that we should send upstream?19:36
poke53282Yes, but the debian version of bluecmd contains an old version.19:37
poke53282It is already upstream19:37
poke53282I am not sure, if debian has updated to the newest libffi version yet. But I guess not.19:39
olofkah cool. Have they done a new release with all the patches? I assume that we only need a packaged new version then19:39
poke53282libffi 3.2.119:39
olofkatgreen seems to be quite busy. His Moxie design has pretty good software support :)19:39
poke53282you should follow the chat a little more intensive ;)19:40
olofkI'm trying, but you're talking all the time :)19:41
olofkoh.... "libffi was originally written by Anthony Green"19:42
olofkSo yeah, I guess it's not that strange that libffi supports the Moxie CPU :)19:43
poke53282But I wish libffi would be more widely used19:51
poke53282There are a lot of program, which have their own implementation.19:51
poke53282blueCmd: I think, that I found a severe error in your atomic load and store implementation in QEMU.21:23
blueCmdpoke53282: oh, exciting!21:23
poke53282you save the value in some stack variables. But this aren't pointers.21:25
blueCmdtA should be an address surely21:26
poke53282Ahh, sorry. The variables are only some handles for the real memory address21:27
blueCmdright, I think so21:27
blueCmdit was a while ago, but this is code that is defies your normal way of following code execution, since it's only being generated21:28
olofkAre there any good docs for how to set up and run an OpenRISC system with qemu?21:47
poke53282for user mode emulation there is one on the or1k debian page and in my wiki.21:50
poke53282For a system, I am not sure.21:51
olofkWhat's the difference?21:51
poke53282User mode emulation. In this mode, QEMU can launch processes compiled for one CPU on another CPU. It can be used to launch the Wine Windows API emulator ( or to ease cross-compilation and cross-debugging.21:53
olofkok, what I'm thinking of mostly to setup a base system and create a stage1 gentoo from that, so I guess that both user and system would work for me21:56
poke53282you can start you statically compiled binary directly21:56
poke53282Well, I ask blueCmd since half a year, that he fixex his glibc to be able to boot Debian.21:57
poke53282gentoo stage 1 should work.21:57
poke53282At least as chroot environment21:58
olofkIt looked pretty straight-forward
blueCmdpoke53282: "fixes"? you mean rebuild the debs?21:58
olofkThey do mention that I need glibc. Is that not working at all, or just some problem with the debian version?21:58
poke53282It seems to be incomplete.21:59
blueCmdpoke53282: it's not trivial, there has been no "good" release, and I didn't feel I had time to work more on that. sorry, but at the time I was wroking like 60h a week on it, it was killing me.21:59
olofkI wonder if I could get away with musl. I've seen other gentoo derivatives using musl21:59
poke53282alpine linux is my goal after I finish the qemu project.22:00
poke53282This is based on musl.22:00
poke53282and my guess is, that around 50% of the packages should compile22:01
olofkblueCmd: Yeah, you've been doing a lot of great stuff. I just hope that we can find someone with a little time to do the last bits22:01
poke53282a chroot works. So a gentoo stage 1 build might work as well.22:02
olofkpoke53282: I'm not sure I understand where the chroot comes into the picture22:03
poke53282in the QEMU user mode emulation..22:03
olofkblueCmd explained this to me last year, but I have forgotten the details22:03
poke53282And I have send you a link a few minutes ago.22:04
olofkpoke53282: Sorry. I only read the introduction. I'll read the rest too22:04
poke53282the user mode eumlation is only an translator from or1k code to x86 code.22:05
poke53282No device is emulated22:05
poke53282no tlb.22:06
poke53282no mmu22:06
poke53282no interrupt22:06
poke53282no timer22:06
olofkAnd all calls to the kernel goes to my host kernel too, right?22:06
blueCmdolofk: well, there is no "last bits" :P22:06
olofkblueCmd: Ah ok. I was thinking about the gcc stuff22:07
blueCmdolofk: ah, well GCC is close22:07
olofkpoke53282: How is it going with qemu btw? Are you and git friends again?22:27
poke53282I understand better, what's going on.22:29
poke53282Especially the nature of conflicts and how git tries to solve it.22:29
poke53282I have two patches ready for upstream.22:29
olofkGreat! Do you expect more patches after that?22:30
poke53282Yes, much more22:30
poke53282But I want to do it step by step.22:30
olofkSounds like a good idea22:30
poke53282Well, we had already patches a year ago.22:30
poke53282And some of them were accepted.22:30
poke53282However the most important ones were not accepted.22:31
poke53282I will send the patches to blueCmd. He needs to approve them.22:32
olofkNot accepted? Why?22:33
poke53282Are in principle simple stuff.22:33
poke53282But for two months I didn't manage it, to correct them.22:33
poke53282And then I had to rebase and got tons of errors.22:34
poke53282So I waited and waited and .....22:34
poke53282They didn't understand the awesomeness of the patches.22:35
olofkSo you got hurt and started working on a doomsday machine to one day show them that they were wrong to reject the patches?22:39
poke53282Something like that22:40
* poke53282 is laughing evil22:40
olofkWhich also turned out to be the first doomsday machine written entirely in JavaScript :)22:41
poke53282hehe, I have their IP addresses.22:43
poke53282blueCmd: EMail send22:57
poke53282olofk: If I haven't made it clear yet. I don't like Javascript.22:58
blueCmdpoke53282: how much review would you want me to do? it looks OK to me, but I haven't compiled it or compared it to my repo23:03
blueCmdpoke53282: also, thanks for upstreaming this23:04
poke53282No real review. It is just the authorship and the sign-off line23:12
poke53282I checked it against my sysroot.23:12
poke53282your signal patches will be the next ones.23:13
--- Log closed Sun Jan 25 00:00:12 2015

Generated by 2.15.2 by Marius Gedminas - find it at!