Emulators such as BDI2000 and CodeWarrior needs to have MSR_DE set
in order to support break points.
This adds MSR_DE for kernel space only.
---
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects, therfore
this RFC.
arch/powerpc/include/asm/reg.h | 2 +-
arch/powerpc/include/asm/reg_booke.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
From: Dan Malek <hidden> Date: 2012-05-30 08:16:03
Hi Joakim.
On May 30, 2012, at 12:43 AM, Joakim Tjernlund wrote:
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects,
therfore
this RFC.
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if MSR_DE
is set, you will have problems with software debuggers that
utilize the the debugging registers in the chip itself. You only want
to force this to be set when using the BDI, not at other times.
Thanks.
-- Dan
From: Abatron Support <hidden> Date: 2012-05-30 12:26:52
quoted
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects,
therfore
this RFC.
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if MSR_DE
is set, you will have problems with software debuggers that
utilize the the debugging registers in the chip itself. You only want
to force this to be set when using the BDI, not at other times.
This MSR_DE is also of interest and used for software debuggers that
make use of the debug registers. Only if MSR_DE is set then debug
interrupts are generated. If a debug event leads to a debug interrupt
handled by a software debugger or if it leads to a debug halt handled
by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
The "e500 Core Family Reference Manual" chapter "Chapter 8
Debug Support" explains in detail the effect of MSR_DE.
Ruedi
From: Bob Cochran <hidden> Date: 2012-05-30 14:27:53
On 05/30/2012 03:43 AM, Joakim Tjernlund wrote:
Emulators such as BDI2000 and CodeWarrior needs to have MSR_DE set
in order to support break points.
This adds MSR_DE for kernel space only.
---
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects, therfore
this RFC.
arch/powerpc/include/asm/reg.h | 2 +-
arch/powerpc/include/asm/reg_booke.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
snip
I believe that additional patches are required for CodeWarrior to work
properly (e.g., assembly start up). I think the patches should come
from Freescale. For whatever reason, they include them in their SDK,
but haven't submitted them for inclusion in the mainline.
As a developer on Freescale Power products, I would like to see
Freescale offer up a CodeWarrior patch set, so I don't have to manage
the patches myself when working outside the SDK (i.e., on a more recent
kernel).
Abatron Support [off-list ref] wrote on 2012/05/30 14:08:26:
quoted
quoted
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects,
therfore
this RFC.
quoted
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if MSR_DE
is set, you will have problems with software debuggers that
utilize the the debugging registers in the chip itself. You only want
to force this to be set when using the BDI, not at other times.
This MSR_DE is also of interest and used for software debuggers that
make use of the debug registers. Only if MSR_DE is set then debug
interrupts are generated. If a debug event leads to a debug interrupt
handled by a software debugger or if it leads to a debug halt handled
by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
The "e500 Core Family Reference Manual" chapter "Chapter 8
Debug Support" explains in detail the effect of MSR_DE.
So what is the verdict on this? I don't buy into Dan argument without some
hard data.
Jocke
From: Abatron Support <hidden> Date: 2012-05-31 09:31:13
Abatron Support [off-list ref] wrote on 2012/05/30 14:08:26:
quoted
quoted
quoted
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects,
therfore
this RFC.
quoted
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if MSR_DE
is set, you will have problems with software debuggers that
utilize the the debugging registers in the chip itself. You only want
to force this to be set when using the BDI, not at other times.
This MSR_DE is also of interest and used for software debuggers that
make use of the debug registers. Only if MSR_DE is set then debug
interrupts are generated. If a debug event leads to a debug interrupt
handled by a software debugger or if it leads to a debug halt handled
by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
The "e500 Core Family Reference Manual" chapter "Chapter 8
Debug Support" explains in detail the effect of MSR_DE.
So what is the verdict on this? I don't buy into Dan argument without some
hard data.
What I tried to mention is that handling the MSR_DE correct is not only
an emulator (JTAG debugger) requirement. Also a software debugger may
depend on a correct handled MSR_DE bit.
Ruedi
Abatron Support [off-list ref] wrote on 2012/05/31 11:30:57:
quoted
Abatron Support [off-list ref] wrote on 2012/05/30 14:08:26:
quoted
quoted
quoted
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects,
therfore
this RFC.
quoted
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if MSR_DE
is set, you will have problems with software debuggers that
utilize the the debugging registers in the chip itself. You only want
to force this to be set when using the BDI, not at other times.
This MSR_DE is also of interest and used for software debuggers that
make use of the debug registers. Only if MSR_DE is set then debug
interrupts are generated. If a debug event leads to a debug interrupt
handled by a software debugger or if it leads to a debug halt handled
by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
The "e500 Core Family Reference Manual" chapter "Chapter 8
Debug Support" explains in detail the effect of MSR_DE.
quoted
So what is the verdict on this? I don't buy into Dan argument without some
hard data.
What I tried to mention is that handling the MSR_DE correct is not only
an emulator (JTAG debugger) requirement. Also a software debugger may
depend on a correct handled MSR_DE bit.
Yes, that made sense to me too. How would SW debuggers work if the kernel keeps
turning off MSR_DE first chance it gets?
Jocke
From: Scott Wood <hidden> Date: 2012-05-31 17:48:14
On 05/31/2012 04:56 AM, Joakim Tjernlund wrote:
Abatron Support [off-list ref] wrote on 2012/05/31 11:30:57:
quoted
quoted
Abatron Support [off-list ref] wrote on 2012/05/30 14:08:26:
quoted
quoted
quoted
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects,
therfore
this RFC.
quoted
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if MSR_DE
is set, you will have problems with software debuggers that
utilize the the debugging registers in the chip itself. You only want
to force this to be set when using the BDI, not at other times.
This MSR_DE is also of interest and used for software debuggers that
make use of the debug registers. Only if MSR_DE is set then debug
interrupts are generated. If a debug event leads to a debug interrupt
handled by a software debugger or if it leads to a debug halt handled
by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
The "e500 Core Family Reference Manual" chapter "Chapter 8
Debug Support" explains in detail the effect of MSR_DE.
quoted
So what is the verdict on this? I don't buy into Dan argument without some
hard data.
What I tried to mention is that handling the MSR_DE correct is not only
an emulator (JTAG debugger) requirement. Also a software debugger may
depend on a correct handled MSR_DE bit.
Yes, that made sense to me too. How would SW debuggers work if the kernel keeps
turning off MSR_DE first chance it gets?
The kernel selectively enables MSR_DE when it wants to debug. I'm not
sure if anything will be bothered by leaving it on all the time. This
is something we need for virtualization as well, so a hypervisor can
debug the guest.
-Scott
Scott Wood [off-list ref] wrote on 2012/05/31 19:47:53:
On 05/31/2012 04:56 AM, Joakim Tjernlund wrote:
quoted
Abatron Support [off-list ref] wrote on 2012/05/31 11:30:57:
quoted
quoted
Abatron Support [off-list ref] wrote on 2012/05/30 14:08:26:
quoted
quoted
quoted
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects,
therfore
this RFC.
quoted
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if MSR_DE
is set, you will have problems with software debuggers that
utilize the the debugging registers in the chip itself. You only want
to force this to be set when using the BDI, not at other times.
This MSR_DE is also of interest and used for software debuggers that
make use of the debug registers. Only if MSR_DE is set then debug
interrupts are generated. If a debug event leads to a debug interrupt
handled by a software debugger or if it leads to a debug halt handled
by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
The "e500 Core Family Reference Manual" chapter "Chapter 8
Debug Support" explains in detail the effect of MSR_DE.
quoted
So what is the verdict on this? I don't buy into Dan argument without some
hard data.
What I tried to mention is that handling the MSR_DE correct is not only
an emulator (JTAG debugger) requirement. Also a software debugger may
depend on a correct handled MSR_DE bit.
Yes, that made sense to me too. How would SW debuggers work if the kernel keeps
turning off MSR_DE first chance it gets?
The kernel selectively enables MSR_DE when it wants to debug. I'm not
sure if anything will be bothered by leaving it on all the time. This
is something we need for virtualization as well, so a hypervisor can
debug the guest.
hmm, I read that as you as in favour of the patch?
From: Scott Wood <hidden> Date: 2012-05-31 21:43:45
On 05/31/2012 04:38 PM, Joakim Tjernlund wrote:
Scott Wood [off-list ref] wrote on 2012/05/31 19:47:53:
quoted
On 05/31/2012 04:56 AM, Joakim Tjernlund wrote:
quoted
Abatron Support [off-list ref] wrote on 2012/05/31 11:30:57:
quoted
quoted
Abatron Support [off-list ref] wrote on 2012/05/30 14:08:26:
quoted
quoted
quoted
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects,
therfore
this RFC.
quoted
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if MSR_DE
is set, you will have problems with software debuggers that
utilize the the debugging registers in the chip itself. You only want
to force this to be set when using the BDI, not at other times.
This MSR_DE is also of interest and used for software debuggers that
make use of the debug registers. Only if MSR_DE is set then debug
interrupts are generated. If a debug event leads to a debug interrupt
handled by a software debugger or if it leads to a debug halt handled
by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
The "e500 Core Family Reference Manual" chapter "Chapter 8
Debug Support" explains in detail the effect of MSR_DE.
quoted
So what is the verdict on this? I don't buy into Dan argument without some
hard data.
What I tried to mention is that handling the MSR_DE correct is not only
an emulator (JTAG debugger) requirement. Also a software debugger may
depend on a correct handled MSR_DE bit.
Yes, that made sense to me too. How would SW debuggers work if the kernel keeps
turning off MSR_DE first chance it gets?
The kernel selectively enables MSR_DE when it wants to debug. I'm not
sure if anything will be bothered by leaving it on all the time. This
is something we need for virtualization as well, so a hypervisor can
debug the guest.
hmm, I read that as you as in favour of the patch?
I'd want some confirmation that it doesn't break anything, and that
there aren't any other places that need MSR_DE that this doesn't cover,
but in general yes.
-Scott
Scott Wood [off-list ref] wrote on 2012/05/31 23:43:34:
On 05/31/2012 04:38 PM, Joakim Tjernlund wrote:
quoted
Scott Wood [off-list ref] wrote on 2012/05/31 19:47:53:
quoted
On 05/31/2012 04:56 AM, Joakim Tjernlund wrote:
quoted
Abatron Support [off-list ref] wrote on 2012/05/31 11:30:57:
quoted
quoted
Abatron Support [off-list ref] wrote on 2012/05/30 14:08:26:
quoted
quoted
quoted
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects,
therfore
this RFC.
quoted
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if MSR_DE
is set, you will have problems with software debuggers that
utilize the the debugging registers in the chip itself. You only want
to force this to be set when using the BDI, not at other times.
This MSR_DE is also of interest and used for software debuggers that
make use of the debug registers. Only if MSR_DE is set then debug
interrupts are generated. If a debug event leads to a debug interrupt
handled by a software debugger or if it leads to a debug halt handled
by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
The "e500 Core Family Reference Manual" chapter "Chapter 8
Debug Support" explains in detail the effect of MSR_DE.
quoted
So what is the verdict on this? I don't buy into Dan argument without some
hard data.
What I tried to mention is that handling the MSR_DE correct is not only
an emulator (JTAG debugger) requirement. Also a software debugger may
depend on a correct handled MSR_DE bit.
Yes, that made sense to me too. How would SW debuggers work if the kernel keeps
turning off MSR_DE first chance it gets?
The kernel selectively enables MSR_DE when it wants to debug. I'm not
sure if anything will be bothered by leaving it on all the time. This
is something we need for virtualization as well, so a hypervisor can
debug the guest.
hmm, I read that as you as in favour of the patch?
I'd want some confirmation that it doesn't break anything, and that
there aren't any other places that need MSR_DE that this doesn't cover,
but in general yes.
From: Scott Wood <hidden> Date: 2012-05-31 22:17:01
On 05/31/2012 05:14 PM, Joakim Tjernlund wrote:
Scott Wood [off-list ref] wrote on 2012/05/31 23:43:34:
quoted
On 05/31/2012 04:38 PM, Joakim Tjernlund wrote:
quoted
Scott Wood [off-list ref] wrote on 2012/05/31 19:47:53:
quoted
On 05/31/2012 04:56 AM, Joakim Tjernlund wrote:
quoted
Abatron Support [off-list ref] wrote on 2012/05/31 11:30:57:
quoted
quoted
Abatron Support [off-list ref] wrote on 2012/05/30 14:08:26:
quoted
quoted
quoted
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects,
therfore
this RFC.
quoted
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if MSR_DE
is set, you will have problems with software debuggers that
utilize the the debugging registers in the chip itself. You only want
to force this to be set when using the BDI, not at other times.
This MSR_DE is also of interest and used for software debuggers that
make use of the debug registers. Only if MSR_DE is set then debug
interrupts are generated. If a debug event leads to a debug interrupt
handled by a software debugger or if it leads to a debug halt handled
by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
The "e500 Core Family Reference Manual" chapter "Chapter 8
Debug Support" explains in detail the effect of MSR_DE.
quoted
So what is the verdict on this? I don't buy into Dan argument without some
hard data.
What I tried to mention is that handling the MSR_DE correct is not only
an emulator (JTAG debugger) requirement. Also a software debugger may
depend on a correct handled MSR_DE bit.
Yes, that made sense to me too. How would SW debuggers work if the kernel keeps
turning off MSR_DE first chance it gets?
The kernel selectively enables MSR_DE when it wants to debug. I'm not
sure if anything will be bothered by leaving it on all the time. This
is something we need for virtualization as well, so a hypervisor can
debug the guest.
hmm, I read that as you as in favour of the patch?
I'd want some confirmation that it doesn't break anything, and that
there aren't any other places that need MSR_DE that this doesn't cover,
but in general yes.
Then you need to test drive the patch :)
I was thinking more along the lines of someone who's more familiar with
the relevant parts of the code confirming that it's really OK, not just
testing that it doesn't blow up in my face.
-Scott
Scott Wood [off-list ref] wrote on 2012/06/01 00:16:53:
On 05/31/2012 05:14 PM, Joakim Tjernlund wrote:
quoted
Scott Wood [off-list ref] wrote on 2012/05/31 23:43:34:
quoted
On 05/31/2012 04:38 PM, Joakim Tjernlund wrote:
quoted
Scott Wood [off-list ref] wrote on 2012/05/31 19:47:53:
quoted
On 05/31/2012 04:56 AM, Joakim Tjernlund wrote:
quoted
Abatron Support [off-list ref] wrote on 2012/05/31 11:30:57:
quoted
quoted
Abatron Support [off-list ref] wrote on 2012/05/30 14:08:26:
quoted
quoted
quoted
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects,
therfore
this RFC.
quoted
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if MSR_DE
is set, you will have problems with software debuggers that
utilize the the debugging registers in the chip itself. You only want
to force this to be set when using the BDI, not at other times.
This MSR_DE is also of interest and used for software debuggers that
make use of the debug registers. Only if MSR_DE is set then debug
interrupts are generated. If a debug event leads to a debug interrupt
handled by a software debugger or if it leads to a debug halt handled
by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
The "e500 Core Family Reference Manual" chapter "Chapter 8
Debug Support" explains in detail the effect of MSR_DE.
quoted
So what is the verdict on this? I don't buy into Dan argument without some
hard data.
What I tried to mention is that handling the MSR_DE correct is not only
an emulator (JTAG debugger) requirement. Also a software debugger may
depend on a correct handled MSR_DE bit.
Yes, that made sense to me too. How would SW debuggers work if the kernel keeps
turning off MSR_DE first chance it gets?
The kernel selectively enables MSR_DE when it wants to debug. I'm not
sure if anything will be bothered by leaving it on all the time. This
is something we need for virtualization as well, so a hypervisor can
debug the guest.
hmm, I read that as you as in favour of the patch?
I'd want some confirmation that it doesn't break anything, and that
there aren't any other places that need MSR_DE that this doesn't cover,
but in general yes.
Then you need to test drive the patch :)
I was thinking more along the lines of someone who's more familiar with
the relevant parts of the code confirming that it's really OK, not just
testing that it doesn't blow up in my face.
Scott Wood [off-list ref] wrote on 2012/06/01 00:16:53:
On 05/31/2012 05:14 PM, Joakim Tjernlund wrote:
quoted
Scott Wood [off-list ref] wrote on 2012/05/31 23:43:34:
quoted
On 05/31/2012 04:38 PM, Joakim Tjernlund wrote:
quoted
Scott Wood [off-list ref] wrote on 2012/05/31 19:47:53:
quoted
On 05/31/2012 04:56 AM, Joakim Tjernlund wrote:
quoted
Abatron Support [off-list ref] wrote on 2012/05/31 11:30:57:
quoted
quoted
Abatron Support [off-list ref] wrote on 2012/05/30 14:08:26:
quoted
quoted
quoted
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects,
therfore
this RFC.
quoted
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if MSR_DE
is set, you will have problems with software debuggers that
utilize the the debugging registers in the chip itself. You only want
to force this to be set when using the BDI, not at other times.
This MSR_DE is also of interest and used for software debuggers that
make use of the debug registers. Only if MSR_DE is set then debug
interrupts are generated. If a debug event leads to a debug interrupt
handled by a software debugger or if it leads to a debug halt handled
by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
The "e500 Core Family Reference Manual" chapter "Chapter 8
Debug Support" explains in detail the effect of MSR_DE.
quoted
So what is the verdict on this? I don't buy into Dan argument without some
hard data.
What I tried to mention is that handling the MSR_DE correct is not only
an emulator (JTAG debugger) requirement. Also a software debugger may
depend on a correct handled MSR_DE bit.
Yes, that made sense to me too. How would SW debuggers work if the kernel keeps
turning off MSR_DE first chance it gets?
The kernel selectively enables MSR_DE when it wants to debug. I'm not
sure if anything will be bothered by leaving it on all the time. This
is something we need for virtualization as well, so a hypervisor can
debug the guest.
hmm, I read that as you as in favour of the patch?
I'd want some confirmation that it doesn't break anything, and that
there aren't any other places that need MSR_DE that this doesn't cover,
but in general yes.
Then you need to test drive the patch :)
I was thinking more along the lines of someone who's more familiar with
the relevant parts of the code confirming that it's really OK, not just
testing that it doesn't blow up in my face.
It just occurred to me that you guys have this already in your Linux SDK so it can't be that bad.
Jocke
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-06-01 09:13:29
On Thu, 2012-05-31 at 11:05 +0200, Joakim Tjernlund wrote:
Abatron Support [off-list ref] wrote on 2012/05/30 14:08:26:
quoted
quoted
quoted
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects,
therfore
this RFC.
quoted
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if MSR_DE
is set, you will have problems with software debuggers that
utilize the the debugging registers in the chip itself. You only want
to force this to be set when using the BDI, not at other times.
This MSR_DE is also of interest and used for software debuggers that
make use of the debug registers. Only if MSR_DE is set then debug
interrupts are generated. If a debug event leads to a debug interrupt
handled by a software debugger or if it leads to a debug halt handled
by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
The "e500 Core Family Reference Manual" chapter "Chapter 8
Debug Support" explains in detail the effect of MSR_DE.
So what is the verdict on this? I don't buy into Dan argument without some
hard data.
The kernel normally controls when to set or not set MSR:DE, at least
when using SW breakpoints. Setting it globally should remain some kind
of specific debug option.
In fact on some CPUs, we even leave user set dbcr settings and rely on
DE being off in kernel space to avoid user->kernel attacks via the debug
registers (I think we still do that on 64-bit BookE though it should
eventually change).
Cheers,
Ben.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-06-01 09:15:03
On Wed, 2012-05-30 at 09:26 -0400, Bob Cochran wrote:
I believe that additional patches are required for CodeWarrior to
work
properly (e.g., assembly start up). I think the patches should come
from Freescale. For whatever reason, they include them in their SDK,
but haven't submitted them for inclusion in the mainline.
As a developer on Freescale Power products, I would like to see
Freescale offer up a CodeWarrior patch set, so I don't have to manage
the patches myself when working outside the SDK (i.e., on a more
recent
kernel).
Such patches would have a hard time getting upstream considering that
codewarrior is a commercial product.
Ben.
Benjamin Herrenschmidt [off-list ref] wrote on 2012/06/01 11:12:51:
On Thu, 2012-05-31 at 11:05 +0200, Joakim Tjernlund wrote:
quoted
Abatron Support [off-list ref] wrote on 2012/05/30 14:08:26:
quoted
quoted
quoted
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects,
therfore
this RFC.
quoted
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if MSR_DE
is set, you will have problems with software debuggers that
utilize the the debugging registers in the chip itself. You only want
to force this to be set when using the BDI, not at other times.
This MSR_DE is also of interest and used for software debuggers that
make use of the debug registers. Only if MSR_DE is set then debug
interrupts are generated. If a debug event leads to a debug interrupt
handled by a software debugger or if it leads to a debug halt handled
by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
The "e500 Core Family Reference Manual" chapter "Chapter 8
Debug Support" explains in detail the effect of MSR_DE.
So what is the verdict on this? I don't buy into Dan argument without some
hard data.
The kernel normally controls when to set or not set MSR:DE, at least
when using SW breakpoints. Setting it globally should remain some kind
of specific debug option.
In fact on some CPUs, we even leave user set dbcr settings and rely on
DE being off in kernel space to avoid user->kernel attacks via the debug
registers (I think we still do that on 64-bit BookE though it should
eventually change).
hmm, would it not be better to always clear out/control dbcr settings and always have MSR:DE
on? It would be much easier to control dbcr, even dynamically, than MSR:DE
Jocke
Benjamin Herrenschmidt [off-list ref] wrote on 2012/06/01 11:14:49:
On Wed, 2012-05-30 at 09:26 -0400, Bob Cochran wrote:
quoted
I believe that additional patches are required for CodeWarrior to
work
properly (e.g., assembly start up). I think the patches should come
from Freescale. For whatever reason, they include them in their SDK,
but haven't submitted them for inclusion in the mainline.
As a developer on Freescale Power products, I would like to see
Freescale offer up a CodeWarrior patch set, so I don't have to manage
the patches myself when working outside the SDK (i.e., on a more
recent
kernel).
Such patches would have a hard time getting upstream considering that
codewarrior is a commercial product.
Naa, Abatron BDI is also a commercial product and that is in the kernel. CW
changes pretty much just add the same settings for CONFIG_CW. I think Freescale
should just rename CONFIG_BDI_SWITCH to something generic and just use the same code.
Jocke
From: Scott Wood <hidden> Date: 2012-06-01 16:29:02
On 06/01/2012 04:14 AM, Benjamin Herrenschmidt wrote:
On Wed, 2012-05-30 at 09:26 -0400, Bob Cochran wrote:
quoted
I believe that additional patches are required for CodeWarrior to
work
properly (e.g., assembly start up). I think the patches should come
from Freescale. For whatever reason, they include them in their SDK,
but haven't submitted them for inclusion in the mainline.
As a developer on Freescale Power products, I would like to see
Freescale offer up a CodeWarrior patch set, so I don't have to manage
the patches myself when working outside the SDK (i.e., on a more
recent
kernel).
Such patches would have a hard time getting upstream considering that
codewarrior is a commercial product.
It's not really about CodeWarrior -- it's needed for any external debug
on these chips.
Those chips are commercial products too, BTW. :-)
-Scott
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-06-01 22:30:19
On Fri, 2012-06-01 at 11:28 -0500, Scott Wood wrote:
It's not really about CodeWarrior -- it's needed for any external
debug
on these chips.
Those chips are commercial products too, BTW. :-)
As long as it's not code to specifically interact with the CW software
it's ok.
I don't have a special axe to grind against CW (I use to love it under
ol' MacOS, though the new eclipse based one does seem to suck hard...
but then I never got a "licence" to use it past the demo anyway), it's
just that I don't want to start building SW interfaces to a foreign
tool.
BTW. My point of view is that this whole business about MSR:DE is a HW
design bug. There should be -no- (absolutely 0) interaction between the
SW state and the HW debugger for normal operations unless the user of
the debugger explicitly wants to change some state.
Cheers,
Ben.
From: Scott Wood <hidden> Date: 2012-06-01 22:42:58
On 06/01/2012 05:30 PM, Benjamin Herrenschmidt wrote:
BTW. My point of view is that this whole business about MSR:DE is a HW
design bug. There should be -no- (absolutely 0) interaction between the
SW state and the HW debugger for normal operations unless the user of
the debugger explicitly wants to change some state.
I agree entirely, and e500mc at least has less of this than e500v2 (not
sure if it still needs MSR[DE], but supposedly it doesn't have the
requirement for there to be a valid instruction at the debug vector,
which is lots of fun when booting). But this isn't exactly something
Freescale is going to replace existing chips over.
Getting all the way to zero interaction would require a completely
separate debug facility so software can debug at the same time. I'd be
all for that (and let's throw in a third, for the hypervisor), but I'm
not the one that needs to be convinced.
-Scott
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-06-01 23:25:14
On Fri, 2012-06-01 at 17:42 -0500, Scott Wood wrote:
On 06/01/2012 05:30 PM, Benjamin Herrenschmidt wrote:
quoted
BTW. My point of view is that this whole business about MSR:DE is a HW
design bug. There should be -no- (absolutely 0) interaction between the
SW state and the HW debugger for normal operations unless the user of
the debugger explicitly wants to change some state.
I agree entirely, and e500mc at least has less of this than e500v2 (not
sure if it still needs MSR[DE], but supposedly it doesn't have the
requirement for there to be a valid instruction at the debug vector,
which is lots of fun when booting). But this isn't exactly something
Freescale is going to replace existing chips over.
Getting all the way to zero interaction would require a completely
separate debug facility so software can debug at the same time. I'd be
all for that (and let's throw in a third, for the hypervisor), but I'm
not the one that needs to be convinced.
You can find a good compromise. If you have some kind of SPR letting you
know now many DACs and IACs are available, you could essentially
"reserve" some for HW debug with the probe. Not as good as a fully
separate facility but still better than stepping on each other toes.
Things like DBCR should probably still be separated. There's no excuse
for the MSR:DE bullshit tho :-)
Cheers,
Ben.
On Fri, 2012-06-01 at 17:42 -0500, Scott Wood wrote:
quoted
On 06/01/2012 05:30 PM, Benjamin Herrenschmidt wrote:
quoted
BTW. My point of view is that this whole business about MSR:DE is a HW
design bug. There should be -no- (absolutely 0) interaction between the
SW state and the HW debugger for normal operations unless the user of
the debugger explicitly wants to change some state.
I agree entirely, and e500mc at least has less of this than e500v2 (not
sure if it still needs MSR[DE], but supposedly it doesn't have the
requirement for there to be a valid instruction at the debug vector,
which is lots of fun when booting). But this isn't exactly something
Freescale is going to replace existing chips over.
Getting all the way to zero interaction would require a completely
separate debug facility so software can debug at the same time. I'd be
all for that (and let's throw in a third, for the hypervisor), but I'm
not the one that needs to be convinced.
You can find a good compromise. If you have some kind of SPR letting you
know now many DACs and IACs are available, you could essentially
"reserve" some for HW debug with the probe. Not as good as a fully
separate facility but still better than stepping on each other toes.
Things like DBCR should probably still be separated. There's no excuse
for the MSR:DE bullshit tho :-)
hmm, where does this go w.r.t the patch? Got the feeling that the
best thing is to just turn MSR:DE on and be done with it?
Jocke
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-06-02 21:21:36
On Sat, 2012-06-02 at 20:29 +0200, Joakim Tjernlund wrote:
hmm, where does this go w.r.t the patch? Got the feeling that the
best thing is to just turn MSR:DE on and be done with it?
Not unconditionally, we need to have a close look, that might be ok
specifically for BookE 32-bit, it's certainly not ok for BookE 64-bit at
this point.
For now, I'm ok with a debug CONFIG_* option.
Also do we know if MSR:DE has any performance impact on any CPU ? I know
having DACs enabled has a major impact on some for example.
Ben.
Benjamin Herrenschmidt [off-list ref] wrote on 2012/06/02 23:21:16:
On Sat, 2012-06-02 at 20:29 +0200, Joakim Tjernlund wrote:
quoted
hmm, where does this go w.r.t the patch? Got the feeling that the
best thing is to just turn MSR:DE on and be done with it?
Not unconditionally, we need to have a close look, that might be ok
specifically for BookE 32-bit, it's certainly not ok for BookE 64-bit at
this point.
For now, I'm ok with a debug CONFIG_* option.
OK, I will wrap this with the existing CONFIG_BDI_SWITCH and only for booke
Also do we know if MSR:DE has any performance impact on any CPU ? I know
having DACs enabled has a major impact on some for example.
No idea, this is something for Freescale to dwell on.
Benjamin Herrenschmidt [off-list ref] wrote on 2012/06/02 23:21:16:
On Sat, 2012-06-02 at 20:29 +0200, Joakim Tjernlund wrote:
quoted
hmm, where does this go w.r.t the patch? Got the feeling that the
best thing is to just turn MSR:DE on and be done with it?
Not unconditionally, we need to have a close look, that might be ok
specifically for BookE 32-bit, it's certainly not ok for BookE 64-bit at
this point.
For now, I'm ok with a debug CONFIG_* option.
Also do we know if MSR:DE has any performance impact on any CPU ? I know
having DACs enabled has a major impact on some for example.
I just sent a new patch, named
[PATCH] powerpc: Add MSR_DE to MSR_KERNEL
which will only add MSR_DE for booke under CONFIG_BDI_SWITCH
On Behalf Of Joakim Tjernlund
Sent: Friday, June 01, 2012 6:36 AM
To: Wood Scott-B07421
Cc: linuxppc-dev@ozlabs.org; Dan Malek; Bob Cochran; Support
Subject: Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
=20
Scott Wood [off-list ref] wrote on 2012/06/01 00:16:53:
quoted
On 05/31/2012 05:14 PM, Joakim Tjernlund wrote:
quoted
Scott Wood [off-list ref] wrote on 2012/05/31 23:43:34:
quoted
On 05/31/2012 04:38 PM, Joakim Tjernlund wrote:
quoted
Scott Wood [off-list ref] wrote on 2012/05/31 19:47:53:
quoted
On 05/31/2012 04:56 AM, Joakim Tjernlund wrote:
quoted
Abatron Support [off-list ref] wrote on 2012/05/31 11:30:57=
:
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
Abatron Support [off-list ref] wrote on 2012/05/30 14:08:=
26:
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side
effects,
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
therfore
this RFC.
quoted
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if
MSR_DE
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
is set, you will have problems with software debuggers that
utilize the the debugging registers in the chip itself. You
only want
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
to force this to be set when using the BDI, not at other time=
s.
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
This MSR_DE is also of interest and used for software debugger=
s
that
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
make use of the debug registers. Only if MSR_DE is set then
debug
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
interrupts are generated. If a debug event leads to a debug
interrupt
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
handled by a software debugger or if it leads to a debug halt
handled
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
The "e500 Core Family Reference Manual" chapter "Chapter 8
Debug Support" explains in detail the effect of MSR_DE.
quoted
So what is the verdict on this? I don't buy into Dan argument
without some
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
hard data.
What I tried to mention is that handling the MSR_DE correct is n=
ot
only
quoted
quoted
quoted
quoted
quoted
quoted
quoted
an emulator (JTAG debugger) requirement. Also a software debugge=
r
may
quoted
quoted
quoted
quoted
quoted
quoted
quoted
depend on a correct handled MSR_DE bit.
Yes, that made sense to me too. How would SW debuggers work if th=
e
kernel keeps
quoted
quoted
quoted
quoted
quoted
quoted
turning off MSR_DE first chance it gets?
The kernel selectively enables MSR_DE when it wants to debug. I'm
not
quoted
quoted
quoted
quoted
quoted
sure if anything will be bothered by leaving it on all the time.
This
quoted
quoted
quoted
quoted
quoted
is something we need for virtualization as well, so a hypervisor c=
an
quoted
quoted
quoted
quoted
quoted
debug the guest.
hmm, I read that as you as in favour of the patch?
I'd want some confirmation that it doesn't break anything, and that
there aren't any other places that need MSR_DE that this doesn't cov=
er,
quoted
quoted
quoted
but in general yes.
Then you need to test drive the patch :)
I was thinking more along the lines of someone who's more familiar with
the relevant parts of the code confirming that it's really OK, not just
testing that it doesn't blow up in my face.
=20
It just occurred to me that you guys have this already in your Linux SDK =
so
it can't be that bad.
No. MSR_DE is ONLY added when using CW debug in SDK.
Roy
Zang Roy-R61911 [off-list ref] wrote on 2012/07/20 10:27:52:
quoted
-----Original Message-----
From: linuxppc-dev-bounces+tie-fei.zang=freescale.com@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+tie-fei.zang=freescale.com@lists.ozlabs.org]
On Behalf Of Joakim Tjernlund
Sent: Friday, June 01, 2012 6:36 AM
To: Wood Scott-B07421
Cc: linuxppc-dev@ozlabs.org; Dan Malek; Bob Cochran; Support
Subject: Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
Scott Wood [off-list ref] wrote on 2012/06/01 00:16:53:
quoted
On 05/31/2012 05:14 PM, Joakim Tjernlund wrote:
quoted
Scott Wood [off-list ref] wrote on 2012/05/31 23:43:34:
quoted
On 05/31/2012 04:38 PM, Joakim Tjernlund wrote:
quoted
Scott Wood [off-list ref] wrote on 2012/05/31 19:47:53:
quoted
On 05/31/2012 04:56 AM, Joakim Tjernlund wrote:
quoted
Abatron Support [off-list ref] wrote on 2012/05/31 11:30:57:
quoted
quoted
Abatron Support [off-list ref] wrote on 2012/05/30 14:08:26:
quoted
quoted
quoted
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side
effects,
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
therfore
this RFC.
quoted
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if
MSR_DE
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
is set, you will have problems with software debuggers that
utilize the the debugging registers in the chip itself. You
only want
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
to force this to be set when using the BDI, not at other times.
This MSR_DE is also of interest and used for software debuggers
that
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
make use of the debug registers. Only if MSR_DE is set then
debug
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
interrupts are generated. If a debug event leads to a debug
interrupt
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
handled by a software debugger or if it leads to a debug halt
handled
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
The "e500 Core Family Reference Manual" chapter "Chapter 8
Debug Support" explains in detail the effect of MSR_DE.
quoted
So what is the verdict on this? I don't buy into Dan argument
without some
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
hard data.
What I tried to mention is that handling the MSR_DE correct is not
only
quoted
quoted
quoted
quoted
quoted
quoted
quoted
an emulator (JTAG debugger) requirement. Also a software debugger
may
quoted
quoted
quoted
quoted
quoted
quoted
quoted
depend on a correct handled MSR_DE bit.
Yes, that made sense to me too. How would SW debuggers work if the
kernel keeps
quoted
quoted
quoted
quoted
quoted
quoted
turning off MSR_DE first chance it gets?
The kernel selectively enables MSR_DE when it wants to debug. I'm
not
quoted
quoted
quoted
quoted
quoted
sure if anything will be bothered by leaving it on all the time.
This
quoted
quoted
quoted
quoted
quoted
is something we need for virtualization as well, so a hypervisor can
debug the guest.
hmm, I read that as you as in favour of the patch?
I'd want some confirmation that it doesn't break anything, and that
there aren't any other places that need MSR_DE that this doesn't cover,
but in general yes.
Then you need to test drive the patch :)
I was thinking more along the lines of someone who's more familiar with
the relevant parts of the code confirming that it's really OK, not just
testing that it doesn't blow up in my face.
It just occurred to me that you guys have this already in your Linux SDK so
it can't be that bad.
No. MSR_DE is ONLY added when using CW debug in SDK.
Roy
Yes, and I later found that user space debugging is busted if you turn on MSR_DE in
kernel.
Jocke
From: Scott Wood <hidden> Date: 2013-06-25 00:51:08
On Fri, Jul 20, 2012 at 10:37:17AM +0200, Joakim Tjernlund wrote:
Zang Roy-R61911 [off-list ref] wrote on 2012/07/20 10:27:52:
quoted
quoted
-----Original Message-----
From: linuxppc-dev-bounces+tie-fei.zang=freescale.com@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+tie-fei.zang=freescale.com@lists.ozlabs.org]
On Behalf Of Joakim Tjernlund
Sent: Friday, June 01, 2012 6:36 AM
To: Wood Scott-B07421
Cc: linuxppc-dev@ozlabs.org; Dan Malek; Bob Cochran; Support
Subject: Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
It just occurred to me that you guys have this already in your Linux SDK so
it can't be that bad.
No. MSR_DE is ONLY added when using CW debug in SDK.
Roy
Yes, and I later found that user space debugging is busted if you turn on MSR_DE in
kernel.
So, how should we handle the CONFIG_BDI_SWITCH patch? It seems like it
should at least have a warning in the kconfig help text that it breaks
userspace debugging (to the point of causing a kernel oops if it's
tried). Or maybe it can deselect CONFIG_PPC_ADV_DEBUG_REGS?
It'd also be nice to keep things like this, that are a consequence of how
external debug works on e500, separate from the Abatron-specific stuff.
-Scott
On Behalf Of Joakim Tjernlund
Sent: Friday, June 01, 2012 6:36 AM
To: Wood Scott-B07421
Cc: linuxppc-dev@ozlabs.org; Dan Malek; Bob Cochran; Support
Subject: Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
It just occurred to me that you guys have this already in your
Linux SDK so
quoted
quoted
quoted
it can't be that bad.
No. MSR_DE is ONLY added when using CW debug in SDK.
Roy
Yes, and I later found that user space debugging is busted if you turn
on MSR_DE in
quoted
kernel.
So, how should we handle the CONFIG_BDI_SWITCH patch? It seems like it
should at least have a warning in the kconfig help text that it breaks
userspace debugging (to the point of causing a kernel oops if it's
tried). Or maybe it can deselect CONFIG_PPC_ADV_DEBUG_REGS?
It'd also be nice to keep things like this, that are a consequence of
how
external debug works on e500, separate from the Abatron-specific stuff.
I was hoping the kernel would grow per context handling of MSR_DE. Then
one could have
MSR_DE on in MSR_KERNEL but off in user space(unless gdb request it on a
per process basis).
Jocke
On Behalf Of Joakim Tjernlund
Sent: Friday, June 01, 2012 6:36 AM
To: Wood Scott-B07421
Cc: linuxppc-dev@ozlabs.org; Dan Malek; Bob Cochran; Support
Subject: Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
It just occurred to me that you guys have this already in your
Linux SDK so
quoted
quoted
quoted
quoted
it can't be that bad.
No. MSR_DE is ONLY added when using CW debug in SDK.
Roy
Yes, and I later found that user space debugging is busted if you =20
turn
on MSR_DE in
quoted
quoted
kernel.
So, how should we handle the CONFIG_BDI_SWITCH patch? It seems =20
like it
quoted
should at least have a warning in the kconfig help text that it =20
breaks
quoted
userspace debugging (to the point of causing a kernel oops if it's
tried). Or maybe it can deselect CONFIG_PPC_ADV_DEBUG_REGS?
It'd also be nice to keep things like this, that are a consequence =20
of
how
quoted
external debug works on e500, separate from the Abatron-specific =20
stuff.
quoted
=20
I was hoping the kernel would grow per context handling of MSR_DE. =20
Then
one could have
MSR_DE on in MSR_KERNEL but off in user space(unless gdb request it =20
on a
per process basis).
What if the external debugger wants debugging to work when in userspace =20
as well? Plus, you wouldn't be able to debug from the very beginning =20
of an exception handler if the exception came from userspace.
-Scott=