IRC logs for #openrisc Saturday, 2012-09-29

_franck_juliusb: , stekern : as you know very weel the or1k, you should save me some time:00:03
_franck_could you tell me why I can't the instruction at address 0x01fc4f6c ? am I missing something ?00:04
_franck_forgot "see" in my sentence...00:04
stekernat least one of the failures I see in the or1k-linux-gcc regressions doesn't seem to be our fault:
stekern_franck_: from what I can tell from that waveform, icbiu is behaving badly (at least if it whould be considered wishboney). It is terminating the cycle without getting an ack.06:44
stekernIIRC that's not allowed.06:45
stekernhmm, no, you don't have the biu ack in the wave, do you?06:46
stekernI loocked at the icqmem_ack_o06:47
stekernbut the same logic can be applied to icqmem_cycstb_i, it goes low without an ack06:49
stekernso what is getting acked at "10" is the request that got initiated at "-5"06:51
stekernotoh, it seems to make use of the rty signal, I'm not sure how that is interpreted in this context though.06:57
stekerneither case, that doesn't seem to work as it should at least06:58
stekernanother gcc FAIL I can "write off", pr51106-2 fails here too:
stekernI've put the testresults up here:09:16
stekernwill update as progress is made09:17
stekernhmm, I wonder if it's safe to switch on DWARF2_ASM_LINE_DEBUG_INFO in or1k.h16:15
stekernthere is a comment above it that our assembler doesn't support it, but that seems old16:16
stekernjeremybennett: any idea? you switched it off in 4.2.2 commit 251 2010-08-2616:24
stekernI mean, was it not supported because the old as was too old or does it need some target specific implementation?16:43
stekernI can't at least find anything target specific in or1k-src, except in gdb16:43
stekernfound this too:,view,182816:49
chengcaihas or1200 a real product?18:27
stekernyou will never know without patience19:29

Generated by 2.15.2 by Marius Gedminas - find it at!