--- Log opened Sun Mar 09 00:00:12 2014 | ||
stekern | olofk: re sockit, the one big missing piece is still the lack of support for qsys in fusesoc (and yes, it's probably up to me to fix that), would you like the sockit port without that anyway? | 07:10 |
---|---|---|
stekern | (it's not that big of a deal running the qsys part manually, but it should of course be integrated at some point) | 07:11 |
_franck_ | stekern: is the DDR3 controller available outside QSYS ? We could have a simplier system without QSYS and HPS | 07:20 |
stekern | not sure | 07:52 |
stekern | I wouldn't really feel like moving it out of that anyway | 07:59 |
stekern | rather add qsys support than that then | 07:59 |
_franck_ | the QSYS requirement of 4GB for the system is a bit anoying that why I thought having something whithout all the fancy stuffs | 08:06 |
stekern | hmm, yeah... but who doesn't have 4gb nowdays? ;) | 08:13 |
_franck_ | sure | 08:26 |
jeremy_bennett | blueCmd: Just sent you an email - Embecosm is all good on FSF already | 10:46 |
blueCmd | jeremy_bennett: yes - I saw it just now, just about to reply to it | 10:47 |
blueCmd | jeremy_bennett: thanks. I'm guessing it's the same for gcc that embecosm is good there as well? | 10:48 |
blueCmd | yes, you wrote for the full tool chain so | 10:50 |
jeremy_bennett | blueCmd: Yes - but there was a lot of predecessor work that is reused. I discussed with Joern last week, and there will be some detective work to track down who did what. | 11:28 |
jeremy_bennett | We should have some resource to commit to OpenRISC gcc in June if you still need help then. GCC 4.9 is already at Stage 3, so realistically we'll need to aim for 4.10. | 11:29 |
jeremy_bennett | I'm sure Joern would be happy to be a maintainer for OpenRISC GCC. | 11:30 |
blueCmd | jeremy_bennett: sgtm, all help is appriciated - i'm very excited that the community seems to be willing in helping in this effort | 11:30 |
blueCmd | jeremy_bennett: perfect | 11:30 |
blueCmd | stekern: i rebased or1k-gcc on master head, a few conflicts but it went OK. should I push it to openrisc/or1k-gcc? | 11:34 |
blueCmd | olofk: didn't I tell you that stekern would be the last man to sign it? ;) | 11:42 |
stekern | blueCmd: push away | 13:13 |
blueCmd | stekern: pushed | 14:10 |
olofk | g++: error: unrecognized command line option '--start-group' | 15:20 |
olofk | g++: error: unrecognized command line option '--end-group' | 15:20 |
olofk | Hmm.. | 15:20 |
olofk | Changing to -Wl,--start-group (and end) seems to work | 15:26 |
olofk | And I thought fusesoc had complex command line parsing. g++ is on a whole different level | 15:27 |
olofk | Wouldn't be surprised if it's turing-complete | 15:28 |
ysionneau | yep it's a linker option | 15:28 |
ysionneau | not a compiler option | 15:28 |
ysionneau | weirdly enough it used to work I think, but it no longer does | 15:29 |
olofk | What I find strange is how different everyone's compilers seem to behave. | 15:29 |
ysionneau | it just depends on the compiler version | 15:30 |
ysionneau | problem is in embedded world everyone is using a different version :) | 15:30 |
olofk | Yeah | 15:30 |
olofk | And I just assumed that they would have fixed problems in their command line parser like twenty years ago | 15:32 |
-!- rfajardo_ is now known as rfajardo | 15:53 | |
ysionneau | the problem is more that gcc/g++ used to accept options even if they were not intended to be used by gcc/g++ | 16:06 |
ysionneau | then a lot of people started to put these options, without -Wl even if they were "linker options" | 16:06 |
ysionneau | and then when the "problem" is fixed ... a lot of makefile do not work anymore | 16:07 |
_franck_ | olofk: I should upgrade my gcc, I have a 4.4.7 | 16:37 |
-!- u_l-lap is now known as unknown_lamer | 16:37 | |
_franck_ | olofk: too bad you've already pushed it :( sorry | 17:04 |
_franck_ | cd /opt/ | 17:20 |
_franck_ | ll | 17:20 |
olofk | _franck_: No worries. It's not like there's a million angry users :) | 17:33 |
olofk | And it made me learn something new about compilers and linkers | 17:34 |
olofk | _franck_: I'm a bit confused now. Is it possible to use elf-loader in verilator now, or do we need another patch? | 18:26 |
blueCmd | olofk: do you run orsoc on hardware? | 18:32 |
olofk | blueCmd: Not me, because I still haven't completed a port for the boards I own, but others have done it | 18:33 |
olofk | Well, stekern has made a SoCKIT port that I could use, but I haven't had time to try it yet | 18:34 |
olofk | blueCmd: By orsoc I assume you mean orpsoc (which has evolved into a system that you can build with fusesoc) | 18:35 |
blueCmd | i'm thinking of buying something | 18:35 |
olofk | blueCmd: If you don't fancy peripherals too much, de0 nano is your best choice | 18:36 |
blueCmd | olofk: do you know the utilization when you have orsoc on it? | 18:38 |
blueCmd | I would ideally want to play with SMP | 18:39 |
stekern | blueCmd: you lost a p again =) | 18:39 |
blueCmd | hah | 18:40 |
stekern | ...and I don't mean that you want to play with S&M | 18:40 |
blueCmd | that would explain why google doesn't like my search | 18:40 |
blueCmd | https://github.com/openrisc/orpsoc :( | 18:41 |
stekern | https://github.com/openrisc/orpsoc-cores | 18:43 |
stekern | which use https://github.com/olofk/fusesoc | 18:44 |
stekern | blame olofk for the confusion =) | 18:44 |
stekern | but I think it's actually a bit less confusing now... | 18:45 |
stekern | olofk: the patch I'm using is a lot bigger than just that | 18:46 |
blueCmd | de0 nano doesn't really have that much RAM | 18:46 |
stekern | 32MB | 18:46 |
stekern | SMP, we'd need to brush of the atomic ops discussion for that | 18:47 |
stekern | which we should either case | 18:48 |
blueCmd | stekern: is the de0 crampted? | 18:49 |
blueCmd | or will I be able to fit two mor1ks on it? | 18:50 |
blueCmd | with all the extras | 18:50 |
stekern | I think you should be able to fit two without problems | 18:51 |
stekern | iirc, the complete SoC takes ~50% of the resources | 18:52 |
_franck_ | olofk: verilator sections from depends are not taken into account for now | 19:16 |
blueCmd | http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,1228&Prod=NETFPGA-1G-CML | 21:10 |
blueCmd | that looks promising | 21:10 |
-!- FreezingAlt is now known as FreezingCold | 22:44 | |
--- Log closed Mon Mar 10 00:00:14 2014 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!