| --- Log opened Thu Apr 09 00:00:58 2015 | ||
| helmut | hi. is there a document describing the state of gcc upstreaming? it seems gcc-5 will not support or1k. | 11:19 |
|---|---|---|
| olofk | helmut: We don't have any documents regarding this. Most of the work is done, but we haven't started the upstreaming process yet | 12:16 |
| olofk | stekern: Got any keys signed lately? | 12:16 |
| stekern | no, I pinged Jonas about it again, but haven't got a reply | 12:19 |
| olofk | ah ok | 12:19 |
| stekern | regardless, I'm going to prepare a branch with the critical patches that are pending | 12:22 |
| stekern | some fun stuff from the minimig work is unfolding too, it's this guy that has done the de1 port I'm modyfying: | 12:24 |
| stekern | http://opencores.org/forum,OpenRISC,0,4427 | 12:24 |
| stekern | and he use those changes in the or1200 core he has | 12:24 |
| stekern | so he doesn't use wishbone, but rather a "qmem bus" | 12:25 |
| stekern | makes mor1kx less easy to just drop-in | 12:25 |
| stekern | an option would be to adapt that to mor1kx and use it for the TCM fetcher in espresso | 12:26 |
| stekern | and I'm doing to port to de0 nano, so I'll need to add alot of stuff to some breakout board | 12:27 |
| stekern | VGA, sd-card and PS/2 at least | 12:28 |
| stekern | and audio | 12:28 |
| stekern | and reading around, he did some experimenting with emulating the 68k with or1200 ;) | 12:29 |
| olofk | haha. Cool. Did it work? | 12:32 |
| stekern | no, don't think he ever finished it. it was just some comment in another context. | 12:32 |
| stekern | but it's probably feasible to do it | 12:35 |
| olofk | Is the interface on the CPU side of the wishbone module in mor1kx single cycle? | 12:35 |
| olofk | So that we could hook up something there, as was done with avalon | 12:35 |
| stekern | the 68k that is used in the FPGA versions of minimig is not cycle accurate, they run it at 28.64MHz to get performance comparable with the original 7.16MHz | 12:36 |
| stekern | olofk: what do you mean? | 12:37 |
| stekern | are you asking if the bus interface in lsu and fetch is single cycle? | 12:38 |
| olofk | I think I am | 12:38 |
| stekern | in cappuccino it's not, since that would create terrible critical paths | 12:38 |
| olofk | ah ok. So to get qmem functionality we would need bigger changes to cappucino | 12:39 |
| stekern | but I've been wanting to add TCM support to cappuccino by hooking into the cache interface | 12:39 |
| stekern | or at least reuse that to some extent | 12:40 |
| stekern | it should be fairly simple, just bypass the cache module and never miss | 12:41 |
| stekern | perhaps you could even allow backpressure in the form of "misses" though | 12:42 |
| stekern | resuing the cache interface would have the benefit that no changes to the lsu and fetcher would be needed | 12:43 |
| stekern | they are messy as it is... | 12:43 |
| olofk | Yeah. That sounds good | 12:44 |
| stekern | but I haven't had anything that would need something like that, so it hasn't been itching enough yet | 12:45 |
| olofk | Anything needed for building an Amiga with a built-in OpenRISC must be regarded as a worthy goal :) | 12:46 |
| stekern | adding wishbone to the minimig core is another thing that has snuck into my todo-list while browsing the sources... | 12:48 |
| olofk | Yeah. I thought about that too | 12:49 |
| olofk | hmm.. could I just use the kernel headers from sabotage-linux when building musl? | 12:50 |
| stekern | both a master and a slave interface, instead of the current 68k and sram interfaces | 12:50 |
| olofk | I guess we could reuse som wishbone peripheral controller then as well | 12:51 |
| stekern | yes, I mentioned that you could the other day, but I haven't tested it | 12:51 |
| olofk | I'll try that once I've gotten my patched version to build | 12:52 |
| olofk | Seems like it's my fault that the qmem patch was never applied | 12:56 |
| helmut | olofk: according to blueCmd upstreaming was tried but ran afoul copyright assignment issues. | 13:01 |
| helmut | olofk: upstream binutils, for example, appear to have working or1k support. | 13:02 |
| olofk | helmut: Yes. binutils was easier because we could get the copyright assignment from all the people. For gcc, we are still missing one or two people. | 13:05 |
| olofk | gcc is also a bit stricter since we need a dedicated gcc guy to review the source | 13:05 |
| olofk | Or perhaps we have all the assignments we need now, but no one has had time to do the last part. Can't remember anymore | 13:06 |
| helmut | the bit whether all the assignments are available now is the one I am interested in. | 13:08 |
| olofk | stekern, blueCmd, poke53281: Anyone remembers the status here? | 13:09 |
| helmut | I had hoped that gcc-5 would contain or1k bits already, but it always looks like https://jenkins.debian.net/view/rebootstrap/job/rebootstrap_or1k_gcc5/lastBuild/console | 13:10 |
| olofk | helmut: Yeah. It would be great to finish this up, but it's still a bit of work and the manpower here is limited :/ | 13:11 |
| helmut | true, but this work prevents you from benefitting from debian's continuous integration of cross building a base system for or1k. | 13:11 |
| olofk | We are sadly aware of this | 13:12 |
| helmut | if the patch stack isn't too big, I'm willing to carry it locally. | 13:13 |
| blueCmd | olofk: we still require one person to sign, and maybe if new persons have contributed | 13:14 |
| helmut | blueCmd: thanks | 13:14 |
| blueCmd | he kind of disappeared though, that last person | 13:14 |
| blueCmd | so it looks like clean-room or Clang only | 13:15 |
| blueCmd | or hire a P-I | 13:15 |
| olofk | Or a hitman | 13:15 |
| olofk | No license requirements for dead people, right? | 13:15 |
| olofk | Still need the P-I though to find him | 13:15 |
| blueCmd | :) | 13:15 |
| helmut | 70 years post mortem in most jurisdictions. | 13:16 |
| olofk | Should be ok. or1k will be just as relevant in 70 years | 13:16 |
| olofk | and gcc too | 13:16 |
| helmut | anyway, I suspect that glibc 2.19 isn't or1k ready either. maybe 2.21 is. | 13:17 |
| olofk | If debian is musl-friendly, perhaps that might be an option? | 13:22 |
| olofk | I think I just built busybox | 13:52 |
| olofk | I ended up doing it in a slow and dirty way :) | 13:53 |
| helmut | olofk: Shawn Landden has recently shown interest in making a musl based debian work. thus far I haven't seen any results though | 14:22 |
| helmut | ironically, the musl source package doesn't build anything for musl-linux-any. | 14:24 |
| olofk | Would it be possible to patch only busybox to make it build with musl and upstream linux headers? | 20:58 |
| olofk | Second best alternative would perhaps be to always use the kernel-headers from sabotage linux. Hope to find some time to test that tomorrow | 21:00 |
| --- Log closed Fri Apr 10 00:00:59 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!