IRC logs for #openrisc Thursday, 2015-04-09

--- Log opened Thu Apr 09 00:00:58 2015
helmuthi. is there a document describing the state of gcc upstreaming? it seems gcc-5 will not support or1k.11:19
olofkhelmut: We don't have any documents regarding this. Most of the work is done, but we haven't started the upstreaming process yet12:16
olofkstekern: Got any keys signed lately?12:16
stekernno, I pinged Jonas about it again, but haven't got a reply12:19
olofkah ok12:19
stekernregardless, I'm going to prepare a branch with the critical patches that are pending12:22
stekernsome fun stuff from the minimig work is unfolding too, it's this guy that has done the de1 port I'm modyfying:12:24
stekernand he use those changes in the or1200 core he has12:24
stekernso he doesn't use wishbone, but rather a "qmem bus"12:25
stekernmakes mor1kx less easy to just drop-in12:25
stekernan option would be to adapt that to mor1kx and use it for the TCM fetcher in espresso12:26
stekernand I'm doing to port to de0 nano, so I'll need to add alot of stuff to some breakout board12:27
stekernVGA, sd-card and PS/2 at least12:28
stekernand audio12:28
stekernand reading around, he did some experimenting with emulating the 68k with or1200 ;)12:29
olofkhaha. Cool. Did it work?12:32
stekernno, don't think he ever finished it. it was just some comment in another context.12:32
stekernbut it's probably feasible to do it12:35
olofkIs the interface on the CPU side of the wishbone module in mor1kx single cycle?12:35
olofkSo that we could hook up something there, as was done with avalon12:35
stekernthe 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.16MHz12:36
stekernolofk: what do you mean?12:37
stekernare you asking if the bus interface in lsu and fetch is single cycle?12:38
olofkI think I am12:38
stekernin cappuccino it's not, since that would create terrible critical paths12:38
olofkah ok. So to get qmem functionality we would need bigger changes to cappucino12:39
stekernbut I've been wanting to add TCM support to cappuccino by hooking into the cache interface12:39
stekernor at least reuse that to some extent12:40
stekernit should be fairly simple, just bypass the cache module and never miss12:41
stekernperhaps you could even allow backpressure in the form of "misses" though12:42
stekernresuing the cache interface would have the benefit that no changes to the lsu and fetcher would be needed12:43
stekernthey are messy as it is...12:43
olofkYeah. That sounds good12:44
stekernbut I haven't had anything that would need something like that, so it hasn't been itching enough yet12:45
olofkAnything needed for building an Amiga with a built-in OpenRISC must be regarded as a worthy goal :)12:46
stekernadding wishbone to the minimig core is another thing that has snuck into my todo-list while browsing the sources...12:48
olofkYeah. I thought about that too12:49
olofkhmm.. could I just use the kernel headers from sabotage-linux when building musl?12:50
stekernboth a master and a slave interface, instead of the current 68k and sram interfaces12:50
olofkI guess we could reuse som wishbone peripheral controller then as well12:51
stekernyes, I mentioned that you could the other day, but I haven't tested it12:51
olofkI'll try that once I've gotten my patched version to build12:52
olofkSeems like it's my fault that the qmem patch was never applied12:56
helmutolofk: according to blueCmd upstreaming was tried but ran afoul copyright assignment issues.13:01
helmutolofk: upstream binutils, for example, appear to have working or1k support.13:02
olofkhelmut: 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
olofkgcc is also a bit stricter since we need a dedicated gcc guy to review the source13:05
olofkOr perhaps we have all the assignments we need now, but no one has had time to do the last part. Can't remember anymore13:06
helmutthe bit whether all the assignments are available now is the one I am interested in.13:08
olofkstekern, blueCmd, poke53281: Anyone remembers the status here?13:09
helmutI had hoped that gcc-5 would contain or1k bits already, but it always looks like
olofkhelmut: 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
helmuttrue, but this work prevents you from benefitting from debian's continuous integration of cross building a base system for or1k.13:11
olofkWe are sadly aware of this13:12
helmutif the patch stack isn't too big, I'm willing to carry it locally.13:13
blueCmdolofk: we still require one person to sign, and maybe if new persons have contributed13:14
helmutblueCmd: thanks13:14
blueCmdhe kind of disappeared though, that last person13:14
blueCmdso it looks like clean-room or Clang only13:15
blueCmdor hire a P-I13:15
olofkOr a hitman13:15
olofkNo license requirements for dead people, right?13:15
olofkStill need the P-I though to find him13:15
helmut70 years post mortem in most jurisdictions.13:16
olofkShould be ok. or1k will be just as relevant in 70 years13:16
olofkand gcc too13:16
helmutanyway, I suspect that glibc 2.19 isn't or1k ready either. maybe 2.21 is.13:17
olofkIf debian is musl-friendly, perhaps that might be an option?13:22
olofkI think I just built busybox13:52
olofkI ended up doing it in a slow and dirty way :)13:53
helmutolofk: Shawn Landden has recently shown interest in making a musl based debian work. thus far I haven't seen any results though14:22
helmutironically, the musl source package doesn't build anything for musl-linux-any.14:24
olofkWould it be possible to patch only busybox to make it build with musl and upstream linux headers?20:58
olofkSecond best alternative would perhaps be to always use the kernel-headers from sabotage linux. Hope to find some time to test that tomorrow21:00
--- Log closed Fri Apr 10 00:00:59 2015

Generated by 2.15.2 by Marius Gedminas - find it at!