IRC logs for #openrisc Sunday, 2014-03-09

--- Log opened Sun Mar 09 00:00:12 2014
stekernolofk: 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 HPS07:20
stekernnot sure07:52
stekernI wouldn't really feel like moving it out of that anyway07:59
stekernrather add qsys support than that then07:59
_franck_the QSYS requirement of 4GB for the system is a bit anoying that why I thought having something whithout all the fancy stuffs08:06
stekernhmm, yeah... but who doesn't have 4gb nowdays? ;)08:13
jeremy_bennettblueCmd: Just sent you an email - Embecosm is all good on FSF already10:46
blueCmdjeremy_bennett: yes - I saw it just now, just about to reply to it10:47
blueCmdjeremy_bennett: thanks. I'm guessing it's the same for gcc that embecosm is good there as well?10:48
blueCmdyes, you wrote for the full tool chain so10:50
jeremy_bennettblueCmd: 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_bennettWe 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_bennettI'm sure Joern would be happy to be a maintainer for OpenRISC GCC.11:30
blueCmdjeremy_bennett: sgtm, all help is appriciated - i'm very excited that the community seems to be willing in helping in this effort11:30
blueCmdjeremy_bennett: perfect11:30
blueCmdstekern: i rebased or1k-gcc on master head, a few conflicts but it went OK. should I push it to openrisc/or1k-gcc?11:34
blueCmdolofk: didn't I tell you that stekern would be the last man to sign it? ;)11:42
stekernblueCmd: push away13:13
blueCmdstekern: pushed14:10
olofkg++: error: unrecognized command line option '--start-group'15:20
olofkg++: error: unrecognized command line option '--end-group'15:20
olofkChanging to -Wl,--start-group (and end) seems to work15:26
olofkAnd I thought fusesoc had complex command line parsing. g++ is on a whole different level15:27
olofkWouldn't be surprised if it's turing-complete15:28
ysionneauyep it's a linker option15:28
ysionneaunot a compiler option15:28
ysionneauweirdly enough it used to work I think, but it no longer does15:29
olofkWhat I find strange is how different everyone's compilers seem to behave.15:29
ysionneauit just depends on the compiler version15:30
ysionneauproblem is in embedded world everyone is using a different version :)15:30
olofkAnd I just assumed that they would have fixed problems in their command line parser like twenty years ago15:32
-!- rfajardo_ is now known as rfajardo15:53
ysionneauthe problem is more that gcc/g++ used to accept options even if they were not intended to be used by gcc/g++16:06
ysionneauthen a lot of people started to put these options, without -Wl even if they were "linker options"16:06
ysionneauand then when the "problem" is fixed ... a lot of makefile do not work anymore16:07
_franck_olofk: I should upgrade my gcc, I have a 4.4.716:37
-!- u_l-lap is now known as unknown_lamer16:37
_franck_olofk: too bad you've already pushed it :( sorry17:04
_franck_cd /opt/17:20
olofk_franck_: No worries. It's not like there's a million angry users :)17:33
olofkAnd it made me learn something new about compilers and linkers17: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
blueCmdolofk: do you run orsoc on hardware?18:32
olofkblueCmd: Not me, because I still haven't completed a port for the boards I own, but others have done it18:33
olofkWell, stekern has made a SoCKIT port that I could use, but I haven't had time to try it yet18:34
olofkblueCmd: By orsoc I assume you mean orpsoc (which has evolved into a system that you can build with fusesoc)18:35
blueCmdi'm thinking of buying something18:35
olofkblueCmd: If you don't fancy peripherals too much, de0 nano is your best choice18:36
blueCmdolofk: do you know the utilization when you have orsoc on it?18:38
blueCmdI would ideally want to play with SMP18:39
stekernblueCmd: you lost a p again =)18:39
stekern...and I don't mean that you want to play with S&M18:40
blueCmdthat would explain why google doesn't like my search18:40
blueCmd :(18:41
stekernwhich use
stekernblame olofk for the confusion =)18:44
stekernbut I think it's actually a bit less confusing now...18:45
stekernolofk: the patch I'm using is a lot bigger than just that18:46
blueCmdde0 nano doesn't really have that much RAM18:46
stekernSMP, we'd need to brush of the atomic ops discussion for that18:47
stekernwhich we should either case18:48
blueCmdstekern: is the de0 crampted?18:49
blueCmdor will I be able to fit two mor1ks on it?18:50
blueCmdwith all the extras18:50
stekernI think you should be able to fit two without problems18:51
stekerniirc, the complete SoC takes ~50% of the resources18:52
_franck_olofk: verilator sections from depends are not taken into account for now19:16
blueCmdthat looks promising21:10
-!- FreezingAlt is now known as FreezingCold22:44
--- Log closed Mon Mar 10 00:00:14 2014

Generated by 2.15.2 by Marius Gedminas - find it at!