| --- Log opened Sun Mar 30 00:00:42 2014 | ||
| olofk | stekern, _franck__: Ok peeps. Time to update your pull requests | 05:39 |
|---|---|---|
| olofk | oh wait... I have some more patches btw | 05:39 |
| * stekern is waiting in anticipation | 05:43 | |
| stekern | I don't care so much about my export() patch, except I have a whole bunch of orpsoc-cores patches that depends on it | 05:45 |
| stekern | + of course, it would be nice to be able to use verilator without having to declare a vpi section ;) | 05:46 |
| olofk | whoops. Missed that one :) | 05:48 |
| olofk | I have some changes in a branch now. How can I copy them to master? | 05:50 |
| stekern | git checkout master && git cherry-pick <start-hash>^..<end-hash> | 05:52 |
| olofk | It's just a single file, but I found my answer here git checkout <branch_name> path/to/new/file | 05:54 |
| stekern | ah, yes | 06:09 |
| olofk | And you're right... I'm scrapping the multiple inheritance. :( | 06:13 |
| stekern | ;) | 06:13 |
| olofk | I never get to use multiple inheritance | 06:13 |
| stekern | there will be a day, there will be a day *pats olofk on shoulder* | 06:13 |
| stekern | you have the wrong attitude towards the fancy stuff though, you should try to avoid it as long as possible ;) | 06:14 |
| olofk | Yeah, 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 |
| olofk | I'm thinking of moving the build functions back into verilator btw | 06:20 |
| olofk | I have a feeling that it will be less messy and perhaps solve the strange import problem | 06:20 |
| stekern | mmm | 06:21 |
| stekern | kind of feels like they belong there too | 06:22 |
| stekern | I wonder if the day will come when I can run ip-generate from python without intoxicating quartus_asm | 06:23 |
| stekern | if 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 files | 06:24 |
| stekern | the odd thing is, if I try to run it with shell=True, ip-generate starts to complain that args that are present are missing | 06:24 |
| stekern | so something is probably not right | 06:25 |
| stekern | with the command string | 06:25 |
| stekern | I think I will generate a qsys.sh, run that from python | 06:25 |
| stekern | if that's not working, then it's really down to that I invoke it from python | 06:26 |
| stekern | I mean, if that qsys.sh works when invoked seperately then | 06:27 |
| olofk | I guess the problem is that quartus_asm is a shell script | 06:37 |
| stekern | hmm, maybe... but if I run just the qsys part from python, and then quartus_asm from command line, I get the same error | 06:39 |
| olofk | Did you try to run it with Launcher using 'sh' as command, quartus_asm as first argument and shell=False? | 06:39 |
| stekern | no, since it's the qsys generation that is the difference | 06:40 |
| stekern | if I run the qsys commands manually, 'fusesoc build sockit' (with the qsys gen part commented out) works | 06:40 |
| stekern | now I'm trying running the ip-generate commands with subprocess.call and shell=True | 06:42 |
| stekern | and the args generated as a concenated string, instead of a list | 06:42 |
| stekern | if that doesn't work, then next thing I will try is to merge the ip-generate commands (there are two) into one subprocess.call() | 06:43 |
| stekern | maybe the first sets some environmental variables that the second depends upno | 06:43 |
| stekern | upon | 06:44 |
| olofk | That's an interesting theory | 06:44 |
| olofk | Could be worth trying to compare env before and after the commands | 06:45 |
| stekern | otoh, generating a standalone qsys.sh 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 |
| stekern | s/from/for | 06:45 |
| olofk | Yeah, that would be great | 06:50 |
| stekern | the 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 |
| olofk | How the heÃll do they manage to make the EDA tools so mess? | 06:51 |
| stekern | and it takes ~1 hour... | 06:51 |
| olofk | ughh | 06:51 |
| stekern | (mess) did you see the $clog2 patch? | 06:52 |
| olofk | nope | 06:52 |
| olofk | Where? | 06:52 |
| stekern | https://github.com/openrisc/orpsoc-cores/pull/43 | 06:53 |
| stekern | I gained a couple of gray hairs making that work with all tools... | 06:54 |
| olofk | yikes. That's scary | 06:57 |
| stekern | mhmm | 07:20 |
| _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 core | 11:56 |
| stekern | ah smary one should be able to steal the line from another master | 11:57 |
| stekern | smart | 11:57 |
| stekern | still having problems with this on-screen kb | 11:58 |
| stekern | I think I've finally got quartus into submission | 18:55 |
| stekern | seems you _have_ to use a relative path to the qip file, not an absolute... | 18:56 |
| blueCmd | stekern: 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 |
| blueCmd | the code generated when __atomic_* is used would be a syscall to be more exact | 19:23 |
| stekern | I think we want to extend the architecture to properly do those | 19:43 |
| blueCmd | yes | 19:43 |
| blueCmd | that would be nice | 19:43 |
| stekern | and that's how it should be done imo | 19:44 |
| stekern | because, the current atomics only work in single cpu systems anyways | 19:44 |
| blueCmd | yeah, but I need it done in a shorter timeframe | 19:44 |
| stekern | if doing system calls in gcc sounds ugly? yeah, I definetely think so ;) | 19:47 |
| blueCmd | good | 19:48 |
| blueCmd | but I still need to do it :) | 19:48 |
| blueCmd | until we add real atomics | 19:49 |
| stekern | tbh, 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 |
| stekern | ? | 19:50 |
| blueCmd | stekern: yes | 19:52 |
| blueCmd | stekern: that's where I would need to implement the syscall | 19:52 |
| stekern | hmm, ok.. in that case it sounds less ugly, but still not pretty | 19:55 |
| blueCmd | stekern: my first thought was to do it in libgcc, but if you don't need to link to libatomic explicitly thhat would be nicer | 19:55 |
| blueCmd | I wonder if it's supported for bootstrapping. glibc depends on atomic, and atomic seems to need crt1.o (well, configure needs it) | 20:08 |
| blueCmd | seems I need to create the functions in libgcc because of that. libatomic does not like to be built before glibc | 20:41 |
| olofk | I'm getting another weird $clog2 error with ISE14.6 | 21:47 |
| --- Log closed Mon Mar 31 00:00:44 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!