--- Log opened Sat Jul 02 00:00:20 2016 | ||
-!- Netsplit *.net <-> *.split quits: _florent_ | 01:05 | |
olofk_ | kc5tja: Welcome to our big family where we all love each other | 02:43 |
---|---|---|
olofk_ | Except me... no one likes me | 02:43 |
* olofk_ is waiting to be comforted | 02:43 | |
-!- olofk_ is now known as olofk | 02:43 | |
wallento | bluecmd: I think we should keep it as fossi | 03:46 |
olofk | Happy birthday wallento! :) | 06:11 |
wallento | thanks, olofk | 09:41 |
GeneralStupid | ohh happy birthday :) wallento | 09:45 |
olofk | wallento: But I think you misunderstood. You're not supposed to give away presents on your birthday :) https://twitter.com/OlofKindgren/status/749238467457064960 | 09:50 |
wallento | hehe, how do you like the business cards? | 10:22 |
olofk | wallento: They look great, and they are being retweeted like crazy :) | 12:01 |
bandvig | Hello all. I'm trying to build OR1K tool chain with latest NewLIB following by instructions http://openrisc.io/newlib/building.html | 12:07 |
bandvig | I cloned binutils-gdb, or1k-gcc and newlib. I downloaded latest gmp/mpc/mpfr, unpacked them and created links in "gcc". | 12:07 |
bandvig | I made the only modification in multi-lib configuration. Instead of "mno-delay/mcompat-delay msoft-float" I made only "mhard-float" to compile NewLIB itself (on stage "Building NewLIB") with mhard-float option switched ON. | 12:08 |
bandvig | I successfully passed "Build binutils" and "GCC stage 1", but building NewLIB failed with error message: http://pastebin.com/0FL0JxQ5. | 12:08 |
bandvig | However if I try to build old NewLIB from or1k-src source tree, the stage passes successfully. Have any idea? | 12:08 |
blueCmd | wallento: cool, let me know how you want to do that at a time that suites you | 12:09 |
blueCmd | for now I'll just renew it | 12:09 |
olofk | bandvig: Which source did you use for newlib? The upstream repo or the OpenRISC one? | 12:15 |
olofk | First thing that comes to mind is that this could be some problem with newer versions of gcc | 12:17 |
olofk | Not sure how to easily debug this | 12:19 |
bandvig | olofk: NewLIB I cloned from https://github.com/openrisc/newlib (or1k branch). I have the same problem wit gcc 4.9.2, 4.9.3 and 5.3.0. | 12:20 |
bandvig | But I have NO problem with NewLIB from https://github.com/openrisc/or1k-src and at least gcc 4.9.2 | 12:21 |
olofk | Have you tried upstream newlib? That should at least be a lot more updated than the one in or1k-src | 12:22 |
bandvig | Not yet. I'll try. | 12:24 |
bandvig | olofk: could I use https://github.com/openrisc/newlib/tree/upstream ? | 12:27 |
olofk | bandvig: Not sure | 12:28 |
olofk | I guess wallento would know best | 12:32 |
bandvig | I'm cloning git://sourceware.org/git/newlib-cygwin.git as recomended http://openrisc.io/newlib/building.html | 12:34 |
bandvig | well, it cloned and configured. Compilation has started. | 12:44 |
olofk | Let me know if it works. I don't have a clue what's wrong, but at least this might make it easier to diff | 12:51 |
bandvig | olofk: unfortunatelly the same error :( | 12:52 |
olofk | hmm.. | 12:52 |
olofk | Do you know how old your previous newlib was? | 12:53 |
bandvig | olofk: README of https://github.com/openrisc/or1k-src/tree/or1k/newlib stays that is "newlib-2.0.0 release" | 13:02 |
olofk | ah.. sorry. Forgot that you said you were using the one from or1k-src previously | 13:04 |
olofk | I see that the failing function or1k_select_cc_mode is only used in a handful places. I wonder if we can turn this around and find out why it's failing instead | 13:06 |
olofk | I hate internal gcc errors. Fells like they are always a mess to debug | 13:09 |
bandvig | In fact, the failed place ("float complex cprojf(float complex);") is declared in the absolutely same way in all NewLIB versions I tried. I'm afraid there is problem with maco declarations, or something like this. | 13:10 |
wallento | bluecmd: probably don't renew, when is it due? | 13:11 |
wallento | I can start the transfer request today | 13:11 |
olofk | Yeah, I saw that too, and it hasn't changed for many years. Doesn't seem like anyone has touched or1k_select_cc_mode either since 2012 | 13:11 |
wallento | bandvig: I will have a look at it tomorrow | 13:12 |
olofk | Have you tried with the default flags? | 13:12 |
wallento | but thats also out of my comfort zone | 13:12 |
bandvig | wallento: thanks, and happy birthday! | 13:13 |
wallento | thanks | 13:14 |
bandvig | olofk: not yet, I will now. | 13:15 |
olofk | A bit far-fetched, but as it was Peter Gavin who wrote the function, he might only have tested it with the ISA version without the delay slot | 13:16 |
olofk | bandvig: How do you enable hard-float? I tried to add -mhard-float when I ran configure while building newlib | 13:46 |
olofk | Or do I need to add this to gcc stage1? | 13:47 |
olofk | Never really understood how this all fits together | 13:47 |
bandvig | olofk: you should open file path_to_src_gcc/gcc/config/or1k and edit declarations for MULTILIB_OPTIONS and MULTILIB_DIRNAMES, than rebild tool chain from stage "Build NewLIB". | 13:55 |
bandvig | olofk: I use MULTILIB_OPTIONS = mhard-float and MULTILIB_DIRNAMES = hard-float | 13:55 |
bandvig | or from "GCC stage 1"? I'm not sure. | 13:57 |
olofk | bandvig: Aha. Is that how it's done. Always thought you could just get away with changing configure options | 15:12 |
bandvig | olofk: wallento: I tried build gcc-5.3.0 with https://github.com/openrisc/newlib (or1k branch) and reduced multi-lib options to MULTILIB_OPTIONS = msoft-float and MULTILIB_DIRNAMES = soft-float. And now "Build NewLIB" stage passed. | 15:15 |
bandvig | so, the problem is definitely in mhard-float option and fresh version of NewLIB | 15:17 |
olofk | bandvig: Hmm.. still don't get how this works. Does newlib pick up these options from gcc somehow? | 15:18 |
olofk | I would have thought that you would specify this option in newlib rather than in gcc | 15:20 |
bandvig | olofk: I think these options somehow affects gcc of stage 1. (I rebuild tool chain starting from GCC-1 stage) | 15:21 |
olofk | I'm trying another option now | 15:28 |
olofk | Because my gcc, without any changes support the -mhard-float flag, so for me it just seems like we only need to enable it for newlib | 15:28 |
olofk | But I'm not an expert on this | 15:28 |
olofk | ok, so I got the same error now with my method | 15:30 |
olofk | Instead of doing stuff in gcc, I just added -mhard-float to the newlib_cflags in newlib/newlib/configure.host | 15:30 |
olofk | One interesting difference is that it seems like I got a better stacktrace | 15:31 |
olofk | http://pastie.org/10897482 | 15:32 |
olofk | So it's the call from or1k_expand_int_compare that fails. Have to dif a bit deeper | 15:33 |
olofk | s/dif/dig | 15:33 |
olofk | There's an interesting comment here https://github.com/openrisc/or1k-gcc/blob/or1k/gcc/config/or1k/or1k.c#L385 | 15:36 |
olofk | Maybe there is some missing code for floating point | 15:36 |
olofk | Or rather some code changes that exposes this in a new way | 15:36 |
olofk | aha. Could this be the problem? (note: I still don't have much of a clue about gcc internals :)) | 15:38 |
olofk | https://github.com/openrisc/or1k-gcc/blob/or1k/gcc/config/or1k/or1k.c#L1411 | 15:38 |
olofk | It seems like we call or1k_expand_compare with "SFmode", which I interpret as some kind of floating point mode | 15:39 |
olofk | But or1k_expand_compare has a comment that says it only deals with integers | 15:39 |
olofk | I tried to break out cprojf to a separate test case, but I can't make that fail | 15:52 |
bandvig | olofk: good job! perhaps it would be the reason. However, it doesn't explain how it works with old version of NewLIB :o | 15:57 |
olofk | True :/ | 15:59 |
olofk | But these codebases are so damn complex, so it's difficult to get an overview | 15:59 |
olofk | I think bisecting the problem is our best hope | 16:00 |
olofk | But that's hard too, since the working and failing cases are in different repos | 16:00 |
olofk | But I also think that adding the -mhard-float to configure.host in newlib is a cleaner solution than hacking the gcc options | 16:02 |
olofk | But I'm not sure of the implications | 16:02 |
bandvig | olofk: I think if you want multi-lib configuration, then you have edit MULTILIB_* in gcc, but if you have fixed hardware configuration (for example, FPU is enabled permanentlu) then changing NewLIB's configure.host is more siutable. | 16:11 |
bandvig | I use MULTILIB_* just because I found them first. | 16:11 |
olofk | bandvig: Ah yes. That makes sens | 16:11 |
olofk | jeremybennett: Is this your area perhaps. Remember why you wrote that comment on line 534 in or1k.md six years ago? :) | 16:12 |
olofk | I wonder if we can trigger the error just by making a testcase that makes gcc emit cbranchsf4 | 16:12 |
olofk | Looks like -fdump-{ipa,tree,rtl}-all might be useful | 16:23 |
olofk | Enough for today | 16:25 |
olofk | Hmm.. what's a standard poster size? | 16:53 |
olofk | Googling a bit, the answer seems to be that it differs :) | 16:54 |
olofk | Looks like I'll go for B1 (approximately) | 16:59 |
olofk | or 700x1000mm to be exact | 17:01 |
olofk | Which apparently is the standard italian movie poster format called Un Foglio | 17:02 |
ZipCPU | For what it's worth, and anyone interested, I am in the process of building a controller for the QSPI flash on the Arty. | 17:57 |
ZipCPU | It's just enough different from the other QSPI flashes I've worked with that ... it needs some attention. | 17:58 |
ZipCPU | My plan is to get it running at Quad speed, to use the XIP feature, and to see if I can't get it running with a 100MHz clock on the Arty. | 17:58 |
ZipCPU | This includes full access to all of the device registers, the device ID, as well as read/write access to the one-time-programmable registers, the ability to do sector and subsector erases, etc. | 17:59 |
olofk | ZipCPU: Don't remember if I have mentioned this before, but have you checked out the quad SPI controller from the Pulpino project? | 18:54 |
ZipCPU | Looking it up now. | 19:16 |
ZipCPU | Okay ... one difference here is the commands are done automatically by the controller. The CPU doesn't need to issue them. In particular, this means that, in the implementation I propose, the CPU may run from flash as though it were any other wishbone accessible device. | 19:18 |
ZipCPU | The ID registers may be read like registers, for example, and the fabric takes care of issuing the appropriate read ID register command and so forth. | 19:20 |
ZipCPU | Further, you can write the flash just like any other address--you just can't erase like any other address. | 19:20 |
ZipCPU | Well, that and ... after writing, the flash goes out to lunch for a while, so you may want to be careful how you do it. | 19:20 |
ZipCPU | It's really useful for a CPU: you place the reset code and the boot loader into the flash, and then the CPU doesn't need to know anything more to read from it--the controller takes care of the details. | 19:23 |
ZipCPU | If you want to read large sections of flash, at pipeline speeds, you can use a DMA controller ... | 19:23 |
blueCmd | wallento: it's due end of this month I think | 20:24 |
--- Log closed Sun Jul 03 00:00:21 2016 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!