search

openrisc / mor1kx

mor1kx - an OpenRISC 1000 processor IP core
Other
493 stars 147 forks source link

PC jump to a invalid address after du restarted. #25

Open xfguo opened 9 years ago

xfguo commented 9 years ago

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

My env:

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...

happen

  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.

fail

  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 commented 9 years ago

On Sat, Feb 7, 2015 at 12:53 PM, Xiongfei(Alex) GUO < notifications@github.com> 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

1.

  1. 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.
  2. 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 commented 9 years ago

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.