IRC logs for #openrisc Friday, 2014-05-30

--- Log opened Fri May 30 00:00:11 2014
poke53281blueCmd: my "chroot initramfs /usr/bin/qemu-or1k-static ..." command returns without an error message. Do you know this error.00:34
poke53281it returns from the chroot environment I mean.00:47
poke53281I also mounted proc,sys, dev and dev/pts01:00
daliasstekern, 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
stekerndalias: nice work!03:54
stekernwe don't define __ARCH_WANT_SYSCALL_OFF_T neither though, so it still fails on SYS_sendfile03:55
stekernshould be trivial to use sendfile64 instead though03:56
stekerndalias: I guess this would do?
daliasstekern, musl never uses the 32-bit-off_t stuff04:29
daliassrc/internal/syscall.h undefs and redefines all the 32-bit-off_t syscalls with 64-bit versions04:30
daliasoh, is that currently wrong for sendfile?04:30
daliasi'll take a look...04:30
daliasbleh. sendfile must not work at all in musl right now then :(04:32
daliasthanks for catching that04:34
daliashmm, i guess it mildly04:37
daliashmm, i guess it mildly 'works' on little-endian systems for small offsets04:37
daliassince the upper bits just get ignored04:37
daliasthat's probably why it wasn't caught before04:38
stekernah, right05:02
daliasstekern, how should i credit you in the commit?05:05
stekernah, no need. but if you must, just add a note that Stefan Kristiansson found it ;)05:08
stekerngreat, 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 out05:32
daliaswhere is the fork/clone thing?05:34
daliasfstat is always redefined to fstat6405:34
daliasahhh, i missed vfork.c because it doesn't get compiled on i386 :)05:36
daliasbecause there's a vfork.s05:36
stekern(fstat) yes, but we don't define stat6405:36
daliasoh, i see05:36
daliasi can fix that05:36
stekerngo ahead ;)05:37
daliasit was just me being lazy and minimizing the ifdef's :)05:37
stekernyeah, I got that05:37
daliasare all of the other ones (like the *32 stuff) ok tho?05:38
daliasand truncate+ftruncate being together05:38
stekernhaven't got through everything yet05:43
stekerndalias: there's a SYS_stat left in src/stat/fstat.c05:44
daliasoh i thought i'd gotten that one05:49
daliaswonder how it passed my test05:49
daliasstekern, committed06:08
stekerndalias: great, then it's only one issue with lseek left ;)06:16
daliaswhat's the issue?06:20
stekernit was an issue on my side, I had defined SYS__llseek to SYS_llseek06:22
daliashmm, it looks like the kernel ppl use llseek as the name now instead of _llseek06:25
daliasbut it really doesn't make much difference as long as it's internally consistent06:25
stekernthe or1k port compiles now, so I guess it's ready to take out for a spin then06:27
daliaswhat's the status on atomics?06:27
stekernthey are now in the arch spec, and I've updated implementations/simulators and binutils06:32
stekernand musl use those06:32
daliasbtw now that you've got it building successfully, trying libc-test ( may be a good next step to see if anything is obviously broken06:35
daliasit's not really easy to cross-compile yet though because the same makefile that compiles the tests also wants to run them06:36
stekernok, I'll take a look at that, thanks for the tip06:36
daliasi 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 release06:39
stekernlet's see how rainy the weekend is ;)06:40
daliasstekern, whenever the port does make it in, we can use it as some publicity for both projects too, btw06:41
stekernolofk 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
simoncookstekern: I don't suppose you've looked at LLVM much lately, or would have any thoughts on
stekernsimoncook: can't say I have from the top of my head08:26
simoncookok, thanks08:28
blueCmdpoke53281: try with
blueCmdI should get around to update the told binary and the checksums08:30
inigomwe are getting this when intalling fusesoc :10:00
inigommake[2]: *** No rule to make target `fusesoc/section/', needed by `install-sectionPYTHON'.  Stop.10:00
inigommake[2]: Leaving directory `/home/inigom/Desktop/pinksoc/fusesoc'10:00
inigommake[1]: *** [install-am] Error 210:00
inigommake[1]: Leaving directory `/home/inigom/Desktop/pinksoc/fusesoc'10:00
inigommake: *** [install-recursive] Error 110:00
stekerninigom: I guess this needs to go:
inigomthere is no section anymore , what do I do ?10:06
inigomwe deleted the line and it worked10:08
stekernthat's what you do10:11
inigombut now when building de0_nano10:12
inigomTraceback (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 run10:12
inigom    cm.add_cores_root(config.cores_root)10:12
inigom  File "/usr/local/lib/python2.7/dist-packages/fusesoc/", line 63, in add_cores_root10:12
inigom    self.load_cores(os.path.expanduser(p))10:12
inigom  File "/usr/local/lib/python2.7/dist-packages/fusesoc/", line 52, in load_cores10:12
inigom    self.load_core(d, f)10:12
inigom  File "/usr/local/lib/python2.7/dist-packages/fusesoc/", line 30, in load_core10:12
inigom    self._cores[name] = Core(file)10:12
inigom  File "/usr/local/lib/python2.7/dist-packages/fusesoc/", line 34, in __init__10:12
inigom    for s in section.SECTION_MAP:10:12
inigomAttributeError: 'module' object has no attribute 'SECTION_MAP'10:12
stekernyou'll need that10:14
inigomdoesn't work . Does it hurt if we go back to f0364db?10:25
stekerndefine 'doesn't work'10:26
stekernnvm, I see it here too10:28
kyrre_Having an issue with byte alignment with the compiler10:28
inigom  File "/usr/local/lib/python2.7/dist-packages/fusesoc/", line 30, in load_core10:28
inigom    self._cores[name] = Core(file)10:28
inigom  File "/usr/local/lib/python2.7/dist-packages/fusesoc/", line 34, in __init__10:28
inigom    for s in section.SECTION_MAP:10:28
inigomAttributeError: 'module' object has no attribute 'SECTION_MAP'10:28
stekerninigom: yes, I see that here too10:29
stekernyou can roll back, no problem10:29
stekernkyrre_: tell us more10:29
kyrre_im writing a string to uart, it puts a address that ends with 6 in R3 when calling uartprint10:30
kyrre_so when trying to read this memory it throws and align exception10:30
stekernwhat uartprint is that?10:32
kyrre_uart_print_str in freertos10:33
stekernwhy isn't it reading things byte-by-byte?10:33
kyrre_it takse a char* as arg10:33
kyrre_and uses uart_putc to print the string10:33
stekernok, it doesn't sound like that would read anything at larger granularity than 1 byte10:34
stekernso, on what does it fail with an unaligned exception then?10:36
kyrre_but it starts to read the first byte at 0x93c610:36
kyrre_shouldnt it be 4 8 c 0 ?10:36
stekernblueCmd: ^^ can you take a look at inigoms problem?10:36
stekernkyrre_: 32-bit accesses need to be 4 byte aligned, 16-bit accesses need to be 2 byte aligned and 8-bit 1 byte aligned10:38
kyrre_ok, so the error im experiencing shoudnt be connected to the start adress of that char* ?10:39
stekernno, that address should be fine, as long as its only access with*/ or l.lh*/l.sh10:40
stekern(since it was 2-byte aligned)10:41
kyrre_ok, after a closer look it loads per byte10:46
kyrre_it loads per byte10:47
kyrre_so, guess ill have to keep digging10:47
kyrre_looks like its because of my changes to or1ksim10:52
kyrre_running freertos on a clean or1ksim, no align exceptions10:52
kyrre_it only happens when i run or1ksim through gdb10:55
stekerndid you get the other crash that was related to your machine sorted out btw?10:58
kyrre_was because of miss assumptions on where we put our sim.cfg11:01
kyrre_and me not double checking the command you posted11:01
stekernoh, right... I forgot that11:02
stekernwonder what makes it different when you run it in gdb11:03
stekernotoh I don't many others have done that11:03
kyrre_not sure either, but it enters a loop at 0x600 0x60411:07
kyrre_using the same sim.cfg file for gdb and regular sim11:08
blueCmdstekern: right, that's because we use Makefiles ;)11:35
blueCmdI'm heading out for lunch now, but I'll give inigom a patch after I get back. basically the 'section' part of needs to be removed and '' added to the fusesoc_PYTHON section at the top, and then regen everything11:36
stekernblueCmd: that's not enough, I already done a pull-request that does that11:37
stekernit doesn't even work if you run it from the fusesoc dir11: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 up11:48
inigomverilator does not work if there are scanf in the code11:49
stekerninigom: again, define 'does not work'11:49
stekernthe vanilla verilator stuff that's in orpsoc-cores doesn't read any uart input, so I'm not surprised it doesn't work there11:50
inigomstekern this explains it11:51
blueCmdstekern: works for me :S13:06
blueCmdwell, up until the 'make' command is ran13:06
blueCmdsince I don't have quartus installed it doesn't go further13:06
blueCmdah, I didn't do make install - I only tried with bin/fusesoc13:07
blueCmdstekern: cannot reproduce13:11
stekernblueCmd: you don't get this?
blueCmdstekern: nope13:13
blueCmdwhere is your pwd?13:13
blueCmdI'm trying to run the thing in another directory than the fusesoc one and it fails with that it cannot find de0_nano13:14
stekernwell... do you have fusesoc.conf there?13:14
blueCmdah no13:14
blueCmdthat should be global IMO13:15
stekernyou mean, it should use a default one if it can't find one? I agree13:16
blueCmdstekern: I suspect that the old  section/ dir is somewhere13:16
blueCmdwhere it shouldn't be13:16
blueCmdstekern: yes13:16
blueCmdstekern: doing make install should put a global one in <prefix>/etc/fusesoc.conf and use that if it doesn't find a local one13:16
stekernwhat should be in that one then?13:17
stekernthere's probably the old section/ dir in the old install path13:17
blueCmdblast it!13:20
stekerndid that, now it works13:22
stekern...still fails when I run it from the src dir though13:22
stekernit's a bit unnice that installing it now breaks it for all old users too13:23
blueCmdyeah, that's a pity13:23
stekernok... make distclean doesn't acually clean .pyc13:25
stekernso the old section/section.pyc was lingering around in my src dir13:26
stekernremoving that and everything works13:27
stekernmy pull req is still valid though13:27
blueCmdstekern: yes, it's very pretty as well!13:40
blueCmdthe pull request that is13:40
wallentostekern: did you dump your snoop extensions for the store buffer somehwere?14:23
stekernwallento: I might have dumped them in my mor1kx, if not I can do that in thevening14:28
wallentoyes, that would be nice, I will also dump my current snoop logic, still faces flaws14:29
stekernblueCmd: just like it's author!14:31
stekernwallento, jupp, I'd like to enable dcache ;)14:31
wallentowell, 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 try14:34
inigomHi 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
blueCmda lot of people has :)14:48
blueCmdinigom: what are the symptoms? have you tried to decrease the clock frequency? what are your timing constraints? and so o14:49
blueCmdand so on*14:49
olofkFuseSoC already looks for a fusesoc.conf in /etc/fusesoc.conf, $XDG_CONFIG_HOME/fusesoc/fusesoc.conf and $PWD/fusesoc.conf15:23
olofkAnd you can manage without a config if you run it with fusesoc --add-cores-root=/path/to/cores15:24
olofkSorry, just --cores-root=/path/to/cores15:24
stekerninigom: again, define 'not working'. that setup works fine here.15:38
inigomno timing violations as fasr we can see .15:46
inigomjust switch or1200 with mor1kx and the uart no longer works15:47
inigomis it possible to tell fusesoc to fetch a previous commit of a core ?15:50
inigomsymptoms is we get nothing from serial port15:51
inigomprintfs don't come out15:52
inigombut if we use or1200 they do15:52
stekerninigom: that definitely works here...15:52
inigomit was workinh here some weeks back15:53
stekernI tested the latest versions of both orpsoc-cores and mor1kx yesterday on de0_nano, and it was printing out stuff on the uart15:54
stekernyes, you can set a commit in the provider section15:55
stekernor just remove the provider section and put symlinks to the related dirs from a normal git checkout15:55
stekernis the program running properly apart from no uart output?15:58
inigomwe think so from gdb it behaves well16:01
stekernif you change the version in the provider section, remember to wipe the cache then16:02
blueCmdolofk: 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
stekernblueCmd: you just have to put your default fusesoc.conf there16:08
inigominstead of version I can just put the hash ?16:09
blueCmdstekern: yeah, but make install should install everything16:09
stekerninigom: yes16:11
stekernblueCmd: but fusesoc don't know what you want as default16:12
stekernmaybe it could put as an example16:32
stekernbut does relative paths like that work in /etc/fusesoc.conf16:32
inigomwitht the mor1kx hash d510ac3babfa4f66887cb870e2b28f656b465ad2 it works!16:33
stekernso you are saying that you've bisected it down to:
stekernthere was some issues with that commit, that I fixed in
stekern...but all this is weird, what's different in our setups?16:40
stekerncan you give me your .elf?16:40
blueCmdstekern: I have some ideas for that as well, but that's for later16:41
wallentostekern: are you available for a chat on sunday?16:41
inigomsterkern: there you have it16:42
inigomstekern: i'm sending you the elf16:43
wallentoI 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 them16:43
wallentotoday I learned the read checking starts before req_i ;)16:44
poke53281thanks blueCmd: That did the job.16:44
stekernwallento: ping me on sunday, I'll probably be around16:44
wallentoperfect, I will check then, cya16:45
stekerninigom: dcc send, ages since I used that last... wonder where the file went :)16:46
stekerninigom: H W16:48
stekernworks fine here...16:48
inigomhere too but only with that hash16:50
inigomwe still have to find the last hash where it still works16:50
poke53281blueCmd: next problem with the second stage of debootstrap: "configuring libc-bin ..." "Failure while configuring required packages."17:00
poke53281Hmm, "Errors were encountered while processing: initscripts"17:10
olofkblueCmd: No, you're right, hardcoding to /etc is not correct for prefixed build. But I don't think anyone actually used that17:51
olofkAnd I don't like to put files in /etc unless necessary, so $PWD or $XDG_CONFIG_HOME/fusesoc are the preferred locations17:52
olofk /etc are mostly for system-wide installations of orpsoc-cores17:52
olofkBut I have thought about adding a setup/init step that fetches orpsoc-cores and adds a fusesoc.conf. Like a wizard17:53
olofkatgreen: Hi. I've seen you lurking around here lately. I wanted to talk binutils verilog backend with you :)20:15
olofkjuliusb: Have you done any workshops, like chiphack,  with fusesoc where you added extra peripherals?20:33
atgreenolofk, any time.  except now :)20:48
atgreenI'm in the middle of a move (packing/cleaning)20:49
olofkatgreen: Ah I see. They really should invent a way to move in somewhere without the hassle of moving out21:04
olofkBut just give me a shout when you're more available21:05
atgreenolofk, I have a few min now actually - still there?21:33
* atgreen takes a break from cleaning21:33
--- Log closed Sat May 31 00:00:13 2014

Generated by 2.15.2 by Marius Gedminas - find it at!