jonibo_ | derRichard: or1k has no (complex) "atomic" operations... this is the biggest missing feature, in my opinion | 08:18 |
---|---|---|
jonibo_ | entry.S has an "atomic_swap" syscall that can be used to get just enough atomicity to make things useful, though | 08:18 |
jonibo_ | stekern: I find l.andi much clearer than l.movhi... the fact that l.movhi also clears the low 16 bits is not obvious at first glance | 08:22 |
stekern | jonibo_: I agree with l.andi, I've used it over l.movhi too, but others seems to have created a de facto "standard" with l.movhi :) | 08:26 |
derRichard | jonibo_: hm, ok. something like cmpxchg would be really nice to have a fast futex implementation. | 10:50 |
jonibo | yes, it sure would... | 10:52 |
derRichard | jonibo_: btw: you asked why clearing r0 in _switch. we have to clear r0 also when swichting tasks. if the kernel switches from taskA to taskB we have to make sure that r0 is clean. is _switch the wrong place? | 11:06 |
jonibo | how could r0 be "incorrect" at that point? | 11:06 |
derRichard | if taskA changes r0 to 1 and a task switch happens | 11:08 |
jonibo | r0 isn't stored for taskA | 11:08 |
jonibo | r0 can only be corrupted in userspace before kernel entry... it should be fixed up on kernel entry only, not elsewhere | 11:09 |
derRichard | so, r0 is cleared on each task swtich? | 11:09 |
jonibo | you don't get a task switch without an exception | 11:09 |
derRichard | ah ok. then it's fine | 11:09 |
jonibo | ok... | 11:09 |
jonibo | I might have missed something, so let me know if you disagree | 11:09 |
jonibo | but I think i'm right :) | 11:10 |
derRichard | you know _much_ more about openrisc than me. so i'll trust you | 11:11 |
-!- Netsplit *.net <-> *.split quits: olofk | 14:20 | |
-!- Netsplit over, joins: olofk | 14:23 | |
jessica1 | Hello. Is there any answer on this http://opencores.org/forum,OpenRISC,0,4661 question? | 20:27 |
jeremybennett | I thought it was solved. The end of the last comment is "build successful, thank you!" | 20:30 |
derRichard | is there a working openrisc target for qemu? | 20:36 |
jeremybennett | derRichard: Not that I know of. There is no pressing requirement for one. It would be an interesting exercise, but it isn't blocking progress elsewhere. | 20:37 |
jeremybennett | If we were starting today, we would probably use QEMU rather than Or1ksim, with CGEN for tool chain development. | 20:37 |
juliusb | i tend to agree on that actually - I was interested in a QEMU port a while back, but really, it's nothing we need urgently | 20:39 |
juliusb | the tool chain would be better helped by the sort of work Pete Gavin is doing | 20:39 |
juliusb | or1ksim is pretty good | 20:40 |
juliusb | although the benefit of qemu for OpenRISC Linux userspace development would be pretty big | 20:40 |
juliusb | that'd make the Linux userspace C library a whole lot easier to test | 20:41 |
jeremybennett | I'm not sure that is true. The problem with testing the C library was that (at the time), Linux was not stable enough, so we had to build an infrastructure with a huge amount of redundancy and restart. | 20:46 |
jeremybennett | It would reduce the compute time though. | 20:46 |
juliusb | well if you're testing the kernel port too, sure you need to test in the full simulator | 20:50 |
juliusb | but I would argue you'd cut a lot of time and effort by running in that emulated user mode | 20:51 |
derRichard | binutils as of today does not build :( | 20:51 |
derRichard | http://paste.opensuse.org/view/raw/46497058 | 20:51 |
derRichard | is this a known problem? | 20:51 |
jeremybennett | derRichard: New one on me | 20:51 |
jeremybennett | juliusb: I'm not convinced by tool chain verification against high level simulators. I worry that you have abstracted so far, you miss some subtleties. | 20:52 |
jeremybennett | But if we were starting again, we'd go that way for sure. | 20:52 |
juliusb | derRichard: yeah I've not seen that either | 20:53 |
derRichard | my buildenv is rather new. gcc 4.6.2 | 20:53 |
jeremybennett | derRichard: It is flex blowing up - do you have all the prerequisites for the tool chain build? | 20:53 |
jeremybennett | Well, GCC does get ever stricter about headers, so it is possible 4.6.2 has broken something. | 20:54 |
jeremybennett | Ideally file a bug and a fix! It is quite likely it is an upstream issue, and there will be a patch shortly. | 20:54 |
derRichard | bah, flex was not installed | 20:55 |
derRichard | ^^ | 20:55 |
derRichard | let's see | 20:55 |
derRichard | jeremybennett: hmm, flex and bison are installed but i get still this error | 21:03 |
jeremybennett | I don't know what the problem is. In my build, it appears in the include directories of the target. | 21:07 |
jeremybennett | But this is the host compiler that is complaining. | 21:07 |
jeremybennett | Do you have sysinfo.h on your host compiler's libraries? | 21:08 |
derRichard | sysinfo.h is a local include | 21:08 |
jeremybennett | Sorry - I don't understand. sysinfo.h is a system header. On my Ubuntu laptop it is in /usr/include/i386-linux-gnu/sys/sysinfo.h | 21:09 |
jeremybennett | Has it gone from 4.6.2? | 21:10 |
derRichard | jeremybennett: sysflex.c does #include "sysinfo.h" | 21:15 |
derRichard | " " vs. < > | 21:15 |
derRichard | and yes, i have sys/sysinfo.h | 21:16 |
derRichard | it comes from glibc-devel | 21:16 |
derRichard | 21:28 | |
derRichard | solved it. a -I../../binutils was missing | 21:35 |
derRichard | donno whether this is an upstream bug or not | 21:36 |
derRichard | *dunno | 21:36 |
jeremybennett | derRichard: Thanks for find that. Would you file a bug? | 22:06 |
derRichard | jeremybennett: sure. where? | 22:08 |
jeremybennett | http://bugzilla.opencores.org/ | 22:09 |
jeremybennett | Julius Baxter and I both track all submissions. If you have a patch, we can roll it in quite quickly. | 22:10 |
derRichard | i took the code from git://openrisc.net/jonas/binutils-svn | 22:14 |
derRichard | does this matter? | 22:14 |
jeremybennett | Jonas maintains his own git repository. I don't know how up to date it is. The official repository is the OpenCores SVN, that is where all the latest patches have been rolled in. | 22:16 |
jeremybennett | You might like to just checkout a copy and see if you still have the same problem. | 22:16 |
jeremybennett | One of the strengths of open source - anyone can run their own fork if they wish to. | 22:17 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!