| --- Log opened Wed May 04 00:00:50 2016 | ||
| olofk | shorne: Ah ok. I'd guess that sim needs to implement all the SPRs that gdb asks for then | 01:19 |
|---|---|---|
| olofk | Don't know how many of them that are mandatory to implement. stekern or wallento probably knows that better | 01:20 |
| shorne | olofk: 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 to | 02:34 |
| shorne | probably why they are not implemented | 02:35 |
| shorne | quit | 02:35 |
| shorne | oops | 02:35 |
| olofk | shorne: 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 bit | 03:36 |
| olofk | IIRC we have been lazy before and read SPRs that we don't really should depend on | 03:36 |
| shorne | olofk: 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 handler | 04:40 |
| shorne | *why its going into the handler | 04:41 |
| shorne | in here for reference: newlib/libgloss/or1k/crt0.S | 04:45 |
| shorne | ok, now I can reproduce, ill trace to see whats going on | 05:14 |
| shorne | some how the instruction pointer (pc) gets to a bad address | 05:15 |
| shorne | core: 4 byte read to unmapped address 0x27f7f7c at 0x27f7f7c | 05:15 |
| shorne | we get that error | 05:15 |
| olofk | shorne: Hmm.. at line 153 it copies NPC from SPR. IIRC that isn't a reliable way to do it | 06:09 |
| olofk | wallento, _franck__, stekern: Any idea? | 06:09 |
| stekern | hmm, where? | 06:09 |
| stekern | but no, reading from spr isn't guaranteed to work | 06:09 |
| olofk | stekern: https://github.com/openrisc/newlib/blob/or1k/libgloss/or1k/crt0.S#L153 | 06:10 |
| stekern | I would vaguely expect it to work though, does it not? (too lazy scroll back to get to the beginning of the discussion) | 06:16 |
| olofk | stekern: 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 issue | 06:18 |
| stekern | ah, ok | 06:18 |
| stekern | "I would vaguely expect it to work" applied to existing implementations, not that sim target ;) | 06:19 |
| olofk | stekern: I thought you meant it that way :) | 06:23 |
| olofk | shorne: It could also be the shadow registers that are missing | 06:26 |
| olofk | oh.. and numcores of course. All these are probably added after we did the big facelift in binutils | 06:29 |
| wallento | olofk: that is like the last operation I have left over from the original libgloss code :) | 08:42 |
| wallento | how else to read the NPC? | 08:42 |
| olofk | wallento: IIRC you do a jump to the current instruction and pick up the npc from god knows where | 08:50 |
| olofk | But it's just something I vaguely remember overhearing :) | 08:50 |
| wallento | you cannot be right, you got this from another very poor architecture! ;) | 08:51 |
| olofk | http://www.juliusbaxter.net/openrisc-irc/%23openrisc.2014-05-20.log.html#t21:20 | 08:53 |
| olofk | I know we had something in the documentation database | 08:53 |
| olofk | So l.jal | 08:53 |
| olofk | And read r9 | 08:55 |
| wallento | oh, yeah, but thats something different, right? | 09:01 |
| wallento | the relocation | 09:01 |
| wallento | libgloss just wants to know which exception vector it is in | 09:02 |
| wallento | it seems to me the reasoning there was more that you _can_ do it without SPR | 09:03 |
| olofk | wallento: Still, I think that the SPR isn't required to hold the correct value | 09:28 |
| olofk | Or even exist | 09:28 |
| olofk | shorne: 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.s | 09:33 |
| olofk | Or maybe crt0.S wasn't related to the dump? (https://gist.github.com/stffrdhrn/14589cb51815b04a7ce0e13e38b014ef) | 09:34 |
| wallento | olofk: 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 |
| wallento | Dan__: I am porting it currently | 10:48 |
| wallento | can you drop me a mail so that I can update you once it is done? stefan@wallentowitz.de | 10: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 |
| wallento | yes, please do | 10:51 |
| Dan__ | To both? | 10:52 |
| wallento | as he prefers | 10:52 |
| Dan__ | Done! Thanks! | 10:54 |
| wallento | thanks 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 |
| _franck__ | http://juliusbaxter.net/openrisc-irc/%23openrisc.2014-05-21.log.html | 11:58 |
| stekern | yeah, it's disallowed by the spec, and it's fairly complex to keep it correct at all times during runtime | 12:54 |
| stekern | (when stalled and stepping is a different thing) | 12:55 |
| wallento | okay, we should ge this straight in the spec then | 13:26 |
| wallento | currently its a "should use l.jal" | 13:27 |
| wallento | I will put it in the wiki to be changed to more strict statements | 13:28 |
| wallento | shorne: Any urge to patch libgloss now? | 13:42 |
| olofk | wallento: 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 |
| shorne | olofk: the read for 0x40 is after going into the exception handler. | 19:39 |
| shorne | https://github.com/openrisc/newlib/blob/or1k/libgloss/or1k/exceptions-asm.S#L79 | 19:39 |
| shorne | wallento: 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 thing | 19:44 |
| shorne | To reproduce I can run 'target sim' in gdb... | 19:44 |
| shorne | Test 1. just run, a program completes, no issue | 19:44 |
| shorne | Test 2. set 'break main', then 'run', program fails with going into the handler then : | 19:45 |
| shorne | core: 4 byte read to unmapped address 0x27f7f7c at 0x27f7f7c | 19:45 |
| shorne | address changes a bit different times | 19:45 |
| shorne | so 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 work | 19:46 |
| shorne | wallento: 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 |
| shorne | But 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 irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!