--- Log opened Sat Jan 24 00:00:10 2015 | ||
olofk | Should we recommend the musl toolchain over uClibc? | 05:53 |
---|---|---|
olofk | Any differences worth knowing? | 05:54 |
olofk | blueCmd: Is this still valid? http://opencores.org/or1k/OR1K:FutureWork#Linux_kernel_VDSO_support | 09:01 |
olofk | stekern, poke53282, blueCmd: And this? http://opencores.org/or1k/OR1K:FutureWork#Port_libffi.2Fgobject-introspection.2Fwith_friends | 09:04 |
olofk | Would be good to have this page in shape for GSoC | 09:10 |
stekern | at least no work have been done on VDSO | 09:30 |
stekern | olofk: I say we should promote musl over uclibc, both for general reasons and openrisc specific ones | 09:47 |
olofk | stekern: (musl) I assumed that and mentioned that on the build instructions page. Haven't put up info on how to build it yet though | 10:59 |
stekern | it's pretty simple | 11:12 |
stekern | basically just a ./build.sh in musl-cros | 11:12 |
stekern | +s | 11:13 |
olofk | Does the official one work, or should we use your fork? | 11:25 |
olofk | I put up a gcc snapshot on the opencores ftp btw | 11:26 |
stekern | https://github.com/sabotage-linux/musl-cross works but you have to configure it to use our musl-4.9.x gcc repo | 11:27 |
olofk | So just set GCC_URL and GCC_EXTRACT_DIR before running then? | 11:30 |
olofk | hmm.. where is fetchextract defined? Need to check if it handles ftp addresses with username/password | 11:32 |
olofk | Have you seen that we got spam on the opencores ftp btw? :) | 11:32 |
olofk | I don't want to remove it in case it triggers more activity | 11:33 |
stekern | you can take a look at the config in my repo | 11:34 |
olofk | hmm.. getting an archive through github seems like a better choice than the opencores ftp | 11:36 |
olofk | Do we still want to use the 4.9.0 tag, or is head of or1k branch better? | 11:36 |
olofk | Same for kernel version. 3.15 or latest? | 11:38 |
olofk | and musl itself. | 11:39 |
olofk | Oh well. I'll play around a bit | 11:39 |
stekern | you should use the musl-4.9.1 branch | 11:42 |
stekern | because I have already applied the musl specific gcc patches to that | 11:43 |
olofk | aha | 11:43 |
stekern | using or1k and letting musl-cross apply the patches might work too though, never tried that though | 11:43 |
olofk | hmm... what should go in config.sh and what should be in defs.sh? | 11:43 |
olofk | Ah, I shouldn't need to touch defs.sh at all | 11:47 |
olofk | Building now | 12:03 |
olofk | ...still building | 12:26 |
olofk | cool. it worked. Time to fire up jor1k and test my compiled test program | 13:59 |
olofk | Is uploading extremely slow? | 14:03 |
olofk | Anyway, it builds fine and I can compile programs using musl-cross from https://github.com/GregorR/musl-cross.git and these additions to config.sh http://pastie.org/9856864 | 14:07 |
olofk | And a statically linked binary runs on jor1k, so I'm considering this fully verified now | 14:08 |
olofk | blueCmd: Do you have any glibc build instructions? | 15:05 |
olofk | I still think it's funny that the page on the OpenRISC wiki that was least recently modified is "News" :) | 15:38 |
poke53282 | olofk: I have ported libffi and it is in the official repository. | 16:59 |
poke53282 | So, this entry is not longer valid | 16:59 |
poke53282 | Also I think, that we should probote over libc | 17:00 |
poke53282 | Also I think, that we should promote musl over uclibc | 17:01 |
Me1234 | What happened to or1k.debain.net | 17:28 |
Me1234 | OK, I just wrote the url uncorrectly | 17:42 |
Me1234 | exit | 17:42 |
poke53282 | musl porting is in principle finished. No feature is missing and it is tested more. | 17:42 |
poke53282 | So this is a better choice currently for the official toolchain. | 17:43 |
olofk | poke53282: Cool. I have updated the GNU toolchain page with musl build instructions and mention that it's preferred over uClibc | 18:10 |
olofk | And I'll remove the libffi item from future work | 18:10 |
olofk | Has anyone tried to build gobject-introspection for or1k? blueCmd? | 19:12 |
olofk | There's a package on or1k.debian.net at least | 19:13 |
poke53282 | I guess building works. But I don't think, anyone has tested it yet. | 19:18 |
olofk | That could be done with a small python script that tries to import something from gi.repository I guess | 19:21 |
olofk | Does anyone have a OpenRISC-based Debian available? | 19:21 |
poke53282 | The libffi version, which blueCmd compiled is the incomplete libffi implementation. | 19:35 |
poke53282 | So any test would be useless | 19:35 |
olofk | And gobject-introspection depends in libffi? | 19:35 |
poke53282 | I guess | 19:35 |
olofk | So what's the status of libffi then? Do we have or1k-specific stuff that we should send upstream? | 19:36 |
poke53282 | Yes, but the debian version of bluecmd contains an old version. | 19:37 |
poke53282 | It is already upstream | 19:37 |
poke53282 | https://github.com/atgreen/libffi/tree/master/src/or1k | 19:38 |
poke53282 | I am not sure, if debian has updated to the newest libffi version yet. But I guess not. | 19:39 |
olofk | ah cool. Have they done a new release with all the patches? I assume that we only need a packaged new version then | 19:39 |
poke53282 | libffi 3.2.1 | 19:39 |
olofk | atgreen seems to be quite busy. His Moxie design has pretty good software support :) | 19:39 |
olofk | cool | 19:40 |
poke53282 | you should follow the chat a little more intensive ;) | 19:40 |
olofk | I'm trying, but you're talking all the time :) | 19:41 |
olofk | oh.... "libffi was originally written by Anthony Green" | 19:42 |
olofk | So yeah, I guess it's not that strange that libffi supports the Moxie CPU :) | 19:43 |
poke53282 | :) | 19:44 |
poke53282 | Nope | 19:50 |
poke53282 | But I wish libffi would be more widely used | 19:51 |
poke53282 | There are a lot of program, which have their own implementation. | 19:51 |
poke53282 | blueCmd: I think, that I found a severe error in your atomic load and store implementation in QEMU. | 21:23 |
blueCmd | poke53282: oh, exciting! | 21:23 |
poke53282 | https://github.com/bluecmd/or1k-qemu/blob/or32-optimize/target-openrisc/translate.c#L166 | 21:24 |
poke53282 | you save the value in some stack variables. But this aren't pointers. | 21:25 |
blueCmd | hm? | 21:25 |
poke53282 | wait | 21:26 |
blueCmd | tA should be an address surely | 21:26 |
poke53282 | Ahh, sorry. The variables are only some handles for the real memory address | 21:27 |
blueCmd | right, I think so | 21:27 |
blueCmd | it was a while ago, but this is code that is defies your normal way of following code execution, since it's only being generated | 21:28 |
olofk | Are there any good docs for how to set up and run an OpenRISC system with qemu? | 21:47 |
poke53282 | for user mode emulation there is one on the or1k debian page and in my wiki. | 21:50 |
poke53282 | For a system, I am not sure. | 21:51 |
olofk | What's the difference? | 21:51 |
poke53282 | http://wiki.qemu.org/download/qemu-doc.html | 21:52 |
poke53282 | User 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 (http://www.winehq.org) or to ease cross-compilation and cross-debugging. | 21:53 |
olofk | ok, 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 me | 21:56 |
poke53282 | you can start you statically compiled binary directly | 21:56 |
poke53282 | Well, I ask blueCmd since half a year, that he fixex his glibc to be able to boot Debian. | 21:57 |
poke53282 | gentoo stage 1 should work. | 21:57 |
poke53282 | At least as chroot environment | 21:58 |
olofk | It looked pretty straight-forward https://wiki.gentoo.org/wiki/Porting | 21:58 |
blueCmd | poke53282: "fixes"? you mean rebuild the debs? | 21:58 |
olofk | They do mention that I need glibc. Is that not working at all, or just some problem with the debian version? | 21:58 |
poke53282 | It seems to be incomplete. | 21:59 |
blueCmd | poke53282: 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 |
olofk | I wonder if I could get away with musl. I've seen other gentoo derivatives using musl | 21:59 |
poke53282 | alpine linux is my goal after I finish the qemu project. | 22:00 |
poke53282 | This is based on musl. | 22:00 |
poke53282 | and my guess is, that around 50% of the packages should compile | 22:01 |
olofk | blueCmd: 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 bits | 22:01 |
poke53282 | a chroot works. So a gentoo stage 1 build might work as well. | 22:02 |
olofk | poke53282: I'm not sure I understand where the chroot comes into the picture | 22:03 |
poke53282 | in the QEMU user mode emulation.. | 22:03 |
olofk | blueCmd explained this to me last year, but I have forgotten the details | 22:03 |
poke53282 | And I have send you a link a few minutes ago. | 22:04 |
olofk | poke53282: Sorry. I only read the introduction. I'll read the rest too | 22:04 |
poke53282 | the user mode eumlation is only an translator from or1k code to x86 code. | 22:05 |
poke53282 | No device is emulated | 22:05 |
poke53282 | no tlb. | 22:06 |
poke53282 | no mmu | 22:06 |
poke53282 | no interrupt | 22:06 |
poke53282 | no timer | 22:06 |
olofk | And all calls to the kernel goes to my host kernel too, right? | 22:06 |
poke53282 | yes | 22:06 |
blueCmd | olofk: well, there is no "last bits" :P | 22:06 |
olofk | blueCmd: Ah ok. I was thinking about the gcc stuff | 22:07 |
blueCmd | olofk: ah, well GCC is close | 22:07 |
olofk | poke53282: How is it going with qemu btw? Are you and git friends again? | 22:27 |
poke53282 | I understand better, what's going on. | 22:29 |
poke53282 | Especially the nature of conflicts and how git tries to solve it. | 22:29 |
poke53282 | I have two patches ready for upstream. | 22:29 |
olofk | Great! Do you expect more patches after that? | 22:30 |
poke53282 | Yes, much more | 22:30 |
poke53282 | But I want to do it step by step. | 22:30 |
olofk | ah.. | 22:30 |
olofk | Sounds like a good idea | 22:30 |
poke53282 | Well, we had already patches a year ago. | 22:30 |
poke53282 | And some of them were accepted. | 22:30 |
poke53282 | However the most important ones were not accepted. | 22:31 |
poke53282 | I will send the patches to blueCmd. He needs to approve them. | 22:32 |
olofk | Not accepted? Why? | 22:33 |
poke53282 | Are in principle simple stuff. | 22:33 |
poke53282 | But for two months I didn't manage it, to correct them. | 22:33 |
poke53282 | And then I had to rebase and got tons of errors. | 22:34 |
poke53282 | So I waited and waited and ..... | 22:34 |
poke53282 | They didn't understand the awesomeness of the patches. | 22:35 |
olofk | :) | 22:38 |
olofk | So 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 |
poke53282 | Something like that | 22:40 |
* poke53282 is laughing evil | 22:40 | |
olofk | Which also turned out to be the first doomsday machine written entirely in JavaScript :) | 22:41 |
poke53282 | hehe, I have their IP addresses. | 22:43 |
poke53282 | blueCmd: EMail send | 22:57 |
poke53282 | olofk: If I haven't made it clear yet. I don't like Javascript. | 22:58 |
blueCmd | poke53282: 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 repo | 23:03 |
blueCmd | poke53282: also, thanks for upstreaming this | 23:04 |
poke53282 | No real review. It is just the authorship and the sign-off line | 23:12 |
poke53282 | I checked it against my sysroot. | 23:12 |
poke53282 | your signal patches will be the next ones. | 23:13 |
--- Log closed Sun Jan 25 00:00:12 2015 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!