IRC logs for #openrisc Tuesday, 2014-04-22

--- Log opened Tue Apr 22 00:00:16 2014
stekernit ends with a lookup for setrlimit6403:48
stekernolofk_: you are too quick to respond, I've already pushed that orpsocv2 patch and was writing an answer06:31
stekernbut I wanted to create the atlys pull request first, so we could boost with a more concrete atlys port in progress ;)06:32
olofk_Sorry about that. Slow day at work :)06:32
stekernmaybe I'll just pretend I didn't see your answer and just send my message as is ;)06:33
olofk_Yeah. Do that. Sounds easiest06:34
olofk_(and is probably what I would have done if I had started writing already)06:34
stekernat least it escalated the atlys board port =)06:45
stekern...and no-one can blame us for being non-responsive and letting patches queue up for eternity anymore ;)06:56
stekernolofk_: so, if you've got a slow day at work, spend some time browsing through the pull-requst ;)07:06
stekernit's not as clean as I'd like it to be, but I think it might just sit around and bitrot until I get around to clean it up...07:07
stekernwho will do the honor of doing the 100th commit?
olofk_stekern: You can still blame me for being non-responsive. Five open pull requests for orpsoc-cores and one for fusesoc :)07:24
olofk_But I'll check the atlys one quickly. Don't worry about it not being clean enough. We can fix that later.07:24
olofk_I should probably have told _franck__ to submit his port too instead of cleaning it up. Perfect is the enemy of done07:26
olofk_What? Three ps/2 slaves? Is there even three ps/2 ports on the board?07:28
stekernno, or well, yes... on my board there is07:28
stekernone goes to the PMOD connector, and two goes to the usb_hid<->ps2 converter07:29
stekernin theory, it should be possible to use mouse and keyboard through the usb connector, but you'll need one of those devices that have both implemented07:30
stekerni.e. a hub doesn't work07:31
stekernlike one of these would work:
blueCmdstekern: i see. i have had some problems with setlocale, thats why im asking07:32
stekernblueCmd: que?07:32
blueCmdirssi and ld dbug07:33
stekernah, ok07:33
olofk_stekern: I think you will have the honor to submit commit #10007:34
stekernolofk_: I'll take a screenshot, print it and put it on a wall!07:35
olofk_Achievement unlocked!07:35
_franck_web_olofk_: don't worry I'm almost done :)07:38
_franck_web_stekern: can you push your DTS file too with your atlys board ?07:40
* _franck_web_ is looking for the best way to implement a whishbone clock crossing bridge07:41
blueCmdstekern: solved the pass 2 btw. MPFR compiles with only 19 test failures instead of 65 now :)07:42
olofk__franck_web_: Yes. A wishbone CDC would be great to have as a stand-alone component. We talked about trying to lift out the one from stekern's wb_sdram_ctrl, but I haven't investigated if that could be done easily07:44
olofk_Unfortunately Wishbone B3 isn't very well suited for CDC. Wishbone B4 fixes that to some extent07:44
stekernblueCmd: sounds good07:56
olofk_So what's the binutls status now?08:19
olofk_Have everyone got their signed papers back?08:19
stekernolofk_: what's in wb b4 that makes cdc easier?08:21
stekernthe irssi bug is an unaligned access somewhere...08:32
blueCmdstekern: really? that's cool08:34
blueCmdI wonder what that might be08:34
blueCmdit might just be memory pointer corruption also08:34
stekernand that it sometimes crashes with a bus error makes that theory even more plausible08:36
blueCmdthat we managed solving the TLS bug makes me feel nice. I really thought giving up for a moment.08:38
blueCmdprobably spent 80 hours on the damn thing :)08:38
stekernmoments like that, I always start thinking "damn, if I give up now, then I have wasted 80h for nothing" ;)08:39
stekernGPR09: 6765745f <- that doesn't look good08:39
blueCmdlooks like a perfectly good return address to me08:40
blueCmdit just needs extra attention08:40
blueCmdLoneTech: nice catch!08:41
stekernhaha, LoneTech is probably the only one that can read ascii in hex on the fly ;)08:41
LoneTechfar from it, and I didn't bother. enough that most of it was letters.08:42
stekerndon't be modest08:42
LoneTechwhy not?08:42
blueCmdI mean, you have a nice thing there to be able to see that in an instant08:42
LoneTechI keep working on bits. it's mere habit08:43
LoneTechgpr2 also holds probable text (nel_)08:44
stekernyeah, which means that it's not only r9 that's trashed08:45
stekern...well, r2 oculd potentially hold something like that in a function where the framepointer is omitted08:45
stekernlet's see what's happening at 000be4a408:46
olofk_stekern: B4 doesn't make it easier. Just more efficient as you don't have to wait for an ack for each access08:48
LoneTechthe alignment of nel_ doesn't match the many get_kernel_page* symbols08:49
stekernbe4a4:       44 00 48 00     l.jr r908:49
LoneTechyep, return to get_08:50
stekernolofk_: you mean in the pipeline mode08:50
olofk_stekern: Yep.08:50
stekernyeah, so our problem is that our registers aren't large enough to hold the full string for the return address...08:51
olofk_I told you that we should have stored our registers in the cloud so we could scale them easier08:51
stekernmor1kx ms edition does that08:52
LoneTechirssi symbol: channel_get_nickmode08:52
LoneTechdoes match up with the alignment08:52
stekernthat looks plausible08:52
stekernbe4a4 is in core_init08:53
stekernmaybe the stack pointer is getting trashed, since r9 is loaded from there08:53
blueCmdsounds very plausible. trashed and makes r9 load some old string value08:54
stekernthis is interesting though, framepointer isn't omitted in that function and:
stekernah, that wasn't as interesting as I first thought08:56
stekernbut it explains the nice alignment of r2 and r908:57
LoneTechor restores frame pointer into stack pointer afaict08:57
LoneTechyep, frame pointer was trashed before restoring the stack frame08:57
LoneTech(as it happens, to a value pointing into the symbol table)08:57
stekernI think I should take up on my own advice and run core_init in or1ksim surrounded with l.trap 8 and l.trap 908:58
stekernerr, l.nop I mean09:02
stekernolofk_: what board is it that you are making a port for btw?09:07
blueCmdwe should set up some regression testing for board support09:15
blueCmdmark a couple 'officially supported' and make sure we test them09:15
blueCmdshould be possible to automate09:15
stekernat least booting on the atlys board is magnitudes faster than or1ksim09:27
blueCmdthat makes me happy!09:31
stekernLoneTech: didn't you have a patch to make or1ksim 'term' sane?09:36
LoneTechI don't recall right now. I probably poked at something way back09:37
LoneTechI've found one diff to xterm.c that probably messed with that09:38
LoneTechI suspect I copied it from somewhere because it mentions cygwin09:39
LoneTechif that thing helps someone should document what it helps with and check it in09:48
LoneTech(incidentally, what it does could probably be done by connecting stty(1) to the xterm)09:49
olofk_stekern: Yep. That's the board09:53
olofk_blueCmd: Yeah. I agree. Need someone to buy them and somewhere to host them though.09:55
blueCmdstekern: if you submit stuff to or1ksim, would you mind testing my pull request as well?09:55
blueCmdi added random MAC generation09:56
blueCmdjeremybennett wanted (rightfully so) me to run the testsuite, but I haven't gotten around to compile an -elf compiler09:57
olofk_34 cores in orpsoc-cores so far. Not bad at all10:02
stekernbah... and then there's those 64-bit fixes that haven't made it into or1ksim too...10:10
stekernblueCmd: sure, I can do that10:12
stekernI can pull in that and peters 64-bit fix and ask jeremybennett if it's ok to push those together with my atomic changes when it's time for them to go in10:17
olofk_What's the status on OpenRISC in qemu? Can we use the mainline version or do we have a lot of local patches?10:28
stekernI've got a nice little 1.6 gig trace to sift through now...10:43
stekernolofk_: I think it's largely ok, iirc the most critical patches from poke53281 got merged10:44
stekernI think blueCmd's patches are mostly related to running glibc in usermode qemu, right?10:45
blueCmdstekern: yes, but I'm using poke53281's patches to build my patches on10:48
stekernI think I see an interesting thing in the 1.6gig trace10:52
LoneTechdo tell10:52
stekernthis is the correct value that get saved away:10:52
stekernU 000be268: 9c410000 l.addi  r2,r1,0x0       r2         = 7fc2dccc  flag: 010:52
stekernthis is the trashed value: GPR01: 0000dccc10:53
stekernwhere did those upper bits go?10:53
LoneTechaddi should not destroy them. andi would10:54
stekernah, yes, but there are about 1.6 gig of trace between those two events ;)10:55
LoneTechwonderful. so search on the address bus?10:55
stekernbut I've got a feeling that I've found the right haystack to search the needle in10:56
stekernlooks like it's the uname syscall that trashes the stack11:56
LoneTechthat structure has changed size in different versions, as indicated by linux/utsname.h having oldold_utsname, old_utsname and new_utsname12:05
stekernyes, that's what I'm starting to think about12:07
stekernfrom the disasm, linux does a copy_to_user with 392 bytes12:07
stekern...and the stack that is getting trashed is at byte 391 and 39212:11
stekernumm... where does those 2 extra bytes come from...12:21
stekernif I go by this:
stekernthe size of struct new_utsname should be 6*65 = 39012:22
LoneTechyes, that's what it looks like it would be in userspace. somehow the kernel didn't agree.12:29
stekernyes, this might be a or32-linux-gcc thing though... it somehow thinks that struct new_utsname is 392 bytes12:30
stekernlet's see if recompiling it with the or1k-elf- makes a difference12:32
stekernseems odd that it would pad it with 2 bytes though...12:32
stekernto something that's not aligned to 4 I mean12:33
stekernor... errr12:33
stekernthat's what it does, pad it to something that's aligned to 412:33
* stekern goes back to the schoolbench to learn some basic math12:34
stekernand blueCmd fiddled with the struct padding in gcc12:35
stekern...the gcc he have used to compile userspace with I mean12:36
blueCmdparts of userspace!12:38
blueCmdlibc would have been compiled before that alignment thing12:38
stekernhmm, could be a or32- vs or1k- difference without your fiddling though12:39
stekernunless the pointer to the utsname struct comes from irssi12:40
stekern...which it probably does12:41
stekernmy or1k-elf-gcc pads it up to 392 too12:44
blueCmdso apparently we have successfully assigned copyright to GNU for binutils12:44, I take back what I said about the struct padding ;)12:50
blueCmdso, what's the problem?12:56
blueCmdI haven't read the discussions with much detail12:56
stekernthe problem is that userspace gives the kernel an area of 390 bytes to copy the struct into, but the kernel copies the padded struct that is 392 bytes13:15
stekernI can of course make the problem go away by compiling the kernel with your struct pad patch applied13:17
blueCmdI think you should do that :)13:19
blueCmdstekern: how does it run in general? bug aside, does it feel useful? I'm afraid it's too slow to be useful, but with atomic instructions and possibly vDSO I hope it will be useable even at 50 MHz13:26
_franck_web_what do you think of simple handshake CDC like this:
_franck_web_that would not be efficient13:51
stekernblueCmd: heh, yeah, I'll probably do that for now, but we probably have to give that patch some more thought13:56
stekernwhat was the problem you had that it solves?13:57
stekernblueCmd: usable? my x64 desktop is already halfways out the window! =)14:00
blueCmdstekern: hah! nice to hear14:01
blueCmdstekern: it solves stuff like file formats and network structures. stuff like freetype has compile time asserts on the size of structures14:02
blueCmdand not attribute((packed))14:02
blueCmdnot sure if that is a correct assumption by them, but I'm not going to rewrite freetype14:03
stekernI guess it depend on what you expect, but it's probably usable enough for some low demand tasks14:04
stekernthat's why I want to get irssi working14:05
stekernapt-getting is snappy enough (if you don't count update)14:06
olofk_stekern: I'm still waiting for you to do a emerge -uND world :)14:10
olofk__franck_web_: I'm not sure that would be enough. I'm a bit scared of sending all those lines between the clock domains without dedicated synchronization registers14:12
blueCmdolofk_: you mean 'wine WindowsUpdate.exe'?14:14
blueCmdnow that's a killer app14:19
_franck_web_olofk_: all those non registered lines are stable when cyc and stb are active. Plus, cyc and stb go thru some dff and are delayed14:19
stekernyeah, I think that should be ok14:20
blueCmdstekern: running make CFLAGS='-fPIC' check on mpfr makes all tests succeed14:27
blueCmdso I guess I missed some PIC emit somewhere14:27
stekern(rewrite freetype) slacker!14:32
stekernyeah, I guess the upsides might win over the downsides then...14:33
blueCmdolofk_: also ofc15:24
-!- phoohb_ is now known as phoohb15:28
Limbolofk: I got the BSCAN working on the artix7, yes17:56
stekernnow irssi starts, but segfaults when trying to connect18:19
stekernthis time it's somewhere in a lib18:20
stekernin to be more preices18:23
stekernprecise, something my writing isn't...18:24
blueCmdstekern: interesting!18:24
stekernthis little irc client is a tough beast to get running ;)18:26
stekernit's nice to have glibc, that have support for all the LD_* env-vars18:27
blueCmdI'm enjoying that you are discovering bugs, it's nice to not be the only one xD18:28
stekernI'm enjoying fixing bugs more than discovering them ;)18:29
stekernotoh, discovering is often the hardest part18:29
stekernblueCmd: hmm, r10 is read in start_thread, but it's zero19:01
stekernwhich makes me suspect that the TLS stuff in copy_thread might not work right19:02
blueCmdstekern: interesting19:06
blueCmdstekern: you have the full right?19:07
stekernunless you have changed something in the atomic patch since what you've posted to the ml, but's not related now19:10
blueCmdright, no that should be fine I think19:10
blueCmdif you could see if kregs->gpr[7] is a "pointer looking value" that would be neat19:11
stekernhmm, I guess I could dig that out, but I don't have it available right now19:14
blueCmdoh well19:15
stekernwhat emits the read from r10?19:15
stekerntrying to find the place where that happens in the C version of start_thread19:16
_franck__stekern: could you show me your ps2 device tree binding ?19:19
blueCmdstekern: the code I'm modifying in gcc19:19
blueCmdemit_insn (gen_add3_insn (dest, dest, tp));19:19
blueCmdor the __tls_get_addr function19:20
stekernhmm... ok...19:20
stekernteach me about tls ;) when does that happen?19:21
blueCmdthe emit?19:24
stekernyes, what triggers that19:24
blueCmdwhen gcc finds a symbol with a TLS model assigned to it19:24
blueCmdwhich would be a symbol with the '__thread' decl19:24
stekernok, I see19:25
blueCmddepending on where the symbol is and how it will be linked19:26
blueCmdGD and LD differs somewhat in that the result from tls_get_addr can be cached in LD. IE nad LD can be resolved link-time.19:26
blueCmdGD LD are resolved runtime (dynamic symbols)19:26
blueCmdso an executable you would only have GD or LD relocs (only GD in or1k since I treat LD as GD)19:27
blueCmdbut in the .o files you can have all relocs19:27
stekerngreat, thanks for the explanation19:28
_franck__stekern: thanks19:31
blueCmdstekern: can we just use llvm instead?19:43
blueCmdthrow away gcc19:48
stekernyes, but there's no TLS support in our port ;)19:48
blueCmdwho needs TLS? let's just change glibc to use emutls19:49
stekernblueCmd: this doesn't look good in combination with your patch:
stekernbut that doesn't explain why it's 0...20:14
blueCmdstekern: which part?20:16
stekernthe part where the stack pointer is copied into argument 5 (r7)20:17
blueCmdline 1095?20:19
blueCmdah right20:19
blueCmdstekern: I recall this, but somehow it was OK20:32
stekernyeah, I think it is20:32
stekernit should already be saved to kregs on exception entry20:32
stekernso, the question is, why isn't it?20:33
stekernor rather, why is it 0?20:33
blueCmdhave you tried in or1ksim?20:33
stekernno, that might be a good idea20:34
blueCmdofc it is!20:34
blueCmdit starts in qemu btw20:34
stekernbut can you connect?20:35
stekernit starts here too20:35
blueCmdoh, I haven't tried20:35
stekernand then segfaults when I do /connect or /server20:35
bluecmd_stekern: hello20:35
blueCmdbluecmd_: you are a handsome devil!20:36
stekernis that usermode or 'normal' qemu?20:38
stekernso, most likely a kernel bug if there's a sw bug20:39
blueCmdyes, running in or1ksim should say something20:39
blueCmdif it's sw or hw20:39
stekernI'm recompiling the kernel for or1ksim now20:40
blueCmdthis is stupid, things are working but optimization kills it20:40
blueCmdfor TLS20:40
blueCmdit tries to wrap everything in a got()(r16) block20:41
blueCmd"because that is obviously the best thing to do"20:41
blueCmdgo home gcc, you're drunk20:41
blueCmdI made the got insn want a "explicitly non-TLS" symbol (that makes sense I think) and then it just barfs20:42
stekernor1ksim booting...20:43
stekernI've installed ssh, so the boot is even slower now20:43
blueCmdit's worth it though20:43
blueCmdthe console isn't really useable in or1ksim20:43
stekernit segfaults like a boss20:49
blueCmdreally? that's interesting20:54
olofkLimb: How do you connect to the bscan device? OpenOCD?20:55
stekernat the exact same place, with r10 = 020:55
olofkAnd great work with binutils everyone!20:55
blueCmdolofk: wouldn't have happened without you20:56
olofkI'm apparently better at kicking people's asses than writing code :)20:57
olofkOh god! Don't tell me I'm destined to become a project manager :(20:57
blueCmd that was a fun one!21:23
blueCmdso I got all the gcc TLS tests to work21:38
blueCmdthat's nice I guess21:38
blueCmdstekern: do we support linking PIC code with non-PIC code? if I have two .o and one is fPIC and the other isn't21:39
stekernI don't think that work21:44
stekernhmm kregs->gpr[7] = 021:46
blueCmdstekern: or1k-glibc/ports/sysdeps/unix/sysv/linux/or1k/nptl/or1k_clone.S is the file where the userspace part is22:08
blueCmdand or1k-glibc/ports/sysdeps/unix/sysv/linux/or1k/clone.c22:09
Limbolofk: OpenOCD yep22:57
blueCmdstekern: so the last 19 errors seems to be because there are IE relocations in the tests' .o files, but GD relocations in some files that they try to link with. I have no idea why mpfr would use -fPIC for one and not the other though23:26
blueCmdI explicitly don't process the same symbol twice in binutils, maybe I need to hack around that23:26
--- Log closed Wed Apr 23 00:00:17 2014

Generated by 2.15.2 by Marius Gedminas - find it at!