| --- Log opened Thu Jan 30 00:00:16 2014 | ||
| blueCmd | ams: sorry, they didn't have anything :( | 02:17 |
|---|---|---|
| jonibo | stekern: yes... it's like this... i've rewritten the syscall handling for Linux to be more efficient, and as a result its possible to follow the regular function call ABI for all syscalls... this means that the arg registers (r3-r8) are clobbered by the call | 06:45 |
| jonibo | ...but the sad thing is that it still doesn't work... things only work if r3-r8 are restored upon return to userspace | 06:45 |
| jonibo | anyway, like I mentioned before, it may also be that we are missing the "memory" clobber on the syscall | 06:45 |
| jonibo | I haven't been able to nail down exactly what is happening | 06:46 |
| stekern | jonibo: ok, thanks for the explanation. | 06:48 |
| jonibo | sure, hope it helps somehow... i'll try to push the syscall rewrite to somewhere public and let you know so you can see it for yourself | 06:49 |
| stekern | I thought I was seeing something similar yesterday on the eco32 port I'm working on, but it had a much more natural explanation. I had forgot to add the incoming registers to the outgoing list in the inline asm that does the syscall instruction. | 06:50 |
| jonibo | aha... yeah, that bit is a bit tricky on GCC since you can't have the same regs in both lists (params and clobbers) | 06:51 |
| stekern | yeah, I don't get why that restriction exists, but there is probably a good technical explanation. | 06:52 |
| stekern | it would feel a lot more natural to mark them as clobbered than as set registers | 06:54 |
| stekern | but if it's in fact the call-site that clobbers r3-r8 in your case, it should be "easy" to find it. especially if you know which syscall cause it. | 06:57 |
| olofk_ | blueCmd: The first commit by pgavin in the or1k-src is really a copy of the changes that juliusb did in his or1k-binutils repo. juliusb has probably taken some of that stuff from OpenCores SVN, which is why the ChangeLog entries doesn't show the full story | 07:16 |
| olofk_ | Luckily, the history is all fine after pgavin's initial commit, so the tricky part is just to identify where all the changes in that commit come from | 07:19 |
| jonibo | stekern: I think you _do_ want to mark them as clobbered... it allows the optimizer to work better than if it needs to treat the contents of those regs as important on return | 07:24 |
| jonibo | there's some macro trickery done in most other arches to do just this | 07:25 |
| stekern | jonibo: but you can't mark them as clobbered, (as you said earlier) since they are in the incoming parm list | 07:31 |
| jonibo | stekern: no, that's the trick... see the macros that are set up in uClibc where the param regs are adds to the input list and teh unused param regs are added to the clobbered list | 08:16 |
| jonibo | the thing that, I think, is missing is the "memory" clobber... other arches seem to need that so I'm sure we do to | 08:16 |
| stekern | jonibo: yes, I know about the macro trickery, I'm using that in the eco32 too: https://github.com/skristiansson/eco32-uClibc/blob/master/libc/sysdeps/linux/eco32/bits/syscalls.h | 08:21 |
| jonibo | yeah, looks good... then I don't understand why you need the input regs in the ouput reg list, too...??? | 08:23 |
| stekern | but I think we are just saying the same thing, I was just commenting on that it feels odd that you can't add incoming registers to the clobber list, but have to add them to the outgoing list to achieve that | 08:23 |
| jonibo | ah, no... input regs are always clobbered... | 08:24 |
| stekern | no | 08:24 |
| stekern | at least gcc disagrees with that statement, it happily used r5 (and incoming reg) after the trap instruction. | 08:25 |
| stekern | and from what I read yesterday from the gcc inline asm documentation, that's expected behaviour | 08:26 |
| jonibo | interesting... i may have misunderstood that... I don't think openrisc uClibc does this properly then | 08:26 |
| stekern | s/and incoming reg/and incoming reg | 08:26 |
| jonibo | and that could explain the "bug" I described earlier | 08:26 |
| stekern | it does, the incoming regs are in the out list | 08:27 |
| jonibo | i'll peek at the docs now | 08:27 |
| jonibo | on openrisc | 08:27 |
| jonibo | ? | 08:27 |
| jonibo | really... ok | 08:27 |
| stekern | yes | 08:27 |
| jonibo | hmm... ok, well at least its correct then... I guess it's just my head that's confused :) | 08:27 |
| stekern | as I said, it's IMO counter-inuitive ;) | 08:28 |
| jonibo | correct you are: "There is no way for you to specify that an input operand is modified without also specifying it as an output operand." | 08:30 |
| jonibo | and I agree, it's not very intuitive | 08:30 |
| ams | blueCmd: thanks! | 08:56 |
| -!- jts_ is now known as jtdesousa | 11:32 | |
| blueCmd | jonibo: I think I have memory clobber set on the syscalls in glibc | 13:17 |
| jonibo | blueCmd: good... | 13:33 |
| jonibo | i'll let you know if I push the patches and you can see if thigns work there | 13:33 |
| jonibo | won't be before next week, though, as I won't have time to look into anything before then | 13:33 |
| blueCmd | jonibo: http://ef0ae0159a6a0cf4.paste.se/ | 13:40 |
| blueCmd | that is how it's done in glibc currently | 13:40 |
| blueCmd | jonibo: cool, i'll be happy to test it | 13:40 |
| blueCmd | the this code is used to generate the ASM_ things: http://9b221a987561bb74.paste.se/ | 13:42 |
| blueCmd | then this* | 13:42 |
| jonibo | looks good | 14:02 |
| maxpaln | Ok, making good progress - but coming unstuck on understanding how the cache between the Wishbone and DDR2 module is used. | 14:06 |
| maxpaln | For example, the simulation starts by pulling data from the SPI Flash and loading it into memory | 14:06 |
| maxpaln | when the first byte arrives from the SPI Flash the cache controller decides to read from the DDR2 memory and as far as I can see it doesn't write the byte (from SPI Flash) into the cache for writeback! | 14:07 |
| maxpaln | Not being familiar with how cache's work I am diving into this to try and get a better understanding - | 14:07 |
| maxpaln | but wondered if anyone has any experience of this part of the design - maybe give me a top level view of how the mechanism should work | 14:08 |
| stekern | blueCmd: that's exactly how it's done in uclibc as well | 14:09 |
| stekern | minus the memory clobber | 14:09 |
| stekern | maxpaln: are you speaking about the CPU cache or some other cache? | 14:10 |
| maxpaln | Not the CPU cache - the cache that is part of the DDR2 wishbone interface | 14:11 |
| maxpaln | there is a 4Kbyte cache that sits between the wishbone and the ddr2 controller. | 14:11 |
| stekern | if you are speaking about the cache that I put in the SVN version of the atlys board, you probably will be better of doing something like I did here instead: http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/xilinx/atlys/rtl/verilog/xilinx_ddr2/xilinx_ddr2_if.v | 14:12 |
| maxpaln | ok, that's interesting - a different implementation | 14:14 |
| maxpaln | The version I am currently looking at is here: http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/xilinx/s3adsp1800/rtl/verilog/xilinx_s3adsp_ddr2/xilinx_s3adsp_ddr2_if.v | 14:15 |
| stekern | yes, I first did the cache one for atlys, which was inspired by an implementation done by juliusb. But when I hooked up a framebuffer to that, there was this issue with the cache constantly being invalidated, which made the performance unacceptable. | 14:16 |
| maxpaln | ah, ok | 14:16 |
| maxpaln | so you think the version you just pointed out is the way to go? | 14:16 |
| stekern | and, I think the non-cache version is slightly simpler, but the xilinx interfaces makes it look complicated | 14:16 |
| stekern | (+ it could probably be improved, it was one of the first things I ever wrote in verilog) | 14:18 |
| maxpaln | :-) | 14:18 |
| maxpaln | I'm just looking at it now - see if I can see a sensible way to map it to our memory controller (which happens to be very similar to the version used in Julius' implementation (and as such the Atyls board version)) | 14:19 |
| stekern | I think the main reason for juliusb to doing the whole cache thing was that he had to map 128-bit of DDR2 data on the virtex5 board he had onto the 32-bit bus | 14:19 |
| stekern | and then he just copied that for the s3adsp board | 14:20 |
| maxpaln | hmmm, yep - I have a similar situation with our board | 14:20 |
| maxpaln | the DDR3 data is 64-bit but could easily be 128-bit if a wider memory interface is used | 14:20 |
| blueCmd | stekern: yes I used a lot of code from uclibc for certain parts, so that might be the case | 14:20 |
| stekern | but, you should be able to adapt that to my "improved" version too | 14:21 |
| blueCmd | stekern: the memory clobber part I think I reasoned that syscalls can take a pointer and modify the value it points to, so clearly it clobbers the memory as well | 14:21 |
| maxpaln | I'm taking a look now - seeing if I can see a neat way to do it without changing the code too much! | 14:21 |
| stekern | blueCmd: yes, and from what I understand, the memory clobber prevents gcc from moving the instruction around too, which I guess is something we want | 14:22 |
| stekern | anyway, last minute of work before 1 month of vacation, bbl ;) | 14:22 |
| maxpaln | aw, and I was hoping to pick your brains as I work through this! grrr :-) | 14:25 |
| maxpaln | off anywhere particularly jealousy inducing? | 14:26 |
| jonibo | stekern: enjoy your vacation! | 14:27 |
| ams | i hate france ... | 14:35 |
| omoc | hi | 14:38 |
| omoc | whats the status of the llvm openrisc port? | 14:38 |
| jonibo | I think you just missed LLVM-stekern... he'll be back in a month :) | 14:39 |
| omoc | I just found some github repos but those have not been touched in quite a while | 14:39 |
| jonibo | I think it all worked... | 14:39 |
| jonibo | haven't tried it myself, though | 14:39 |
| omoc | hmm okay, I guess I just have to try myself then | 14:40 |
| jonibo | i think you'll find it works | 14:40 |
| blueCmd | omoc: what do you need? | 14:40 |
| omoc | just curious, we may want to use it in a university project and if you touch the backend, gcc is not very pleasent to work with :) | 14:42 |
| blueCmd | well, then missing feature suddently is a good thing! :) | 14:44 |
| blueCmd | omoc: it apparently supports dynamic linking acording to a forum post by stekern, so there's that | 14:47 |
| simoncook | omoc: the status of the llvm port is I haven't pulled in the latest upstream changes for the last 4 months or so but it was up to date as of then | 14:48 |
| omoc | nice, thanks | 14:49 |
| omoc | changes of the past 4 month? the github repo I found shows the last change was a year ago | 14:50 |
| omoc | :) | 14:50 |
| simoncook | try https://github.com/simonpcook/llvm-or1k I seemingly haven't been pushing my changes to the openrisc/ repository that often | 14:52 |
| stekern | maxpaln: Thailand, but don't worry I'll be around ;) | 14:56 |
| maxpaln | stekern: definitely jealous! As I drown in the wettest January on record in the UK...... | 14:56 |
| stekern | simoncook: don't be afraid of pushing them there ;) | 15:05 |
| simoncook | i will do, ill try and merge in the last 4 months of changes first and then push a nice up to date llvm/clang | 15:08 |
| _franck_web_ | ams: what's up with france ? | 15:19 |
| _franck_web_ | :) | 15:19 |
| blueCmd | jonibo: did you receive my patches btw? | 15:34 |
| jonibo | really superficially... haven't had any real time to do openrisc stuff for a while | 15:34 |
| jonibo | they looked good, though | 15:34 |
| jonibo | i intend to throw them onto master next week | 15:34 |
| jonibo | sorry, read "review" where you wrote "receive" :) | 15:35 |
| stekern | omoc: to elaborate on what simoncook said, the port as I left it a year ago was pretty much complete, I could compile a working linux, uclibc and busybox with it | 15:35 |
| jonibo | yes, I received them... even looked at them... superficially :) | 15:35 |
| jonibo | Linux doesn't build with llvm :p | 15:36 |
| stekern | openrisc linux does ;) | 15:36 |
| blueCmd | jonibo: great! I just wanted to know if I sent them to the correct place. couldn't find them by googling, which I usually can | 15:37 |
| stekern | we're superior than the others | 15:37 |
| jonibo | blueCmd: yeah, sorry, my fault for not being responsive | 15:37 |
| ams | _franck_web_: people don't have places for me to stay at ... :-) | 15:37 |
| jonibo | stekern: I knew that already ;) | 15:37 |
| blueCmd | jonibo: np :) | 15:37 |
| blueCmd | stekern: does it have TLS and DWARF2 support!? | 15:38 |
| blueCmd | that is the single most important question | 15:38 |
| stekern | blueCmd: no, that's actually missing | 15:39 |
| blueCmd | pff, how can you even call it a compiler then? | 15:40 |
| blueCmd | basically useless... | 15:40 |
| blueCmd | :P | 15:40 |
| stekern | but we didn't have tls support when I worked on it ;) | 15:40 |
| ams | anyone used airbnb here? | 15:41 |
| blueCmd | yeah I have actually been meaning to implement it in LLVM, but it's quite far down on my list | 15:41 |
| stekern | I thought it'd be your responsibility to add the support across the tools, so patches welcome =) | 15:41 |
| stekern | heh, it's too slow writing on this phone, you beat me | 15:42 |
| jonibo | who's going to fosdem this weekend? | 15:42 |
| stekern | I would have if it didn't clash with my thailand trip | 15:43 |
| ams | jonibo: some gnu hackers are going . | 15:43 |
| jonibo | i meant from this group, of course :p | 15:44 |
| jonibo | i kind of figured I'd run into a GNU hacker or two down there | 15:44 |
| jonibo | i'll be around in any case... i'll be wearing my "South Pole" attire, if somebody feels like saying "hi" | 15:44 |
| jonibo | there'll be a couple of others from South Pole, but I'm easy to recognize... the stunning good looks and all | 15:45 |
| blueCmd | jonibo: http://img.costumecraze.com/images/vendors/rasta/7139-large.jpg | 15:45 |
| blueCmd | that's a south pole attire | 15:45 |
| jonibo | blueCmd: something along those lines, yeah :) | 15:45 |
| ams | jonibo: you at south pole? coolies... | 15:45 |
| blueCmd | yeah, south pool is pretty cool | 15:45 |
| jonibo | blueCmd: it mostly scares me how quickly you dug up that photo... | 15:45 |
| ams | jonibo: know giuseppe scrivano? | 15:45 |
| blueCmd | pole* | 15:46 |
| blueCmd | jonibo: haha | 15:46 |
| jonibo | ams: yes I do... I employed him for a while | 15:46 |
| blueCmd | ams: apparently -48C there now | 15:46 |
| * blueCmd is hillarious | 15:46 | |
| ams | jonibo: ah! | 15:46 |
| ams | blueCmd: some regions had -90 .. though i think that was north pole .. | 15:46 |
| ams | jonibo: you guys looking for people? | 15:46 |
| jonibo | yes we are | 15:47 |
| jonibo | always on the lookout for the right people | 15:47 |
| jonibo | good experience with embedded Linux | 15:47 |
| jonibo | or good sysadmins | 15:47 |
| jonibo | or the mythical "good salesman who likes to get his hands dirty building servers" | 15:47 |
| ams | nifty ... will make a note in my notebook .. will be looking for work after august .. | 15:47 |
| jonibo | cool | 15:47 |
| ams | jonibo: you looking for contracters, or full time people? onsite, or off-site | 15:48 |
| jonibo | full time, mainly | 15:48 |
| jonibo | onsite/offsite depends on the role we determine for the employee... it's a mixed bag, currently | 15:48 |
| ams | fair enough ... | 15:48 |
| blueCmd | jonibo: you have a sarskrivning on the "Rymdprotokol" section, http://southpole.se/services.php?subpage=services_embedded_reference - my eyes are bleeding | 15:48 |
| ams | jonibo: i'm planning on moving to uppsala/stockholm region after a small stint in paris .. currently in gothenburg ... | 15:49 |
| jonibo | yeah, I think our web guy's not a grammar nazi | 15:49 |
| jonibo | ams: aha.. cool | 15:49 |
| omoc | 00:27 here, happy new year ;) | 16:27 |
| ams | omoc: you are ... 30 days late .. | 16:33 |
| omoc | nope, chinese new year | 16:35 |
| omoc | we are going from the year of the snake to the year of the horse | 16:35 |
| olofk | Happy new horse! ...or what is one supposed to say? | 18:34 |
| olofk | ams: I've used airbnb a few times. Have been great | 18:41 |
| blueCmd | never liked that snake anyway | 20:55 |
| stekern | The year of the snake sounds so much cooler than the year of the horse | 22:54 |
| stekern | and apparently it's a wooden horse | 22:56 |
| --- Log closed Fri Jan 31 00:00:18 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
