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

--- Log opened Sun Mar 30 00:00:42 2014
olofkstekern, _franck__: Ok peeps. Time to update your pull requests05:39
olofkoh wait... I have some more patches btw05:39
* stekern is waiting in anticipation05:43
stekernI don't care so much about my export() patch, except I have a whole bunch of orpsoc-cores patches that depends on it05:45
stekern+ of course, it would be nice to be able to use verilator without having to declare a vpi section ;)05:46
olofkwhoops. Missed that one :)05:48
olofkI have some changes in a branch now. How can I copy them to master?05:50
stekerngit checkout master && git cherry-pick <start-hash>^..<end-hash>05:52
olofkIt's just a single file, but I found my answer here git checkout <branch_name> path/to/new/file05:54
stekernah, yes06:09
olofkAnd you're right... I'm scrapping the multiple inheritance. :(06:13
olofkI never get to use multiple inheritance06:13
stekernthere will be a day, there will be a day *pats olofk on shoulder*06:13
stekernyou have the wrong attitude towards the fancy stuff though, you should try to avoid it as long as possible ;)06:14
olofkYeah, I know, but I'm mostly reviewing patches, so the few lines of code I write myself need to be as fancy as possible :)06:19
olofkI'm thinking of moving the build functions back into verilator btw06:20
olofkI have a feeling that it will be less messy and perhaps solve the strange import problem06:20
stekernkind of feels like they belong there too06:22
stekernI wonder if the day will come when I can run ip-generate from python without intoxicating quartus_asm06:23
stekernif I run the exact same commands from the command line, it works, but when I invoke them from python quartus_asm starts to complain it can't find files06:24
stekernthe odd thing is, if I try to run it with shell=True, ip-generate starts to complain that args that are present are missing06:24
stekernso something is probably not right06:25
stekernwith the command string06:25
stekernI think I will generate a, run that from python06:25
stekernif that's not working, then it's really down to that I invoke it from python06:26
stekernI mean, if that works when invoked seperately then06:27
olofkI guess the problem is that quartus_asm is a shell script06:37
stekernhmm, maybe... but if I run just the qsys part from python, and then quartus_asm from command line, I get the same error06:39
olofkDid you try to run it with Launcher using 'sh' as command, quartus_asm as first argument and shell=False?06:39
stekernno, since it's the qsys generation that is the difference06:40
stekernif I run the qsys commands manually, 'fusesoc build sockit' (with the qsys gen part commented out) works06:40
stekernnow I'm trying running the ip-generate commands with and shell=True06:42
stekernand the args generated as a concenated string, instead of a list06:42
stekernif that doesn't work, then next thing I will try is to merge the ip-generate commands (there are two) into one
stekernmaybe the first sets some environmental variables that the second depends upno06:43
olofkThat's an interesting theory06:44
olofkCould be worth trying to compare env before and after the commands06:45
stekernotoh, generating a standalone might be a nice approach from other reasons, that will make the build dir still completely independent from fusesoc (as it is now)06:45
olofkYeah, that would be great06:50
stekernthe most annoying part of debugging this is that I have to wait for the whole build to go through before I know if a change works or not.06:51
olofkHow the heÃll do they manage to make the EDA tools so mess?06:51
stekernand it takes ~1 hour...06:51
stekern(mess) did you see the $clog2 patch?06:52
stekernI gained a couple of gray hairs making that work with all tools...06:54
olofkyikes. That's scary06:57
_franck__stekern: how smart was your arbiter "with a bit of fairness" when you tried to remove that f*?!#ing flicker on your screen ?08:05
stekern_franck__: I think it was not so smart, basically just priorirising the vga core11:56
stekernah smary one should be able to steal the line from another master11:57
stekernstill having problems with this on-screen kb11:58
stekernI think I've finally got quartus into submission18:55
stekernseems you _have_ to use a relative path to the qip file, not an absolute...18:56
blueCmdstekern: I want to implement the atomic builtins in gcc. they will need to do system calls and thus be linux specific. would it be ugly to do system calls in gcc?19:22
blueCmdthe code generated when __atomic_* is used would be a syscall to be more exact19:23
stekernI think we want to extend the architecture to properly do those19:43
blueCmdthat would be nice19:43
stekernand that's how it should be done imo19:44
stekernbecause, the current atomics only work in single cpu systems anyways19:44
blueCmdyeah, but I need it done in a shorter timeframe19:44
stekernif doing system calls in gcc sounds ugly? yeah, I definetely think so ;)19:47
blueCmdbut I still need to do it :)19:48
blueCmduntil we add real atomics19:49
stekerntbh, I haven't looked at the atomic builtins, but if they aren't implemented, aren't they resolved as a lib-call then (to libatomic)19:50
blueCmdstekern: yes19:52
blueCmdstekern: that's where I would need to implement the syscall19:52
stekernhmm, ok.. in that case it sounds less ugly, but still not pretty19:55
blueCmdstekern: my first thought was to do it in libgcc, but if you don't need to link to libatomic explicitly thhat would be nicer19:55
blueCmdI wonder if it's supported for bootstrapping. glibc depends on atomic, and atomic seems to need crt1.o (well, configure needs it)20:08
blueCmdseems I need to create the functions in libgcc because of that. libatomic does not like to be built before glibc20:41
olofkI'm getting another weird $clog2 error with ISE14.621:47
--- Log closed Mon Mar 31 00:00:44 2014

Generated by 2.15.2 by Marius Gedminas - find it at!