| --- Log opened Fri May 30 00:00:11 2014 | ||
| poke53281 | blueCmd: my "chroot initramfs /usr/bin/qemu-or1k-static ..." command returns without an error message. Do you know this error. | 00:34 |
|---|---|---|
| poke53281 | it returns from the chroot environment I mean. | 00:47 |
| poke53281 | pastie.org/9236887 | 00:58 |
| poke53281 | I also mounted proc,sys, dev and dev/pts | 01:00 |
| dalias | stekern, i've committed the no-legacy-syscalls stuff for musl, so that's no longer blocking or1k port :) | 01:22 |
| dalias | (the port's bits/syscall.h just needs to ensure that the unsupported SYS_* macros aren't defined) | 01:22 |
| stekern | dalias: nice work! | 03:54 |
| stekern | we don't define __ARCH_WANT_SYSCALL_OFF_T neither though, so it still fails on SYS_sendfile | 03:55 |
| stekern | should be trivial to use sendfile64 instead though | 03:56 |
| stekern | dalias: I guess this would do? http://pastie.org/9237183 | 04:16 |
| dalias | stekern, musl never uses the 32-bit-off_t stuff | 04:29 |
| dalias | src/internal/syscall.h undefs and redefines all the 32-bit-off_t syscalls with 64-bit versions | 04:30 |
| dalias | oh, is that currently wrong for sendfile? | 04:30 |
| dalias | i'll take a look... | 04:30 |
| dalias | bleh. sendfile must not work at all in musl right now then :( | 04:32 |
| dalias | thanks for catching that | 04:34 |
| dalias | hmm, i guess it mildly | 04:37 |
| dalias | hmm, i guess it mildly 'works' on little-endian systems for small offsets | 04:37 |
| dalias | since the upper bits just get ignored | 04:37 |
| dalias | that's probably why it wasn't caught before | 04:38 |
| stekern | ah, right | 05:02 |
| dalias | stekern, how should i credit you in the commit? | 05:05 |
| stekern | ah, no need. but if you must, just add a note that Stefan Kristiansson found it ;) | 05:08 |
| dalias | ok | 05:12 |
| dalias | committed | 05:22 |
| stekern | great, I've found some other fall-outs as well (a missing fork->clone ifdef and fstat->fstat64 so far), but I can send them as proper patches when I've got them sorted out | 05:32 |
| dalias | oh? | 05:34 |
| dalias | where is the fork/clone thing? | 05:34 |
| dalias | fstat is always redefined to fstat64 | 05:34 |
| stekern | http://pastie.org/9237576 | 05:35 |
| dalias | ahhh, i missed vfork.c because it doesn't get compiled on i386 :) | 05:36 |
| dalias | because there's a vfork.s | 05:36 |
| stekern | (fstat) yes, but we don't define stat64 | 05:36 |
| dalias | oh, i see | 05:36 |
| dalias | i can fix that | 05:36 |
| stekern | go ahead ;) | 05:37 |
| dalias | it was just me being lazy and minimizing the ifdef's :) | 05:37 |
| stekern | yeah, I got that | 05:37 |
| dalias | are all of the other ones (like the *32 stuff) ok tho? | 05:38 |
| dalias | and truncate+ftruncate being together | 05:38 |
| stekern | haven't got through everything yet | 05:43 |
| stekern | ;) | 05:43 |
| stekern | dalias: there's a SYS_stat left in src/stat/fstat.c | 05:44 |
| dalias | oh i thought i'd gotten that one | 05:49 |
| dalias | wonder how it passed my test | 05:49 |
| dalias | stekern, committed | 06:08 |
| stekern | dalias: great, then it's only one issue with lseek left ;) | 06:16 |
| dalias | oh? | 06:20 |
| dalias | what's the issue? | 06:20 |
| stekern | it was an issue on my side, I had defined SYS__llseek to SYS_llseek | 06:22 |
| dalias | hmm, it looks like the kernel ppl use llseek as the name now instead of _llseek | 06:25 |
| dalias | but it really doesn't make much difference as long as it's internally consistent | 06:25 |
| stekern | yup | 06:26 |
| stekern | the or1k port compiles now, so I guess it's ready to take out for a spin then | 06:27 |
| dalias | nice | 06:27 |
| dalias | what's the status on atomics? | 06:27 |
| stekern | they are now in the arch spec, and I've updated implementations/simulators and binutils | 06:32 |
| stekern | and musl use those | 06:32 |
| dalias | nice | 06:33 |
| dalias | btw now that you've got it building successfully, trying libc-test (http://nsz.repo.hu/git/?p=libc-test) may be a good next step to see if anything is obviously broken | 06:35 |
| dalias | it's not really easy to cross-compile yet though because the same makefile that compiles the tests also wants to run them | 06:36 |
| stekern | ok, I'll take a look at that, thanks for the tip | 06:36 |
| dalias | i dunno how well it's working yet or how much time you have to spend on it, but it'll probably be at least another week to 10 days before we're ready to release 1.1.2, and if you have anything even experimental-quality ready by then it'd be cool to include it in the release | 06:39 |
| stekern | let's see how rainy the weekend is ;) | 06:40 |
| dalias | stekern, whenever the port does make it in, we can use it as some publicity for both projects too, btw | 06:41 |
| stekern | absolutely | 06:41 |
| stekern | olofk already made a note about the musl port, and that made it to slashdot =) | 06:41 |
| stekern | (there was other stuff in that note too though) | 06:42 |
| simoncook | stekern: I don't suppose you've looked at LLVM much lately, or would have any thoughts on http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073304.html | 08:23 |
| stekern | simoncook: can't say I have from the top of my head | 08:26 |
| simoncook | ok, thanks | 08:28 |
| blueCmd | poke53281: try with http://openrisc.debian.net/qemu-or1k-static.atomic | 08:29 |
| blueCmd | I should get around to update the told binary and the checksums | 08:30 |
| inigom | we are getting this when intalling fusesoc : | 10:00 |
| inigom | make[2]: *** No rule to make target `fusesoc/section/__init__.py', needed by `install-sectionPYTHON'. Stop. | 10:00 |
| inigom | make[2]: Leaving directory `/home/inigom/Desktop/pinksoc/fusesoc' | 10:00 |
| inigom | make[1]: *** [install-am] Error 2 | 10:00 |
| inigom | make[1]: Leaving directory `/home/inigom/Desktop/pinksoc/fusesoc' | 10:00 |
| inigom | make: *** [install-recursive] Error 1 | 10:00 |
| stekern | inigom: I guess this needs to go: https://github.com/olofk/fusesoc/blob/master/Makefile.am#L22 | 10:02 |
| inigom | there is no section anymore , what do I do ? | 10:06 |
| inigom | we deleted the line and it worked | 10:08 |
| stekern | that's what you do | 10:11 |
| stekern | ;) | 10:11 |
| inigom | but now when building de0_nano | 10:12 |
| inigom | Traceback (most recent call last): | 10:12 |
| inigom | File "/usr/local/bin/fusesoc", line 232, in <module> | 10:12 |
| inigom | run(parsed_args) | 10:12 |
| inigom | File "/usr/local/bin/fusesoc", line 167, in run | 10:12 |
| inigom | cm.add_cores_root(config.cores_root) | 10:12 |
| inigom | File "/usr/local/lib/python2.7/dist-packages/fusesoc/coremanager.py", line 63, in add_cores_root | 10:12 |
| inigom | self.load_cores(os.path.expanduser(p)) | 10:12 |
| inigom | File "/usr/local/lib/python2.7/dist-packages/fusesoc/coremanager.py", line 52, in load_cores | 10:12 |
| inigom | self.load_core(d, f) | 10:12 |
| inigom | File "/usr/local/lib/python2.7/dist-packages/fusesoc/coremanager.py", line 30, in load_core | 10:12 |
| inigom | self._cores[name] = Core(file) | 10:12 |
| inigom | File "/usr/local/lib/python2.7/dist-packages/fusesoc/core.py", line 34, in __init__ | 10:12 |
| inigom | for s in section.SECTION_MAP: | 10:12 |
| inigom | AttributeError: 'module' object has no attribute 'SECTION_MAP' | 10:12 |
| stekern | http://pastie.org/9238927 | 10:14 |
| stekern | you'll need that | 10:14 |
| inigom | doesn't work . Does it hurt if we go back to f0364db? | 10:25 |
| stekern | define 'doesn't work' | 10:26 |
| stekern | nvm, I see it here too | 10:28 |
| kyrre_ | Having an issue with byte alignment with the compiler | 10:28 |
| inigom | File "/usr/local/lib/python2.7/dist-packages/fusesoc/coremanager.py", line 30, in load_core | 10:28 |
| inigom | self._cores[name] = Core(file) | 10:28 |
| inigom | File "/usr/local/lib/python2.7/dist-packages/fusesoc/core.py", line 34, in __init__ | 10:28 |
| inigom | for s in section.SECTION_MAP: | 10:28 |
| inigom | AttributeError: 'module' object has no attribute 'SECTION_MAP' | 10:28 |
| stekern | inigom: yes, I see that here too | 10:29 |
| stekern | you can roll back, no problem | 10:29 |
| stekern | kyrre_: tell us more | 10:29 |
| kyrre_ | im writing a string to uart, it puts a address that ends with 6 in R3 when calling uartprint | 10:30 |
| kyrre_ | so when trying to read this memory it throws and align exception | 10:30 |
| stekern | what uartprint is that? | 10:32 |
| kyrre_ | uart_print_str in freertos | 10:33 |
| stekern | why isn't it reading things byte-by-byte? | 10:33 |
| kyrre_ | it takse a char* as arg | 10:33 |
| kyrre_ | and uses uart_putc to print the string | 10:33 |
| stekern | ok, it doesn't sound like that would read anything at larger granularity than 1 byte | 10:34 |
| kyrre_ | nope | 10:34 |
| stekern | so, on what does it fail with an unaligned exception then? | 10:36 |
| kyrre_ | but it starts to read the first byte at 0x93c6 | 10:36 |
| kyrre_ | shouldnt it be 4 8 c 0 ? | 10:36 |
| stekern | blueCmd: ^^ can you take a look at inigoms problem? | 10:36 |
| stekern | kyrre_: 32-bit accesses need to be 4 byte aligned, 16-bit accesses need to be 2 byte aligned and 8-bit 1 byte aligned | 10:38 |
| kyrre_ | ok, so the error im experiencing shoudnt be connected to the start adress of that char* ? | 10:39 |
| stekern | no, that address should be fine, as long as its only access with l.lb*/l.sb or l.lh*/l.sh | 10:40 |
| stekern | (since it was 2-byte aligned) | 10:41 |
| kyrre_ | ok, after a closer look it loads per byte | 10:46 |
| kyrre_ | wb | 10:47 |
| kyrre_ | it loads per byte | 10:47 |
| kyrre_ | so, guess ill have to keep digging | 10:47 |
| kyrre_ | looks like its because of my changes to or1ksim | 10:52 |
| kyrre_ | running freertos on a clean or1ksim, no align exceptions | 10:52 |
| kyrre_ | nope | 10:55 |
| kyrre_ | it only happens when i run or1ksim through gdb | 10:55 |
| stekern | did you get the other crash that was related to your machine sorted out btw? | 10:58 |
| kyrre_ | ye | 11:00 |
| kyrre_ | was because of miss assumptions on where we put our sim.cfg | 11:01 |
| kyrre_ | and me not double checking the command you posted | 11:01 |
| stekern | oh, right... I forgot that | 11:02 |
| stekern | wonder what makes it different when you run it in gdb | 11:03 |
| stekern | otoh I don't many others have done that | 11:03 |
| kyrre_ | not sure either, but it enters a loop at 0x600 0x604 | 11:07 |
| kyrre_ | using the same sim.cfg file for gdb and regular sim | 11:08 |
| blueCmd | stekern: right, that's because we use Makefiles ;) | 11:35 |
| blueCmd | I'm heading out for lunch now, but I'll give inigom a patch after I get back. basically the 'section' part of Makefile.am needs to be removed and 'section.py' added to the fusesoc_PYTHON section at the top, and then regen everything | 11:36 |
| stekern | blueCmd: that's not enough, I already done a pull-request that does that | 11:37 |
| stekern | it doesn't even work if you run it from the fusesoc dir | 11:38 |
| kyrre_ | the cause of gdb changing behavior seems to be because i added a breakpoint at the location and for some reason that fucked things up | 11:48 |
| inigom | verilator does not work if there are scanf in the code | 11:49 |
| stekern | inigom: again, define 'does not work' | 11:49 |
| stekern | the vanilla verilator stuff that's in orpsoc-cores doesn't read any uart input, so I'm not surprised it doesn't work there | 11:50 |
| inigom | stekern this explains it | 11:51 |
| blueCmd | stekern: works for me :S | 13:06 |
| blueCmd | well, up until the 'make' command is ran | 13:06 |
| blueCmd | since I don't have quartus installed it doesn't go further | 13:06 |
| blueCmd | ah, I didn't do make install - I only tried with bin/fusesoc | 13:07 |
| blueCmd | stekern: cannot reproduce | 13:11 |
| stekern | blueCmd: you don't get this? http://pastie.org/9239530 | 13:12 |
| blueCmd | stekern: nope | 13:13 |
| blueCmd | where is your pwd? | 13:13 |
| stekern | stefan@wonka:~/openrisc/orpsocv3/build-de0_nano$ | 13:13 |
| blueCmd | I'm trying to run the thing in another directory than the fusesoc one and it fails with that it cannot find de0_nano | 13:14 |
| stekern | well... do you have fusesoc.conf there? | 13:14 |
| blueCmd | ah no | 13:14 |
| blueCmd | that should be global IMO | 13:15 |
| stekern | you mean, it should use a default one if it can't find one? I agree | 13:16 |
| blueCmd | stekern: I suspect that the old section/ dir is somewhere | 13:16 |
| blueCmd | where it shouldn't be | 13:16 |
| blueCmd | stekern: yes | 13:16 |
| blueCmd | stekern: doing make install should put a global one in <prefix>/etc/fusesoc.conf and use that if it doesn't find a local one | 13:16 |
| stekern | what should be in that one then? | 13:17 |
| stekern | there's probably the old section/ dir in the old install path | 13:17 |
| blueCmd | blast it! | 13:20 |
| stekern | did that, now it works | 13:22 |
| stekern | ...still fails when I run it from the src dir though | 13:22 |
| stekern | it's a bit unnice that installing it now breaks it for all old users too | 13:23 |
| blueCmd | yeah, that's a pity | 13:23 |
| stekern | ok... make distclean doesn't acually clean .pyc | 13:25 |
| stekern | so the old section/section.pyc was lingering around in my src dir | 13:26 |
| stekern | removing that and everything works | 13:27 |
| stekern | my pull req is still valid though | 13:27 |
| blueCmd | stekern: yes, it's very pretty as well! | 13:40 |
| blueCmd | the pull request that is | 13:40 |
| wallento | stekern: did you dump your snoop extensions for the store buffer somehwere? | 14:23 |
| stekern | wallento: I might have dumped them in my mor1kx, if not I can do that in thevening | 14:28 |
| wallento | yes, that would be nice, I will also dump my current snoop logic, still faces flaws | 14:29 |
| stekern | blueCmd: just like it's author! | 14:31 |
| stekern | wallento, jupp, I'd like to enable dcache ;) | 14:31 |
| wallento | well, yeah, I can enable it now but still fails after some time. I am not sure it may be due to the store buffer. At the moment I heavily document it in the hope I find the flaw, nevertheless I want to give a snooping write buffer a try | 14:34 |
| wallento | :) | 14:34 |
| inigom | Hi again. I have been running simple code in de0_nano. I have used or1200 and mor1kx. The first one works well but the last one is not working properly. I have tried to simulate mork1x in verilator nad works fine! Do someone have tried the mork1x in the de0_nano or on a board?? | 14:47 |
| blueCmd | yes | 14:48 |
| blueCmd | a lot of people has :) | 14:48 |
| blueCmd | have* | 14:49 |
| blueCmd | inigom: what are the symptoms? have you tried to decrease the clock frequency? what are your timing constraints? and so o | 14:49 |
| blueCmd | and so on* | 14:49 |
| olofk | FuseSoC already looks for a fusesoc.conf in /etc/fusesoc.conf, $XDG_CONFIG_HOME/fusesoc/fusesoc.conf and $PWD/fusesoc.conf | 15:23 |
| olofk | And you can manage without a config if you run it with fusesoc --add-cores-root=/path/to/cores | 15:24 |
| olofk | Sorry, just --cores-root=/path/to/cores | 15:24 |
| stekern | inigom: again, define 'not working'. that setup works fine here. | 15:38 |
| inigom | no timing violations as fasr we can see . | 15:46 |
| inigom | just switch or1200 with mor1kx and the uart no longer works | 15:47 |
| inigom | is it possible to tell fusesoc to fetch a previous commit of a core ? | 15:50 |
| inigom | symptoms is we get nothing from serial port | 15:51 |
| inigom | printfs don't come out | 15:52 |
| inigom | but if we use or1200 they do | 15:52 |
| stekern | inigom: that definitely works here... | 15:52 |
| inigom | it was workinh here some weeks back | 15:53 |
| stekern | I tested the latest versions of both orpsoc-cores and mor1kx yesterday on de0_nano, and it was printing out stuff on the uart | 15:54 |
| stekern | yes, you can set a commit in the provider section | 15:55 |
| stekern | or just remove the provider section and put symlinks to the related dirs from a normal git checkout | 15:55 |
| stekern | is the program running properly apart from no uart output? | 15:58 |
| inigom | we think so from gdb it behaves well | 16:01 |
| stekern | if you change the version in the provider section, remember to wipe the cache then | 16:02 |
| inigom | yes | 16:02 |
| blueCmd | olofk: so then the bug is that it isn't installed in the search path. also, you should use <prefix>/etc/fusesoc.conf (or etclibdir or whatever it's called from autoconf) | 16:07 |
| stekern | blueCmd: you just have to put your default fusesoc.conf there | 16:08 |
| inigom | instead of version I can just put the hash ? | 16:09 |
| blueCmd | stekern: yeah, but make install should install everything | 16:09 |
| stekern | inigom: yes | 16:11 |
| stekern | blueCmd: but fusesoc don't know what you want as default | 16:12 |
| stekern | maybe it could put http://pastie.org/9239991 as an example | 16:32 |
| stekern | but does relative paths like that work in /etc/fusesoc.conf | 16:32 |
| inigom | witht the mor1kx hash d510ac3babfa4f66887cb870e2b28f656b465ad2 it works! | 16:33 |
| stekern | so you are saying that you've bisected it down to: https://github.com/openrisc/mor1kx/commit/9e5a414e35cee893d46d4a7442f2b80e32619b82 | 16:38 |
| stekern | there was some issues with that commit, that I fixed in https://github.com/openrisc/mor1kx/commit/7db7a341f9886851fb18d6c4a1a0b00de7016f24 | 16:39 |
| stekern | ...but all this is weird, what's different in our setups? | 16:40 |
| stekern | can you give me your .elf? | 16:40 |
| blueCmd | stekern: I have some ideas for that as well, but that's for later | 16:41 |
| wallento | stekern: are you available for a chat on sunday? | 16:41 |
| inigom | sterkern: there you have it | 16:42 |
| inigom | stekern: i'm sending you the elf | 16:43 |
| wallento | I think I am approaching the problem, but maybe it is easier to ask you some questions regarding the LSU and cache. I think I got most of it now, but there might be some larger changes I want you to discuss before actually doing them | 16:43 |
| wallento | today I learned the read checking starts before req_i ;) | 16:44 |
| poke53281 | thanks blueCmd: That did the job. | 16:44 |
| stekern | wallento: ping me on sunday, I'll probably be around | 16:44 |
| wallento | perfect, I will check then, cya | 16:45 |
| stekern | inigom: dcc send, ages since I used that last... wonder where the file went :) | 16:46 |
| stekern | inigom: H W | 16:48 |
| stekern | works fine here... | 16:48 |
| inigom | here too but only with that hash | 16:50 |
| inigom | we still have to find the last hash where it still works | 16:50 |
| poke53281 | blueCmd: next problem with the second stage of debootstrap: "configuring libc-bin ..." "Failure while configuring required packages." | 17:00 |
| poke53281 | Hmm, "Errors were encountered while processing: initscripts" | 17:10 |
| olofk | blueCmd: No, you're right, hardcoding to /etc is not correct for prefixed build. But I don't think anyone actually used that | 17:51 |
| olofk | And I don't like to put files in /etc unless necessary, so $PWD or $XDG_CONFIG_HOME/fusesoc are the preferred locations | 17:52 |
| olofk | /etc are mostly for system-wide installations of orpsoc-cores | 17:52 |
| olofk | But I have thought about adding a setup/init step that fetches orpsoc-cores and adds a fusesoc.conf. Like a wizard | 17:53 |
| olofk | atgreen: Hi. I've seen you lurking around here lately. I wanted to talk binutils verilog backend with you :) | 20:15 |
| olofk | juliusb: Have you done any workshops, like chiphack, with fusesoc where you added extra peripherals? | 20:33 |
| atgreen | olofk, any time. except now :) | 20:48 |
| atgreen | I'm in the middle of a move (packing/cleaning) | 20:49 |
| olofk | atgreen: Ah I see. They really should invent a way to move in somewhere without the hassle of moving out | 21:04 |
| olofk | But just give me a shout when you're more available | 21:05 |
| atgreen | olofk, I have a few min now actually - still there? | 21:33 |
| * atgreen takes a break from cleaning | 21:33 | |
| --- Log closed Sat May 31 00:00:13 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!