IRC logs for #openrisc Sunday, 2013-01-27

stekernthis doesn't make sense at all...05:53
stekernhttp://pastebin.com/Zjif9sqy05:53
stekernbut in the waveform, execute_delay_slot changes it value even though padv_execute_o doesn't go high05:54
stekernbah... I'm looking at post-synthesis signals...06:45
stekernproblem 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 mmu06:47
stekernthe 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 well06:50
jeremybennett_franck_: Excellent progress. I would certainly post on the Wiki to compare against the GDB 7.2 results.11:22
jeremybennettI 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
jeremybennettTypically you fix one problem and 20 tests then pass.11:24
jeremybennettThere 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
jeremybennettSo all these failures are probably architecture specific.11:25
jeremybennettHowever...11:25
jeremybennettIn 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
blueCmdstekern: FYI, a full recompile of everything solved the problem14:24
blueCmdI tried to link busybox and zsh with eglibc - it worked and started. a couple of syscalls seem to be bugged, but progress!17:27
stekernblueCmd: is that with upstream kernel or the "uClibc kernel"17:55
stekern?17:55
blueCmdstekern: upstream17:55
blueCmdif I understand the question correctly17:56
stekernthe question was, does it have this patch: http://git.openrisc.net/cgit.cgi/jonas/linux/commit/?id=d79d1b13057b14e5c2bdde9d36745c6ce79c6e6a18:15
blueCmdaha, let me check!18:16
stekernand this: http://git.openrisc.net/cgit.cgi/jonas/linux/commit/arch/openrisc/kernel/sys_or32.c?id=ba55149979f383504fd5a566d61c75555fe7de8818:16
blueCmdit does18:16
blueCmdI would really love to have the eth running on a vanilla kernel18:19
stekernI'm not sure if it hurts when you don't need them though, but better to spread th knowledge about it ;)18:19
blueCmdstekern: yes, a year ago I ended up writing that patch myself18:20
blueCmdhaha, I wonder when delay slots will stop biting me?21:40
blueCmdchdir 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
blueCmdadd l.nop, recompile, and hopefully success! :D21:41
blueCmdhah! zsh running :)21:56
LoneTechblueCmd: they do not stop. (got bit by delay slot last friday)21:58
LoneTechI've modified or1200 and eCos to use 4 words per exception vector instead of 64. saved a bit of memory21:59
blueCmdLoneTech: Ha, I was afraid that was the answer ;)22:05
LoneTechsince 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 match22:09
blueCmdheh, speaking of memory22:19
blueCmdmy initramfs is currently 125 MB22:19
blueCmdwell, it's not an initramfs anymore to be honest - it's an NFS mount22:29

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!