IRC logs for #openrisc Wednesday, 2013-01-23

blueCmdhm, crash while reading 0x96370 - a variable in .data00:28
blueCmd doesn't really make sense00:28
blueCmdhm, TLB miss. maybe I'm looking at the wrong part00:29
blueCmdah! yes I was00:29
_franck_this testsuite is going to kill me :) good night...00:45
blueCmd_franck_: ;) gn00:46
blueCmdstekern: - that's eglibc ;)01:56
blueCmdI had to remove a couple of TLS references (since I'm not done with all relocations) but it seems to be working01:59
blueCmdprintf and basic C apps compile02:00
stekernblueCmd: wow! nice work!04:24
stekernregarding userspace, here's a vmlinux image i've been using:
stekernbut it's an older kernel, from (i.e. not upstream)04:29
stekernif I have understood Jonas Bonn right, there are some incompatibilities with the syscalls in the upstream kernel and uclibc04:32
stekernI haven't really looked at it though, but I guess that shouldn't concern you, so you should be able to use the upstream kernel without any patches to handle that04:33
stekernbuilding userspace isn't that bad though, essentially it's just busybox04:33
stekernah, here's the patches Jonas sent to uclibc:
stekernthey were never accepted though (afaik)04:37
stekernwooo! or1200-mmu immu test passes!06:11
stekern...only when icache is disabled though...06:11
blueCmdstekern: I see that you merged the patches, did you have time to run regressions on them?11:10
blueCmdstekern: btw, mind sending me your sim.cfg you're using with that vmlinux? mine crashes with that image11:15
stekernno, I trust that you know what you are doing ;)11:27
stekern.. on the first question11:27
blueCmdhah, well that's comforting. Better get the regression suite running  locally then ;)11:29
stekernI'll rerun them, but it takes so long for them to complete, so I figured we can as well merge those and deal with potential regressions afterwards11:30's not like it's any lifedepending machines that are doing daily updates from those repos anyway ;)11:30
blueCmdnah that's true11:32
hnoHm... is there some way to soft-reset orpsocv2 so that it restarts in the boot rom?11:41
hnolinux kernel only does         __asm__("l.nop 1"); which obviously isn't quite enough.11:44
stekernjump to 0x10011:56
stekernmake sure all mmus and caches are disabled first11:57
stekernor actually, the bootrom might be at 0xf000000011:58
stekernso jump to  0xf000010012:01
hnostekern, yes. just figured out. But have not quite got it working.12:03
hnoI am doing from gdb12:03
hnospr sys sr 112:03
hnospr sys npc 0xf000010012:03
hnoand it does reload u-boot from SPI, but then u-boot hangs during initialiation so there is more things needed to be done.12:04
hnoresetting the FPGA by reloading the svf do work.12:05
_franck_you could load you uboot elf with gdb then j *0x10012:06
hno_franck_, that also hangs in this state.12:07
_franck_and if you break, couldn't you see where you are in uboot ?12:07
hno but the point was to verify that what was written to SPI flash actually works.12:07
hno_franck_, for some reason GDB only showed 0x01f801fc in ?? ()12:08
hnoafter resetting the FPGA u-boot do load, and gdb do show the current function.12:08
hnoHm.. is it possible to reset the FPGA on ordb2a using JTAG and have it reload it's configuration from SPI?12:10
stekernso what is in u-boot at 0x01f801fc?12:10
_franck_if you have enable debug symbols while compiling you can do "backtrace" in gdb12:11
_franck_and see why you end up at 0x01f801fc12:12
hnostekern, seems to be _interrupt_handler according to nm.12:12
hnodebug symbols is enabled. But backtrace do not work for some reason.12:12
hnomakes sense that it's the interrupt handler. Linux was running with man devices enabled, and those needs to be reset as well.12:14
hnoshould add some software controlled reset logics or more likel a watchdog with system reset output.12:15
blueCmdstekern: i get "Passive mode refused." now and then in the test suite13:44
blueCmdit will timeout (300 seconds!) and what I can see it will retry it and that time it will work13:44
blueCmdthis happens perhaps once every 20 tests. annoying as hell13:45
blueCmdhave you seen this problem?13:45
blueCmdI'm thinking of just switching to active FTP mod13:45
stekernhmm, no... haven't seen that13:46
blueCmdI only catched it by tailing gcc.log13:46
blueCmdit doesn't take 300 seconds, but it takes a while for it to continue13:46
stekernbut doesn't the test fail then?13:47
blueCmdno, it retries the same test again AFAICS13:49
stekernI don't have any of those in:
stekernwhat does your tun/tap setup look like?13:51
blueCmdstekern: you're log is much less verbose than mine14:00
blueCmdthat is the file I'm tailing14:01
blueCmdregarding my network, I use your exact config14:03
blueCmdsudo ip link set up dev tap014:03
blueCmdsudo ip addr add dev tap014:03
jeremybennettblueCmd: There is some commentary on setting up TUN/TAP in the Or1ksim manual I believe.14:04
jeremybennettYour log file seems to be missing a report of FTP starting.14:04
stekernhmm, why does that "SJK DEBUG" show up there?14:05
jeremybennettThe DejaGnu FTP used to be a bit flakey. The SVN board descriptions include some hacked FTP stuff - that may be worth checking.14:05
jeremybennettYou can also run make check-gcc RUNTESTFLAGS="v" to increase the verbosity of the logging14:06
blueCmdjeremybennett: well, I don't think this is a network problem14:06
jeremybennett(you can use "v v" and even "v v v" to further increase verbosity.14:06
blueCmdmy hunch is that ftpd in the platform is bugged14:07
jeremybennettI doubt it, given that telnet seems to have worked.14:07
jeremybennettcan you FTP in manually?14:07
stekernblueCmd: I'm also doing some iptable rules stuff when setting up the tun/tap14:07
blueCmdafter a while it retries the connection, then it works14:07
blueCmdwith PASV and everything14:07
jeremybennettWe ran extensive testing of OpenRISC using this environment, so it should be workable.14:07
blueCmdstekern: oh? like what?14:07
jeremybennettIf you look at etc in the Or1ksim source, you'll see the commands it uses for iptables stuff.14:08
blueCmdjeremybennett: it works, it's just slower than it needs to be. i mean, this could easily be missed if you don't look for it14:08
blueCmdah well I don't need to bridge it, point-to-point with my host computer is enough14:09
blueCmdI added an ACCEPT on everything -i tap0, the issue persists14:11
jeremybennettblueCmd: We added the bridge, because to run the entire regression suite required multiple instances on multiple computers (I think we used 14 instances of Or1ksim as targets to distribute the load).14:14
blueCmdjeremybennett: ah I see.14:14
stekernyeah, I'm using the brstart.sh14:17
blueCmdstekern: FYI, 20010122-1.c is a regression with my patches14:21
stekernok, do you know why? :)14:25
blueCmdwell, I suspect alloca14:26
blueCmdI never tested that and it wouldn't surprise me14:27
stekerni would have guessed the builtin_return_address14:28
blueCmdwell yes, but it needs to compensate for the frame size which alloca messes with14:28
stekernah, ok, you meant like that14:29
blueCmdI think builtin_return_address works when you don't use alloca14:29
blueCmdstekern: is it ok if I push vmlinux to github? or is it prive?14:29
blueCmdthe one you sent me14:29
stekernyou can do whatever you want with it14:30
stekernbut I still wonder why that SJK DEBUG came up in your ftp session14:31
stekernthat's an old debug printout I had when debugging why transparent unions didn't work with clang14:31
blueCmdah, didn't notice that14:33
stekernI know it comes up when your booting, haven't seen it anywhere else14:34
_franck_jeremybennett: I'm finally seeing something useful using RUNTESTFLAGS="-v -de gdb.base/advance.exp"14:52
_franck_see Start address in both case14:52
blueCmdstekern: ah. well that case testes builtin_return_addr's backtracing ability. I never implemented support for that14:53
_franck_Now, need to why this....tonight14:53
blueCmd__builtin_return_addr(0) returns the current frames return address, that we support. __builtin_return_addr(n > 0) would step n frames backwards and return that frame. not sure how we would do that in a good way14:54
stekernhow did that work before your changes14:55
blueCmdit used SjLj-stuff14:55
stekernah, right14:55
blueCmdI suppose we could implement it using stack unwinding14:55
hnoIs there an linux strace port for openrisc?14:55
blueCmdstekern: correction. before my patch that function always assumes that the first thing on the stack is LR14:58
hnoI have found this which looks promising, but not sure what it means.
blueCmdtilepro chose to not implement going backwards, i386 checks 0(sp) for the frame. we can't do the i386 way since frame_info-struct isn't available and we don't know where r9 was pushed to15:03
stekernblueCmd: hmm, but isn't that a wrong assumption?15:03
blueCmdstekern: yes it is15:03
blueCmdthat's why I changed it :)15:03
blueCmdjoking aside, let me double check it. it shouldn't have passed before if that's true15:04
blueCmdhm this shouldn't have passed before15:05
blueCmd#define RETURN_ADDR_RTX(COUNT, FP) ((COUNT) ? NULL_RTX : get_hard_reg_initial_val (Pmode, LINK_REGNUM))15:05
blueCmdthat's the old line15:05
blueCmdassume that it's in r915:05
blueCmdthat works for non GOT-code.15:06
blueCmdbut count is >0 would set it to NULL, which should have cause the test to fail15:06
stekernhmm, yeah that sounds odd15:07
stekernif NULL_RTX doesn't have some special meaning for RETURN_ADDR_RTX ;)15:08
blueCmdah no, this is something else. I re-read the code that failed and it's a case with only count = 015:10
stekernah, but you are returning const0_rtx15:10
stekernon count != 0, so it should work the same for that case15:11
stekern(I'm assuming NULL_RTX == cont0_rtx)15:11
blueCmdyes, me too. I just stole that part from tilepro15:12
blueCmdbut yes, I have a testcase that fails now that really should work.15:12
* blueCmd fix15:12
stekernok, so it's when r9 is on the stack that it fails15:12
stekernand count == 015:13
blueCmd  l.ori     r4,r3,0  # move reg to reg15:18
blueCmdr3 isn't r9 - why is it doing that?15:18
blueCmdit pops r2 into r315:19
blueCmdthis is the case where we haven't saved lr on the stack and have a function call15:20
blueCmdhm no15:20
blueCmdframe_info.save_lr_p is set15:20
* blueCmd is off to do laundry and think about this15:22
blueCmdstekern: I have a theory. Maybe or1k_return_addr_rtx is executed before it's valid to read frame information like what registers are live15:42
blueCmdthat would cause it to use data from the old frame which would make it restore from where r9 were then15:42
stekernsounds like it's worth investigating16:00
stekernheh, laundry break thinking sounds familiar16:01
stekernI've solved many problems while walking the dog ;)16:01
blueCmdstekern: I don't seem to have that passive mode error on another machine I have16:03
blueCmdstekern: yeah, it helped me :)16:03
blueCmd*sig* forgetitng make install doesn't fix anything16:21
blueCmdthat should fix it, I have to run some tests on my other stuff but it seems to work16:25
blueCmdwill push when I see that there is no more regressions, bbl16:28
blueCmdPerhaps it is possible to generate some instruction/macro that is later evaulated - I'm not that familiar with the MD system, but that would be neat17:22
stekernyeah, I can't say from the top of my head, not that familiar neither, I've mostly have learned how it works as I go18:56
stekernjuliusb: long term mor1kx spr idea: how would it sound if the spr's all where defined as registered?18:57
stekernthat way you could put at least some of them in blockram18:58
stekern+ it would make a lot more sense in cappuccino ;)18:58
stekernthe mmu spr's are registered per se, I had to add a small hack to get those to work properly18:59
stekernthoughts on that?18:59
blueCmdstekern: looking at some test cases that have the status UNRESOLVED for me21:18
blueCmdand not for you - the cases lack an main method21:19
blueCmdwhich causes the linker to complain. I don't see how it works for you21:19
blueCmdhm your log shows that it compiles it as an object - not linking it. I will investigate further21:20
blueCmd981001-2.c to be exact21:22
blueCmdI retract my statement that it's caused by not having a main method - it's irrelevant. I will wait for the whole test to complete before chasing any bugs21:52
blueCmdwell, the #gcc guys couldnt help me - I will just use my files as reference from now on.22:38
blueCmdstekern: anyway, gcc passes the relevant testcases - I had some problems with cleanup-*.c - but if I compile it myself with my glibc it works. I won't spend much time on that, if you have any regressions related to that - give me a ping and we can debug it then22:40
blueCmdwith my uclibc* (not glibc)22:41
blueCmdstekern: I don't know if I merged the pull request correctly - it added a sort of dummy commit22:53
* blueCmd feels like a noob when it comes to github :(22:53

Generated by 2.15.2 by Marius Gedminas - find it at!