| blueCmd | hm, crash while reading 0x96370 - a variable in .data | 00:28 |
|---|---|---|
| blueCmd | http://pastebin.com/uMiAd33U doesn't really make sense | 00:28 |
| blueCmd | hm, TLB miss. maybe I'm looking at the wrong part | 00:29 |
| blueCmd | ah! yes I was | 00:29 |
| _franck_ | this testsuite is going to kill me :) good night... | 00:45 |
| blueCmd | _franck_: ;) gn | 00:46 |
| blueCmd | stekern: http://pastebin.com/tWJiF2YM - that's eglibc ;) | 01:56 |
| blueCmd | I had to remove a couple of TLS references (since I'm not done with all relocations) but it seems to be working | 01:59 |
| blueCmd | printf and basic C apps compile | 02:00 |
| stekern | blueCmd: wow! nice work! | 04:24 |
| stekern | regarding userspace, here's a vmlinux image i've been using: http://oompa.chokladfabriken.org/tmp/vmlinux | 04:28 |
| stekern | but it's an older kernel, from git.openrisc.net (i.e. not upstream) | 04:29 |
| stekern | if I have understood Jonas Bonn right, there are some incompatibilities with the syscalls in the upstream kernel and uclibc | 04:32 |
| stekern | I 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 that | 04:33 |
| stekern | building userspace isn't that bad though, essentially it's just busybox | 04:33 |
| stekern | ah, here's the patches Jonas sent to uclibc: http://comments.gmane.org/gmane.comp.lib.uclibc.general/21241 | 04:36 |
| stekern | they were never accepted though (afaik) | 04:37 |
| stekern | wooo! or1200-mmu immu test passes! | 06:11 |
| stekern | ...only when icache is disabled though... | 06:11 |
| blueCmd | stekern: I see that you merged the patches, did you have time to run regressions on them? | 11:10 |
| blueCmd | stekern: btw, mind sending me your sim.cfg you're using with that vmlinux? mine crashes with that image | 11:15 |
| stekern | no, I trust that you know what you are doing ;) | 11:27 |
| stekern | .. on the first question | 11:27 |
| blueCmd | hah, well that's comforting. Better get the regression suite running locally then ;) | 11:29 |
| stekern | I'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 afterwards | 11:30 |
| stekern | ...it's not like it's any lifedepending machines that are doing daily updates from those repos anyway ;) | 11:30 |
| blueCmd | nah that's true | 11:32 |
| stekern | http://oompa.chokladfabriken.org/tmp/or1ksim-tcp.cfg | 11:32 |
| stekern | http://oompa.chokladfabriken.org/tmp/or1ksim.cfg | 11:32 |
| blueCmd | gracias | 11:32 |
| hno | Hm... is there some way to soft-reset orpsocv2 so that it restarts in the boot rom? | 11:41 |
| hno | linux kernel only does __asm__("l.nop 1"); which obviously isn't quite enough. | 11:44 |
| stekern | jump to 0x100 | 11:56 |
| stekern | make sure all mmus and caches are disabled first | 11:57 |
| stekern | or actually, the bootrom might be at 0xf0000000 | 11:58 |
| stekern | so jump to 0xf0000100 | 12:01 |
| hno | stekern, yes. just figured out. But have not quite got it working. | 12:03 |
| hno | I am doing from gdb | 12:03 |
| hno | spr sys sr 1 | 12:03 |
| hno | spr sys npc 0xf0000100 | 12:03 |
| hno | c | 12:03 |
| hno | and 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 |
| hno | resetting the FPGA by reloading the svf do work. | 12:05 |
| _franck_ | you could load you uboot elf with gdb then j *0x100 | 12: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 |
| hno | after resetting the FPGA u-boot do load, and gdb do show the current function. | 12:08 |
| hno | Hm.. is it possible to reset the FPGA on ordb2a using JTAG and have it reload it's configuration from SPI? | 12:10 |
| stekern | so what is in u-boot at 0x01f801fc? | 12:10 |
| _franck_ | if you have enable debug symbols while compiling you can do "backtrace" in gdb | 12:11 |
| _franck_ | and see why you end up at 0x01f801fc | 12:12 |
| hno | stekern, seems to be _interrupt_handler according to nm. | 12:12 |
| hno | debug symbols is enabled. But backtrace do not work for some reason. | 12:12 |
| hno | makes sense that it's the interrupt handler. Linux was running with man devices enabled, and those needs to be reset as well. | 12:14 |
| hno | should add some software controlled reset logics or more likel a watchdog with system reset output. | 12:15 |
| blueCmd | stekern: i get "Passive mode refused." now and then in the test suite | 13:44 |
| blueCmd | it will timeout (300 seconds!) and what I can see it will retry it and that time it will work | 13:44 |
| blueCmd | this happens perhaps once every 20 tests. annoying as hell | 13:45 |
| blueCmd | have you seen this problem? | 13:45 |
| blueCmd | I'm thinking of just switching to active FTP mod | 13:45 |
| stekern | hmm, no... haven't seen that | 13:46 |
| blueCmd | I only catched it by tailing gcc.log | 13:46 |
| blueCmd | it doesn't take 300 seconds, but it takes a while for it to continue | 13:46 |
| stekern | but doesn't the test fail then? | 13:47 |
| blueCmd | no, it retries the same test again AFAICS | 13:49 |
| stekern | I don't have any of those in: http://oompa.chokladfabriken.org/tmp/regression/gcc/gcc.log | 13:50 |
| stekern | what does your tun/tap setup look like? | 13:51 |
| blueCmd | stekern: you're log is much less verbose than mine | 14:00 |
| blueCmd | weird | 14:00 |
| blueCmd | ./gcc/testsuite/gcc/gcc.log | 14:01 |
| blueCmd | that is the file I'm tailing | 14:01 |
| blueCmd | http://pastebin.com/Bx8q4wTr | 14:01 |
| blueCmd | regarding my network, I use your exact config | 14:03 |
| blueCmd | sudo ip link set up dev tap0 | 14:03 |
| blueCmd | sudo ip addr add 192.168.255.201/24 dev tap0 | 14:03 |
| jeremybennett | blueCmd: There is some commentary on setting up TUN/TAP in the Or1ksim manual I believe. | 14:04 |
| jeremybennett | Your log file seems to be missing a report of FTP starting. | 14:04 |
| stekern | hmm, why does that "SJK DEBUG" show up there? | 14:05 |
| jeremybennett | The DejaGnu FTP used to be a bit flakey. The SVN board descriptions include some hacked FTP stuff - that may be worth checking. | 14:05 |
| jeremybennett | You can also run make check-gcc RUNTESTFLAGS="v" to increase the verbosity of the logging | 14:06 |
| blueCmd | jeremybennett: well, I don't think this is a network problem | 14:06 |
| jeremybennett | (you can use "v v" and even "v v v" to further increase verbosity. | 14:06 |
| blueCmd | my hunch is that ftpd in the platform is bugged | 14:07 |
| jeremybennett | I doubt it, given that telnet seems to have worked. | 14:07 |
| jeremybennett | can you FTP in manually? | 14:07 |
| stekern | blueCmd: I'm also doing some iptable rules stuff when setting up the tun/tap | 14:07 |
| blueCmd | after a while it retries the connection, then it works | 14:07 |
| blueCmd | with PASV and everything | 14:07 |
| jeremybennett | We ran extensive testing of OpenRISC using this environment, so it should be workable. | 14:07 |
| blueCmd | stekern: oh? like what? | 14:07 |
| jeremybennett | If you look at brstart.sh etc in the Or1ksim source, you'll see the commands it uses for iptables stuff. | 14:08 |
| blueCmd | jeremybennett: it works, it's just slower than it needs to be. i mean, this could easily be missed if you don't look for it | 14:08 |
| blueCmd | ah well I don't need to bridge it, point-to-point with my host computer is enough | 14:09 |
| blueCmd | I added an ACCEPT on everything -i tap0, the issue persists | 14:11 |
| jeremybennett | blueCmd: 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 |
| blueCmd | jeremybennett: ah I see. | 14:14 |
| stekern | yeah, I'm using the brstart.sh | 14:17 |
| blueCmd | stekern: FYI, 20010122-1.c is a regression with my patches | 14:21 |
| stekern | ok, do you know why? :) | 14:25 |
| blueCmd | well, I suspect alloca | 14:26 |
| blueCmd | I never tested that and it wouldn't surprise me | 14:27 |
| stekern | i would have guessed the builtin_return_address | 14:28 |
| blueCmd | well yes, but it needs to compensate for the frame size which alloca messes with | 14:28 |
| stekern | ah, ok, you meant like that | 14:29 |
| blueCmd | I think builtin_return_address works when you don't use alloca | 14:29 |
| blueCmd | stekern: is it ok if I push vmlinux to github? or is it prive? | 14:29 |
| blueCmd | private* | 14:29 |
| blueCmd | the one you sent me | 14:29 |
| stekern | you can do whatever you want with it | 14:30 |
| blueCmd | great | 14:30 |
| stekern | but I still wonder why that SJK DEBUG came up in your ftp session | 14:31 |
| stekern | that's an old debug printout I had when debugging why transparent unions didn't work with clang | 14:31 |
| blueCmd | ah, didn't notice that | 14:33 |
| stekern | I know it comes up when your booting, haven't seen it anywhere else | 14:34 |
| _franck_ | jeremybennett: I'm finally seeing something useful using RUNTESTFLAGS="-v -de gdb.base/advance.exp" | 14:52 |
| _franck_ | http://pastebin.com/Nb6usTN3 | 14:52 |
| _franck_ | see Start address in both case | 14:52 |
| blueCmd | stekern: ah. well that case testes builtin_return_addr's backtracing ability. I never implemented support for that | 14:53 |
| _franck_ | Now, need to why this....tonight | 14: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 way | 14:54 |
| stekern | how did that work before your changes | 14:55 |
| blueCmd | it used SjLj-stuff | 14:55 |
| stekern | ah, right | 14:55 |
| blueCmd | I suppose we could implement it using stack unwinding | 14:55 |
| hno | Is there an linux strace port for openrisc? | 14:55 |
| blueCmd | stekern: correction. before my patch that function always assumes that the first thing on the stack is LR | 14:58 |
| hno | I have found this which looks promising, but not sure what it means. http://blog.csdn.net/citytramper/article/details/3084812 | 15:02 |
| blueCmd | tilepro 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 to | 15:03 |
| stekern | blueCmd: hmm, but isn't that a wrong assumption? | 15:03 |
| blueCmd | stekern: yes it is | 15:03 |
| blueCmd | that's why I changed it :) | 15:03 |
| blueCmd | joking aside, let me double check it. it shouldn't have passed before if that's true | 15:04 |
| blueCmd | hm this shouldn't have passed before | 15:05 |
| blueCmd | #define RETURN_ADDR_RTX(COUNT, FP) ((COUNT) ? NULL_RTX : get_hard_reg_initial_val (Pmode, LINK_REGNUM)) | 15:05 |
| blueCmd | that's the old line | 15:05 |
| blueCmd | assume that it's in r9 | 15:05 |
| blueCmd | that works for non GOT-code. | 15:06 |
| blueCmd | but count is >0 would set it to NULL, which should have cause the test to fail | 15:06 |
| stekern | hmm, yeah that sounds odd | 15:07 |
| stekern | if NULL_RTX doesn't have some special meaning for RETURN_ADDR_RTX ;) | 15:08 |
| blueCmd | ah no, this is something else. I re-read the code that failed and it's a case with only count = 0 | 15:10 |
| stekern | ah, but you are returning const0_rtx | 15:10 |
| stekern | on count != 0, so it should work the same for that case | 15:11 |
| stekern | (I'm assuming NULL_RTX == cont0_rtx) | 15:11 |
| stekern | +s | 15:11 |
| blueCmd | yes, me too. I just stole that part from tilepro | 15:12 |
| blueCmd | but yes, I have a testcase that fails now that really should work. | 15:12 |
| * blueCmd fix | 15:12 | |
| stekern | ok, so it's when r9 is on the stack that it fails | 15:12 |
| stekern | and count == 0 | 15:13 |
| blueCmd | erhm | 15:18 |
| blueCmd | l.ori r4,r3,0 # move reg to reg | 15:18 |
| blueCmd | r3 isn't r9 - why is it doing that? | 15:18 |
| blueCmd | it pops r2 into r3 | 15:19 |
| blueCmd | aha | 15:20 |
| blueCmd | this is the case where we haven't saved lr on the stack and have a function call | 15:20 |
| blueCmd | hm no | 15:20 |
| blueCmd | frame_info.save_lr_p is set | 15:20 |
| * blueCmd is off to do laundry and think about this | 15:22 | |
| blueCmd | stekern: I have a theory. Maybe or1k_return_addr_rtx is executed before it's valid to read frame information like what registers are live | 15:42 |
| blueCmd | that would cause it to use data from the old frame which would make it restore from where r9 were then | 15:42 |
| stekern | sounds like it's worth investigating | 16:00 |
| stekern | heh, laundry break thinking sounds familiar | 16:01 |
| stekern | I've solved many problems while walking the dog ;) | 16:01 |
| blueCmd | stekern: I don't seem to have that passive mode error on another machine I have | 16:03 |
| blueCmd | stekern: yeah, it helped me :) | 16:03 |
| blueCmd | *sig* forgetitng make install doesn't fix anything | 16:21 |
| blueCmd | stekern: http://pastebin.com/bfxDpVAD | 16:24 |
| blueCmd | that should fix it, I have to run some tests on my other stuff but it seems to work | 16:25 |
| blueCmd | will push when I see that there is no more regressions, bbl | 16:28 |
| blueCmd | Perhaps 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 neat | 17:22 |
| stekern | yeah, I can't say from the top of my head, not that familiar neither, I've mostly have learned how it works as I go | 18:56 |
| stekern | -have | 18:56 |
| stekern | juliusb: long term mor1kx spr idea: how would it sound if the spr's all where defined as registered? | 18:57 |
| stekern | that way you could put at least some of them in blockram | 18:58 |
| stekern | + it would make a lot more sense in cappuccino ;) | 18:58 |
| stekern | the mmu spr's are registered per se, I had to add a small hack to get those to work properly | 18:59 |
| stekern | thoughts on that? | 18:59 |
| blueCmd | stekern: looking at some test cases that have the status UNRESOLVED for me | 21:18 |
| blueCmd | and not for you - the cases lack an main method | 21:19 |
| blueCmd | which causes the linker to complain. I don't see how it works for you | 21:19 |
| blueCmd | hm your log shows that it compiles it as an object - not linking it. I will investigate further | 21:20 |
| blueCmd | 981001-2.c to be exact | 21:22 |
| blueCmd | I 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 bugs | 21:52 |
| blueCmd | well, the #gcc guys couldnt help me - I will just use my files as reference from now on. | 22:38 |
| blueCmd | stekern: 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 then | 22:40 |
| blueCmd | with my uclibc* (not glibc) | 22:41 |
| blueCmd | stekern: I don't know if I merged the pull request correctly - it added a sort of dummy commit | 22:53 |
| * blueCmd feels like a noob when it comes to github :( | 22:53 | |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!