| --- Log opened Mon Mar 07 00:00:23 2016 | ||
| stekern | shorne: no, that's fine. so, yes, sounds like you might be hitting something else | 03:59 |
|---|---|---|
| stekern | ...but, that said, how are you debugging where in the code you are failing? | 04:03 |
| stekern | and you need to set r3 = 0 before you jump to 0x100, otherwise the 'the dtb reference is null' statement doesn't hold, do you do that? | 04:07 |
| stekern | s/doesn't hold/might not hold | 04:08 |
| shorne | stekern: I dont think I need to set r3 to zero before going to 0x100, this is in head.S | 04:46 |
| shorne | l.lwz r3,0(r25) | 04:46 |
| shorne | (load r3 with address ar 25) which is not the fdt | 04:46 |
| shorne | then if the fdt check fails | 04:46 |
| shorne | there is this | 04:46 |
| shorne | .or r25,r0,r0 | 04:47 |
| shorne | whck clears r25 | 04:47 |
| shorne | then | 04:47 |
| shorne | l.or r3,r0,r25 | 04:47 |
| shorne | which set r3 to r25, in my case it shold be 0x0 | 04:47 |
| stekern | yeah, but you have: | 04:48 |
| stekern | _start: /* save kernel parameters */ l.orr25,r0,r3/* pointer to fdt */ | 04:48 |
| shorne | yeah, but as long as the fdt magic check fails it gets set to 0x0 | 04:49 |
| shorne | right? | 04:49 |
| stekern | yes, but if r3 points to somewhere which will cause a mmu fault, you'll get the fault before the magic check | 04:50 |
| stekern | you load something from the address r3 points to, which might contain the magic | 04:50 |
| shorne | I see for dmmu | 04:50 |
| shorne | right, I see your point now | 04:50 |
| shorne | well, I get past there | 04:50 |
| shorne | it fails here | 04:51 |
| stekern | how do you determine that you get past there? which cpu-core are you using? | 04:51 |
| shorne | l.jalr r24 | 04:51 |
| shorne | I am using or1200, and debugging (instruction stepping) in gdb | 04:51 |
| shorne | after the jalr, I can see the debugger shows it tries to jump to 0c0038xxxxx something | 04:52 |
| shorne | then it jumps to bus exception 0x200 | 04:52 |
| stekern | but you get a databus error, you can't get that from the jump | 04:52 |
| shorne | ok, I see, let me get the debugger running | 04:54 |
| shorne | I am using or1200 from git last week | 04:55 |
| stekern | no, sorry, actually 0x200 is just a bus error, so it could be an ibus error | 04:55 |
| shorne | yea, I was guessing that it meant that it really tried to access 0xc0038xxx physical address, which didnt exist | 04:55 |
| shorne | I was going to try and debug the initial 0xa00 routine which sets up the IMMU MR and TR registers to see what its putting into there | 04:56 |
| shorne | Also, I am running linux kernel from openrisc/linux + merged with 4.5 linus head :) (doing things the hard way) | 04:57 |
| stekern | can you boot that in or1ksim? and have you tried using mor1kx instead of or1200? | 04:58 |
| shorne | ill try both, feeding kid now :) | 05:01 |
| shorne | what is different with mor1kx? | 05:02 |
| shorne | I see some details about mor1kx on http://opencores.org/or1k/OR1K_CPU_Cores | 05:05 |
| shorne | the strange thing is that sometimes I do get serial output which just does a bunch of stack frame dumps. | 05:09 |
| shorne | which seems to mean sometimes its getting past the dts loading, since it knows where the serial device is | 05:10 |
| stekern | mor1kx is newer, more efficient | 05:13 |
| shorne | cool, I saw using the orpsoc-cores de0_nano system, which I guess is not linking that in. Ill change it over to mor1kx if possible | 05:15 |
| shorne | stekern: I ran my kernel in or1ksim and it runs ok. | 06:35 |
| shorne | will try the new core | 06:35 |
| olofk | shorne: Hmm.. the de0_nano system should use mor1kx by default | 09:56 |
| olofk | We're seriously trying to move people away from or1200 to mor1kx | 09:57 |
| olofk | looks like the de0 nano system uses mor1kx by default | 10:12 |
| shorne | olofk: you are right, it is mor1kx | 15:29 |
| shorne | I guess I always thought it was or1200 because I saw it in de0_nano_top.v | 16:34 |
| shorne | but there is an ifdef between MOR1KX and OR1200 | 16:35 |
| --- Log closed Tue Mar 08 00:00:24 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!