stekern | this doesn't make sense at all... | 05:53 |
---|---|---|
stekern | http://pastebin.com/Zjif9sqy | 05:53 |
stekern | but in the waveform, execute_delay_slot changes it value even though padv_execute_o doesn't go high | 05:54 |
stekern | bah... I'm looking at post-synthesis signals... | 06:45 |
stekern | problem is that a tick timer exception comes when there is a load in mem stage, the tick timer exception latches the "exception sr" which turns off the mmu | 06:47 |
stekern | the exception waits for the load to finish, but since the mmu has been turned off it's loading from the virtual address and not the physical one... | 06:48 |
* stekern considers getting a rubber duck as well | 06:50 | |
jeremybennett | _franck_: Excellent progress. I would certainly post on the Wiki to compare against the GDB 7.2 results. | 11:22 |
jeremybennett | I would be inclined to start on common groups of FAILs. For example a whole load of double complex stuff fails - that may be a target specific dependency on how double complex is handled. | 11:23 |
jeremybennett | Typically you fix one problem and 20 tests then pass. | 11:24 |
jeremybennett | There are a number of tests that fail generically. IIRC GDB now reports these as KFAIL. That's different from XFAIL, because it means this test fails and it should not, but we know about it and it is a problem in the generic codebase. | 11:25 |
jeremybennett | So all these failures are probably architecture specific. | 11:25 |
jeremybennett | However... | 11:25 |
jeremybennett | In my experience a lot of GDB failures come down to defective DWARF debug information. So sometimes you are finding bugs in the GCC/binutils components generating wrong (or more often insufficient) DWARF. | 11:26 |
blueCmd | stekern: FYI, a full recompile of everything solved the problem | 14:24 |
blueCmd | I tried to link busybox and zsh with eglibc - it worked and started. a couple of syscalls seem to be bugged, but progress! | 17:27 |
stekern | blueCmd: is that with upstream kernel or the "uClibc kernel" | 17:55 |
stekern | ? | 17:55 |
blueCmd | stekern: upstream | 17:55 |
blueCmd | if I understand the question correctly | 17:56 |
stekern | the question was, does it have this patch: http://git.openrisc.net/cgit.cgi/jonas/linux/commit/?id=d79d1b13057b14e5c2bdde9d36745c6ce79c6e6a | 18:15 |
blueCmd | aha, let me check! | 18:16 |
stekern | and this: http://git.openrisc.net/cgit.cgi/jonas/linux/commit/arch/openrisc/kernel/sys_or32.c?id=ba55149979f383504fd5a566d61c75555fe7de88 | 18:16 |
blueCmd | it does | 18:16 |
blueCmd | I would really love to have the eth running on a vanilla kernel | 18:19 |
stekern | I'm not sure if it hurts when you don't need them though, but better to spread th knowledge about it ;) | 18:19 |
blueCmd | stekern: yes, a year ago I ended up writing that patch myself | 18:20 |
blueCmd | haha, I wonder when delay slots will stop biting me? | 21:40 |
blueCmd | chdir returning 50 but kernel returning 0 - assembler looks right for that function. After linking another syscall ends up after it, with syscall number 50. | 21:40 |
blueCmd | add l.nop, recompile, and hopefully success! :D | 21:41 |
blueCmd | hah! zsh running :) | 21:56 |
LoneTech | blueCmd: they do not stop. (got bit by delay slot last friday) | 21:58 |
LoneTech | I've modified or1200 and eCos to use 4 words per exception vector instead of 64. saved a bit of memory | 21:59 |
blueCmd | LoneTech: Ha, I was afraid that was the answer ;) | 22:05 |
LoneTech | since I used the trick of finding the vector used by jump and link, it added 2 with delay slot or 1 without, so I had to change the calculation to match | 22:09 |
blueCmd | heh, speaking of memory | 22:19 |
blueCmd | my initramfs is currently 125 MB | 22:19 |
blueCmd | well, it's not an initramfs anymore to be honest - it's an NFS mount | 22:29 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!