PC jump to a invalid address after du restarted.

[xfguo]

Hi, I have a problem when I am using mor1kx.

My env:

• mor1kx espresso
• ibus type => CLASSIC
• enable debug_unit

I use openocd,jtag_vpi and gdb to debug the system, after I uploaded the elf program and let it start to run, the PC was jump to 0x4.

I think it might be a bug when du stop the cpu, and at the same time, CPU is in branch or delay slot.

And I think after a du_restart issued, CPU might need to wait until something is finished.

Let me explain it, It is a little bit complicated, so pls correct me if...

---

1. In the beginning, CPU is running normally.
2. When CPU is just execute an branch inst. with a delay slot (ctrl_branch_occur is HIGH), CPU is stalled by external signal (du_stall by debug_unit by gdb)
3. Then execute_delay_slot and ctrl_branch_occur_o become always HIGH until the du_stall_i is de-asserted.

---

1. After gdb upload everything, it send a du_restart_o pulse to let CPU jump to 0x100
2. Then I think because ctrl_branch_occur_o is HIGH, so CPU believe it is in branching, but actually the first two instructions are two l.nop.
3. PC jump to 0x4, then everything messed up. -_-

---

Another clue is if I modify

diff mor1kx_bus_if_wb32.v
@@ 179
     assign wbm_stb_o = cpu_req_i & !cycle_end;
-    assign wbm_cyc_o = cpu_req_i;
+    assign wbm_cyc_o = cpu_req_i & !cycle_end;

It seems that it is fixed, I am really not sure about this!

Thanks!

[skristiansson]

On Sat, Feb 7, 2015 at 12:53 PM, Xiongfei(Alex) GUO <
[email protected]> wrote:

Hi, I have a problem when I am using mor1kx.

My env:

• mor1kx espresso
• ibus type => CLASSIC
• enable debug_unit

I use openocd,jtag_vpi and gdb to debug the system, after I uploaded the
elf program and let it start to run, the PC was jump to 0x4.

To get the facts straight here, did you set the pc to 0x100 after you had
uploaded the program and then after you run the program, it's still in 0x4?

I think it might be a bug when du stop the cpu, and at the same time,
CPU is in branch or delay slot.

Let me explain it, It is a little bit complicated, so pls correct me if...

[image: happen]
https://cloud.githubusercontent.com/assets/912165/6091851/3634173a-aefa-11e4-9306-5fbfa62be6af.jpg

1. In the beginning, CPU is running normally.
2. When CPU is just execute an branch inst. with a delay slot (
   ctrl_branch_occur is HIGH), CPU is stalled by external signal (du_stall
   by debug_unit by gdb)
3. Then execute_delay_slot and ctrl_branch_occur_o become always HIGH
   until the du_stall_i is de-asserted.

---

[image: fail]
https://cloud.githubusercontent.com/assets/912165/6091850/2f469916-aefa-11e4-8f0c-b670c0eb09cd.jpg

1. After gdb upload everything, it send a du_restart_o pulse to let
   CPU jump to 0x100

du_restart_o shouldn't reset the cpu, it should just restart the pipeline
from the current PC.
Where 'current PC' depends a little bit on the situation where the cpu was
halted, and if you manually override the PC by writing to the NPC SPR, that
should be used.
It's quite possible that you have found a bug in that logic, you can take a
look at it here

https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx_ctrl_espresso.v#L1233

2. Then I think because ctrl_branch_occur_o is HIGH, so CPU believe it
   is in branching, but actually the first two instructions are two l.nop.
3. PC jump to 0x4, then everything messed up. -_-

---

Another clue is if I modify

diff mor1kx_bus_if_wb32.v
@@ 179
assign wbm_stb_o = cpu_req_i & !cycle_end;- assign wbm_cyc_o = cpu_req_i;+ assign wbm_cyc_o = cpu_req_i & !cycle_end;

Hmm, that probably just fix the symptoms, not the cause.

Stefan

[xfguo]

To get the facts straight here, did you set the pc to 0x100 after you had
uploaded the program and then after you run the program, it's still in 0x4?

Yes, here is my gdb script.

file app.or32
target remote :3333
load app.or32
set $pc=0x100
cont

---

from the current PC.
Where 'current PC' depends a little bit on the situation where the cpu was
halted, and if you manually override the PC by writing to the NPC SPR, that
should be used.
It's quite possible that you have found a bug in that logic, you can take a
look at it here

I need some time to simulate them and maybe start at next weed end.

---

Hmm, that probably just fix the symptoms, not the cause.

I think so too, but how could it happen, it must have some inherent relation.