IRC logs for #openrisc Wednesday, 2016-05-04

--- Log opened Wed May 04 00:00:50 2016
olofkshorne: Ah ok. I'd guess that sim needs to implement all the SPRs that gdb asks for then01:19
olofkDon't know how many of them that are mandatory to implement. stekern or wallento probably knows that better01:20
shorneolofk: it looks like many are implemented, these 2 get read in the exception hanlder, so I guess its not a normal place for the cpu to get to02:34
shorneprobably why they are not implemented02:35
olofkshorne: This of course raises the question if they are supposed to be read from the interrupt handler. Haven't looked it up, and I suspect the answer is yes, but it's a good opportunity to think it through a bit03:36
olofkIIRC we have been lazy before and read SPRs that we don't really should depend on03:36
shorneolofk: I agree, the code that reads them is the newlib bare metal interrupt handlers.  So the code is right.  But I am trying to find we we are going into the handler04:40
shorne*why its going into the handler04:41
shornein here for reference: newlib/libgloss/or1k/crt0.S04:45
shorneok, now I can reproduce, ill trace to see whats going on05:14
shornesome how the instruction pointer (pc) gets to a bad address05:15
shornecore: 4 byte read to unmapped address 0x27f7f7c at 0x27f7f7c05:15
shornewe get that error05:15
olofkshorne: Hmm.. at line 153 it copies NPC from SPR. IIRC that isn't a reliable way to do it06:09
olofkwallento, _franck__, stekern: Any idea?06:09
stekernhmm, where?06:09
stekernbut no, reading from spr isn't guaranteed to work06:09
stekernI would vaguely expect it to work though, does it not? (too lazy scroll back to get to the beginning of the discussion)06:16
olofkstekern: shorne is improving the sim backend in binutils (to used instead of the or1ksim hack), and it fails reading some SPR. Not sure this is the problem, but I thought it could be a potential issue06:18
stekernah, ok06:18
stekern"I would vaguely expect it to work" applied to existing implementations, not that sim target ;)06:19
olofkstekern: I thought you meant it that way :)06:23
olofkshorne: It could also be the shadow registers that are missing06:26
olofkoh.. and numcores of course. All these are probably added after we did the big facelift in binutils06:29
wallentoolofk: that is like the last operation I have left over from the original libgloss code :)08:42
wallentohow else to read the NPC?08:42
olofkwallento: IIRC you do a jump to the current instruction and pick up the npc from god knows where08:50
olofkBut it's just something I vaguely remember overhearing :)08:50
wallentoyou cannot be right, you got this from another very poor architecture! ;)08:51
olofkI know we had something in the documentation database08:53
olofkSo l.jal08:53
olofkAnd read r908:55
wallentooh, yeah, but thats something different, right?09:01
wallentothe relocation09:01
wallentolibgloss just wants to know which exception vector it is in09:02
wallentoit seems to me the reasoning there was more that you _can_ do it without SPR09:03
olofkwallento: Still, I think that the SPR isn't required to hold the correct value09:28
olofkOr even exist09:28
olofkshorne: Looking at the dump you sent, 0x10 is indeed the npc spr, but I can't see that it tries to read spr 0x40 anywhere in crt0.s09:33
olofkOr maybe crt0.S wasn't related to the dump? (
wallentoolofk: I don't get it. SPR_NPC is defined in the spec, why should it not be implemented or hold a wrong value?10:07
Dan__Hello!  Can anyone tell me if the OpenRISC platform has ever been ported to the Arty board before?10:18
wallentoDan__: I am porting it currently10:48
wallentocan you drop me a mail so that I can update you once it is done? stefan@wallentowitz.de10:49
Dan__Actually, I'm trying to answer a question [NelsonWee88] asked on a Digilent forum.  May I pass him your e-mail address, or would you rather I just sent him to this channel?10:50
wallentoyes, please do10:51
Dan__To both?10:52
wallentoas he prefers10:52
Dan__Done!  Thanks!10:54
wallentothanks to you for forwarding :)11:04
Dan__Not a problem.11:04
_franck__wallento: stekern said some times ago: "and please, do not use SPR_NPC, it's disallowed by the arch spec"11:57
stekernyeah, it's disallowed by the spec, and it's fairly complex to keep it correct at all times during runtime12:54
stekern(when stalled and stepping is a different thing)12:55
wallentookay, we should ge this straight in the spec then13:26
wallentocurrently its a "should use l.jal"13:27
wallentoI will put it in the wiki to be changed to more strict statements13:28
wallentoshorne: Any urge to patch libgloss now?13:42
olofkwallento: What is the preferred way to do or1k patches for newlib/libgloss? Just send them upstream right away, or apply them to openrisc/newlib, and in that case, which branch?15:58
shorneolofk: the read for 0x40 is after going into the exception handler.19:39
shornewallento: no plan to patch it now :). For now I am looking at why its getting into the exception handler.  If it turns out the problem I will look into. Bug I agree reading from r9 after jump is the right thing19:44
shorneTo reproduce I can run 'target sim' in gdb...19:44
shorneTest 1. just run, a program completes, no issue19:44
shorneTest 2. set 'break main', then 'run', program fails with going into the handler then :19:45
shornecore: 4 byte read to unmapped address 0x27f7f7c at 0x27f7f7c19:45
shorneaddress changes a bit different times19:45
shorneso when adding the break point it fails. So I am guessing something in the single step sim/hardware is not implemented correct.  I need to read the spec on how debug should work19:46
shornewallento: OTOH, I think the patch would be pretty straight forward.  Just dont store NPC in r3, use jal, then in the _or1k_exception_handler use r9 for (Determine offset in table of exception handler).19:52
shorneBut jal, would cause us to lose the original r9.  I guess we need to save is somewhere first?19:54
--- Log closed Thu May 05 00:00:52 2016

Generated by 2.15.2 by Marius Gedminas - find it at!