[OpenRISC] mor1kx debug (was [RFC] or1k atomic operation instructions)

[Stefan Kristiansson]

I don't think this discussion belongs in the thread about the atomic operations,
so I've changed the subject.

--debug stub or
-- adbg (this was giving problems the last time I tried, and although it
works with or1200 the adbg's RTL needs a lot of rewriting... just ask
Verilator why)

mor1kx has a debug port, it's not specifically tied to adbg, but
that's likely what will be used.
What problem did you experience and could you provide a testcase where it fails.
What are the problems with verilator and adbg?

We are sort of planning a Bluetooth Low energy chip using an open source
processor and LM32 appears a serious contender to mor1kx. OR1200 is out of
the question.

LM32 is a nice implementation and it's smaller than mor1kx, apart from
that they are pretty much comparable in the 'baremetal' niche.
mor1kx has some 'cool' features (and more coming) that LM32 lacks, but
you might not need or be interested in them.
What speaks in OpenRISC favor is IMO a stronger eco-system around it.

Stefan

[Sébastien Bourdeauducq]

Post by Stefan Kristiansson
What speaks in OpenRISC favor is IMO a stronger eco-system around it.

Well, besides what we (M-Labs) do - which includes some more physics
stuff, MMU development, NetBSD port and MiSoC - LM32 is also used in
White Rabbit:
http://www.ohwr.org/projects/white-rabbit/wiki/WRUsers
There are also a few implementations of LM32 in proprietary ASICs that I
have heard of.

At the point where those projects started, mor1kx wasn't around, and
LM32 was the only reasonable open softcore. It's a bit annoying that the
small open-CPU community is now split between LM32 and mor1kx. Maybe we
could look more at supporting mor1kx as a CPU option for MiSoC (which
would also make LM32 vs. mor1kx benchmarks easier)...

Sébastien

[Stefan Kristiansson]

Post by Sébastien Bourdeauducq

Post by Stefan Kristiansson
What speaks in OpenRISC favor is IMO a stronger eco-system around it.

Well, besides what we (M-Labs) do - which includes some more physics
stuff, MMU development, NetBSD port and MiSoC - LM32 is also used in
http://www.ohwr.org/projects/white-rabbit/wiki/WRUsers
There are also a few implementations of LM32 in proprietary ASICs that I
have heard of.

Yes, I didn't mean to be dismissive of the work you've got going on.
There's a live and kicking community and users around LM32, no doubt about it.
I still think that the sw eco-system with active development on
toolchains etc is stronger on the OpenRISC side.

Post by Sébastien Bourdeauducq
At the point where those projects started, mor1kx wasn't around, and
LM32 was the only reasonable open softcore. It's a bit annoying that the
small open-CPU community is now split between LM32 and mor1kx. Maybe we
could look more at supporting mor1kx as a CPU option for MiSoC (which
would also make LM32 vs. mor1kx benchmarks easier)...

I agree, it's a bit unfortunate.
Otoh, competition has its benefits too, LM32 has been one (among
others) driving force to make mor1kx better. :)
But as you said, the open-CPU community is small, so we definitely
will benefit from collaboration both ways.

Stefan

[Stefan Kristiansson]

Hi Stefan,

Post by Stefan Kristiansson
mor1kx has a debug port, it's not specifically tied to adbg, but
that's likely what will be used.
What problem did you experience and could you provide a testcase where it fails.

Use the DE0 nano board or this branch (https://github.com/openrisc/orpsoc-cores/pull/35) with Icarus or Verilator (which I have
not had time to improve yet but works ok on 32 bit PCs and has not yet been
upgraded to 64-bit machines due to the elf loader problem recently solved).
If you use either of these you will see that breakpoints and namely Step vs.
Next is not working properly. It does not do Next well.

Both breakpoints and single stepping works for me on the de0 nano
board with mor1kx, could you please be more precise?
https://github.com/openrisc/orpsoc-cores/pull/35 is using or1200, I
can't see how that's going to help debug an issue with mor1kx?

Post by Stefan Kristiansson
What are the problems with verilator and adbg?

If you activate the Verilator switch to give all warnings you 'll see many
unacceptable stuff that backend ASIC engineers will simply refuse to go
forward with it. Moreover ADBG is a dead body in the chip if you're not
doing debug, which is not really compatible with a low energy approach, or
complicate matters with gate clocking to power it down etc.

What would you like to use as an alternative then?

In general it would be preferable to solve these sanitary issues first
(debug and profiling) before addressing more complex issues such as
multicore approaches. I am not by any means diminishing the tremendous stuff
that Stefan W. has just presented on the multicore front which certainly
very cool, but I always enjoy playing the janitor-in-chief role :-)

Sure, but then we need a clear picture of what the actual problem is.

Stefan

[Jose Teixeira de Sousa]

Please see more embedded comments.


On Tue, Apr 29, 2014 at 11:47 PM, Stefan Kristiansson <

Hi Stefan,

Post by Stefan Kristiansson
mor1kx has a debug port, it's not specifically tied to adbg, but
that's likely what will be used.
What problem did you experience and could you provide a testcase where

it

Post by Stefan Kristiansson
fails.

Use the DE0 nano board or this branch (

https://github.com/openrisc/orpsoc-cores/pull/35) with Icarus or
Verilator (which I have

not had time to improve yet but works ok on 32 bit PCs and has not yet

been

upgraded to 64-bit machines due to the elf loader problem recently

solved).

If you use either of these you will see that breakpoints and namely Step

vs.

Next is not working properly. It does not do Next well.

Both breakpoints and single stepping works for me on the de0 nano
board with mor1kx, could you please be more precise?
https://github.com/openrisc/orpsoc-cores/pull/35 is using or1200, I
can't see how that's going to help debug an issue with mor1kx?

Please you need just switch it to mor1kx in orpsoc-defines.v. I left it to
OR1200 because that what last was working for me. Please confirm you see
the issue.

You need to create a function f() and set a breakpoint where this function
is called, say line 10.

(gdb) break 10

It actually stops at line 10

(gdb) next

Here instead of moving over f and stopping again at line 11 it actually
enters inside function f(), that is, it behaves sort of like ""step"
instead of like "next".

I hope this is clear now and that you will be able to reproduce it. Please
let me know.

Post by Stefan Kristiansson
What are the problems with verilator and adbg?

If you activate the Verilator switch to give all warnings you 'll see

many

unacceptable stuff that backend ASIC engineers will simply refuse to go
forward with it. Moreover ADBG is a dead body in the chip if you're not
doing debug, which is not really compatible with a low energy approach,

or

complicate matters with gate clocking to power it down etc.

What would you like to use as an alternative then?

We could use a JTAG peripheral or existing RS232 UART and send the GDB
commands directly to the CPU. A simple gdb stub (or server could be
written) to conduct the debug process. LM32 uses a scheme like this.

Since gdb stubs will change the code of the program to implement
breakpoints using software exception support for self modifying code is
needed. However, the recent work on atomic loads and stores may provide
adequate support for this (make sure the memory is not read before the stub
actually modifies it).

In general it would be preferable to solve these sanitary issues first
(debug and profiling) before addressing more complex issues such as
multicore approaches. I am not by any means diminishing the tremendous

stuff

that Stefan W. has just presented on the multicore front which certainly
very cool, but I always enjoy playing the janitor-in-chief role :-)

Sure, but then we need a clear picture of what the actual problem is.

I hope you have a clearer picture now and appreciate your feedback.

Stefan

[Stefan Kristiansson]

Post by Jose Teixeira de Sousa
On Tue, Apr 29, 2014 at 11:47 PM, Stefan Kristiansson

Post by Stefan Kristiansson
Both breakpoints and single stepping works for me on the de0 nano
board with mor1kx, could you please be more precise?
https://github.com/openrisc/orpsoc-cores/pull/35 is using or1200, I
can't see how that's going to help debug an issue with mor1kx?

Please you need just switch it to mor1kx in orpsoc-defines.v. I left it to
OR1200 because that what last was working for me. Please confirm you see the
issue.

No, it's not enough to just switch the define in orpsoc-defines.v
1) or1200_monitor is included in orpsoc_tb.v
2) the verilator testbench only have support for or1200
Those two facts made me make the conclusion that this branch was
or1200 specific.

Now, I'm experiencing strange problems with jtag_vpi together with
mor1kx, but that's unrelated to this.

Post by Jose Teixeira de Sousa
You need to create a function f() and set a breakpoint where this function
is called, say line 10.
(gdb) break 10
It actually stops at line 10
(gdb) next
Here instead of moving over f and stopping again at line 11 it actually
enters inside function f(), that is, it behaves sort of like ""step" instead
of like "next".

Thanks, that was a lot better description! ;)
Yes, I can now reproduce the behaviour above with mor1kx with the
de0_nano board.
I'll investigate further.

Stefan

[Stefan Kristiansson]

On Thu, May 1, 2014 at 10:45 AM, Stefan Kristiansson

Post by Stefan Kristiansson
Yes, I can now reproduce the behaviour above with mor1kx with the
de0_nano board.
I'll investigate further.

I've pushed a couple of commits to openrisc/mor1kx that should fix it,
at least my test cases works now.
Could you please give it a try and confirm that it works for you too now?

Stefan

[Jose Teixeira de Sousa]

Thanks, i'll take a look!!
Em 01/05/2014 22:01, "Stefan Kristiansson" <

Post by Stefan Kristiansson
On Thu, May 1, 2014 at 10:45 AM, Stefan Kristiansson

Post by Stefan Kristiansson
Yes, I can now reproduce the behaviour above with mor1kx with the
de0_nano board.
I'll investigate further.

I've pushed a couple of commits to openrisc/mor1kx that should fix it,
at least my test cases works now.
Could you please give it a try and confirm that it works for you too now?
Stefan

[Jose Teixeira de Sousa]

---------- Forwarded message ----------
From: Jose Teixeira de Sousa <***@inesc-id.pt>
Date: Sat, May 3, 2014 at 4:20 PM
Subject: Re: mor1kx debug (was [RFC] or1k atomic operation instructions)
To: Stefan Kristiansson <***@saunalahti.fi>


Stefan,

it worked with Verilator too! Thanks. I updated branch
https://github.com/jjts/orpsoc-cores/tree/icarus as you were right about
or1200 specificity.

Unfortunately it does not load the elf file for now but you can load it
with gdb. Here's how to run it now if you need:

fusesoc sim --force --sim verilator de0_nano_sim -d -j

In another term do:
src/openocd -f tcl/interface/jtag_vpi.cfg -f tcl/board/or1k_generic.cfg

(make sure JTAG tap is set to MOHOR)

Transcript of gdb session:

(gdb) set remotetimeout unlimited
(gdb) target remote :3333
Remote debugging using :3333
0x00000108 in __reset ()
(gdb) load hello_func
Loading section .vectors, size 0x2000 lma 0x0
Loading section .init, size 0x28 lma 0x2000
Loading section .text, size 0x1735c lma 0x2028
Loading section .fini, size 0x1c lma 0x19384
Loading section .rodata, size 0x131c lma 0x193a0
Loading section .eh_frame, size 0x4 lma 0x1c6bc
Loading section .ctors, size 0x8 lma 0x1c6c0
Loading section .dtors, size 0x8 lma 0x1c6c8
Loading section .jcr, size 0x4 lma 0x1c6d0
Loading section .data, size 0xa40 lma 0x1c6d4
Start address 0x100, load size 110868
Transfer rate: 474 bytes/sec, 7391 bytes/write.
(gdb) l
5 // c = c + 1;
6 // return c;
7 //}
8
9 main(){
10 //int i;
11 // for (i=0; i<1; i++)
12 // printf("Hello, World!\r\n");
13
14 int a = 3;
(gdb)
15 printf("a = %d\r\n", a);
16 int b = 6;
17 printf("b = %d\r\n", b);
18
19 int c, d;
20
21 c = a + b;
22
23 d = a*b;
24
(gdb)
25 // c = foo(c);
26 scanf("%d" , &c);
27 printf("Hello: c = %d\r\n", c);
28 exit(0);
29 }
(gdb)
Line number 30 out of range; hello_func.c has 29 lines.
(gdb) b 17
Breakpoint 1 at 0x240c: file hello_func.c, line 17.
(gdb) c
Continuing.

[Remote target] #1 stopped.
main () at hello_func.c:17
17 printf("b = %d\r\n", b);
(gdb) n

[Remote target] #1 stopped.
main () at hello_func.c:21
21 c = a + b;
(gdb) quit


Regards

Jose









On Thu, May 1, 2014 at 10:00 PM, Stefan Kristiansson <

Post by Stefan Kristiansson
On Thu, May 1, 2014 at 10:45 AM, Stefan Kristiansson

Post by Stefan Kristiansson
Yes, I can now reproduce the behaviour above with mor1kx with the
de0_nano board.
I'll investigate further.

I've pushed a couple of commits to openrisc/mor1kx that should fix it,
at least my test cases works now.
Could you please give it a try and confirm that it works for you too now?
Stefan

--
Jose T. de Sousa, PhD
Office: [phone]
R. Alves Redol 9
1000-029 Lisboa
Portugal

[Jose Teixeira de Sousa]

Hi Stefan

today we tried with De0 Nano and we couldn't even stop at breakpoints. Any
changes that could have caused this since last time ?

Thanks

Jose

Post by Jose Teixeira de Sousa
---------- Forwarded message ----------
Date: Sat, May 3, 2014 at 4:20 PM
Subject: Re: mor1kx debug (was [RFC] or1k atomic operation instructions)
Stefan,
it worked with Verilator too! Thanks. I updated branch
https://github.com/jjts/orpsoc-cores/tree/icarus as you were right about
or1200 specificity.
Unfortunately it does not load the elf file for now but you can load it
fusesoc sim --force --sim verilator de0_nano_sim -d -j
src/openocd -f tcl/interface/jtag_vpi.cfg -f tcl/board/or1k_generic.cfg
(make sure JTAG tap is set to MOHOR)
(gdb) set remotetimeout unlimited
(gdb) target remote :3333
Remote debugging using :3333
0x00000108 in __reset ()
(gdb) load hello_func
Loading section .vectors, size 0x2000 lma 0x0
Loading section .init, size 0x28 lma 0x2000
Loading section .text, size 0x1735c lma 0x2028
Loading section .fini, size 0x1c lma 0x19384
Loading section .rodata, size 0x131c lma 0x193a0
Loading section .eh_frame, size 0x4 lma 0x1c6bc
Loading section .ctors, size 0x8 lma 0x1c6c0
Loading section .dtors, size 0x8 lma 0x1c6c8
Loading section .jcr, size 0x4 lma 0x1c6d0
Loading section .data, size 0xa40 lma 0x1c6d4
Start address 0x100, load size 110868
Transfer rate: 474 bytes/sec, 7391 bytes/write.
(gdb) l
5 // c = c + 1;
6 // return c;
7 //}
8
9 main(){
10 //int i;
11 // for (i=0; i<1; i++)
12 // printf("Hello, World!\r\n");
13
14 int a = 3;
(gdb)
15 printf("a = %d\r\n", a);
16 int b = 6;
17 printf("b = %d\r\n", b);
18
19 int c, d;
20
21 c = a + b;
22
23 d = a*b;
24
(gdb)
25 // c = foo(c);
26 scanf("%d" , &c);
27 printf("Hello: c = %d\r\n", c);
28 exit(0);
29 }
(gdb)
Line number 30 out of range; hello_func.c has 29 lines.
(gdb) b 17
Breakpoint 1 at 0x240c: file hello_func.c, line 17.
(gdb) c
Continuing.
[Remote target] #1 stopped.
main () at hello_func.c:17
17 printf("b = %d\r\n", b);
(gdb) n
[Remote target] #1 stopped.
main () at hello_func.c:21
21 c = a + b;
(gdb) quit
Regards
Jose
On Thu, May 1, 2014 at 10:00 PM, Stefan Kristiansson <

Post by Stefan Kristiansson
On Thu, May 1, 2014 at 10:45 AM, Stefan Kristiansson

Post by Stefan Kristiansson
Yes, I can now reproduce the behaviour above with mor1kx with the
de0_nano board.
I'll investigate further.

I've pushed a couple of commits to openrisc/mor1kx that should fix it,
at least my test cases works now.
Could you please give it a try and confirm that it works for you too now?
Stefan

--
Jose T. de Sousa, PhD
Office: [phone]
R. Alves Redol 9
1000-029 Lisboa
Portugal
--
Jose T. de Sousa, PhD
Office: [phone]
R. Alves Redol 9
1000-029 Lisboa
Portugal

[Stefan Kristiansson]

Hi Stefan
today we tried with De0 Nano and we couldn't even stop at breakpoints. Any
changes that could have caused this since last time ?

I just tested de0_nano out of HEAD of orpsoc-cores and HEAD of mor1kx,
and that worked fine for me.
As for mor1kx commits, there shouldn't be anything new that I can see
would break breakpoints.
The commit that differ are:
https://github.com/openrisc/mor1kx/compare/cbdd7abf528bed632c6bb9eec56f49d4cd5932a7...master

Stefan

[Olof Kindgren]

Could it be that you have an older version of mor1kx in the FuseSoC cache?
Den 28 maj 2014 20:52 skrev "Stefan Kristiansson" <

Post by Stefan Kristiansson

Hi Stefan
today we tried with De0 Nano and we couldn't even stop at breakpoints.

Any

changes that could have caused this since last time ?

I just tested de0_nano out of HEAD of orpsoc-cores and HEAD of mor1kx,
and that worked fine for me.
As for mor1kx commits, there shouldn't be anything new that I can see
would break breakpoints.
https://github.com/openrisc/mor1kx/compare/cbdd7abf528bed632c6bb9eec56f49d4cd5932a7...master
Stefan
_______________________________________________
OpenRISC mailing list
http://lists.openrisc.net/listinfo/openrisc

[Jose Teixeira de Sousa]

hhhmmmm, the program was previously loaded by openOcd .... with or1200 it
seems to work but not with mor1kx.

The only thing we do is to define OR1200 or MOR1Kx in oprsoc-defines and
recompile the FPGA.

Inigo, could you try load the program with gdb, and only after set
breakpoints?

Please let us know if it works this way. If it does we are faced with the
question of why or1200 works with the program pre-loaded by openOcd and
morkx does not. If not something must still be wrong.

Thanks,

Jose

Post by Olof Kindgren
Could it be that you have an older version of mor1kx in the FuseSoC cache?
Den 28 maj 2014 20:52 skrev "Stefan Kristiansson" <

Post by Stefan Kristiansson

Hi Stefan
today we tried with De0 Nano and we couldn't even stop at breakpoints.

Any

changes that could have caused this since last time ?

I just tested de0_nano out of HEAD of orpsoc-cores and HEAD of mor1kx,
and that worked fine for me.
As for mor1kx commits, there shouldn't be anything new that I can see
would break breakpoints.
https://github.com/openrisc/mor1kx/compare/cbdd7abf528bed632c6bb9eec56f49d4cd5932a7...master
Stefan
_______________________________________________
OpenRISC mailing list
http://lists.openrisc.net/listinfo/openrisc

[Stefan Kristiansson]

On Thu, May 29, 2014 at 11:53 AM, Jose Teixeira de Sousa

Post by Jose Teixeira de Sousa
hhhmmmm, the program was previously loaded by openOcd .... with or1200 it
seems to work but not with mor1kx.
The only thing we do is to define OR1200 or MOR1Kx in oprsoc-defines and
recompile the FPGA.
Inigo, could you try load the program with gdb, and only after set
breakpoints?
Please let us know if it works this way. If it does we are faced with the
question of why or1200 works with the program pre-loaded by openOcd and
morkx does not. If not something must still be wrong.

I don't understand what you are trying to do here. Can you try to explain?
I interpreted this as:
1) load program with openocd
2) start gdb
3) set breakpoint
4) run program

Is that what you do?

This works in my setup, it breaks at the breakpoint.

Stefan

[Jose Teixeira de Sousa]

Yes, that is what we are trying to do. Please use the program below and
try break at the fisrt scanf line:

http://wiki.pinksoc.org/doku.php/a_simple_c_program

To run the program without debug at the moment one needs to type CR (Enter
key) + LF (^J) after entering each number.

By the way this is the first introduction to the community of our tutorial
website for openrisc which I used at the workshop at Univ. of Lisbon.

Whoever wishes to contribute to this wiki please let me know.

Regards,

Jose

PS: It needs updateing with the latest fusesoc stuff but it should be ok
for the rest.









On Thu, May 29, 2014 at 11:14 AM, Stefan Kristiansson <

Post by Stefan Kristiansson
On Thu, May 29, 2014 at 11:53 AM, Jose Teixeira de Sousa

Post by Jose Teixeira de Sousa
hhhmmmm, the program was previously loaded by openOcd .... with or1200 it
seems to work but not with mor1kx.
The only thing we do is to define OR1200 or MOR1Kx in oprsoc-defines and
recompile the FPGA.
Inigo, could you try load the program with gdb, and only after set
breakpoints?
Please let us know if it works this way. If it does we are faced with the
question of why or1200 works with the program pre-loaded by openOcd and
morkx does not. If not something must still be wrong.

I don't understand what you are trying to do here. Can you try to explain?
1) load program with openocd
2) start gdb
3) set breakpoint
4) run program
Is that what you do?
This works in my setup, it breaks at the breakpoint.
Stefan

[Stefan Kristiansson]

Yes, that is what we are trying to do. Please use the program below and try
http://wiki.pinksoc.org/doku.php/a_simple_c_program

Yes, that works fine here.

To run the program without debug at the moment one needs to type CR (Enter
key) + LF (^J) after entering each number.
By the way this is the first introduction to the community of our tutorial
website for openrisc which I used at the workshop at Univ. of Lisbon.
Whoever wishes to contribute to this wiki please let me know.

Ah, nice!
I saw some comment about the Pink SoC page somewhere else, but didn't
make the connection then.

Stefan