Question about DBCR0 initialization for 440

Question about DBCR0 initialization for 440

[John Linn]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

The kernel does not initialize the PPC440 DBCR0 register. This prevents
(among other things) the use of software breakpoints with GDB.  I
realize that boot loaders probably do initialize this but we run a lot
without a boot loader and so do our customers.

 

The file, head_fsl_booke.S, does initialize the register for the
freescale specific code (as shown at the end of the message).

 

We are needing this also for Xilinx.  What's the best method to
incorporate this, is it possible to add to head_44x.S?

 

Thanks,

John

 

#if !defined(CONFIG_BDI_SWITCH)

            /*

             * The Abatron BDI JTAG debugger does not tolerate others

             * mucking with the debug registers.

             */

            lis     r2,DBCR0_IDM@h

            mtspr   SPRN_DBCR0,r2

            isync

            /* clear any residual debug events */

            li      r2,-1

            mtspr   SPRN_DBSR,r2

#endif

 



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.


[-- Attachment #2: Type: text/html, Size: 5751 bytes --]

RE: Question about DBCR0 initialization for 440

[Tirumala Reddy Marri]

[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]

Some debuggers like BDI(Abatron) they setup the debug registers. If you
have different debugger which doesn't support configuring debug
registers I suggest you to program then in the head_44x.S file.

 

From: linuxppc-dev-bounces+tmarri=amcc.com@ozlabs.org
[mailto:linuxppc-dev-bounces+tmarri=amcc.com@ozlabs.org] On Behalf Of
John Linn
Sent: Tuesday, April 14, 2009 1:33 PM
To: jwboyer@linux.vnet.ibm.com; grant.likely@secretlab.ca;
linuxppc-dev@ozlabs.org
Subject: Question about DBCR0 initialization for 440

 

The kernel does not initialize the PPC440 DBCR0 register. This prevents
(among other things) the use of software breakpoints with GDB.  I
realize that boot loaders probably do initialize this but we run a lot
without a boot loader and so do our customers.

 

The file, head_fsl_booke.S, does initialize the register for the
freescale specific code (as shown at the end of the message).

 

We are needing this also for Xilinx.  What's the best method to
incorporate this, is it possible to add to head_44x.S?

 

Thanks,

John

 

#if !defined(CONFIG_BDI_SWITCH)

            /*

             * The Abatron BDI JTAG debugger does not tolerate others

             * mucking with the debug registers.

             */

            lis     r2,DBCR0_IDM@h

            mtspr   SPRN_DBCR0,r2

            isync

            /* clear any residual debug events */

            li      r2,-1

            mtspr   SPRN_DBSR,r2

#endif

 


This email and any attachments are intended for the sole use of the
named recipient(s) and contain(s) confidential information that may be
proprietary, privileged or copyrighted under applicable law. If you are
not the intended recipient, do not read, copy, or forward this email
message or any attachments. Delete this email message and any
attachments immediately. 


[-- Attachment #2: Type: text/html, Size: 9736 bytes --]

RE: Question about DBCR0 initialization for 440

[John Linn]

[-- Attachment #1: Type: text/plain, Size: 2746 bytes --]

Josh, any thoughts on putting this into head_44x.S?

 

Thanks,

John

 

________________________________

From: linuxppc-dev-bounces+john.linn=xilinx.com@ozlabs.org
[mailto:linuxppc-dev-bounces+john.linn=xilinx.com@ozlabs.org] On Behalf
Of Tirumala Reddy Marri
Sent: Wednesday, April 15, 2009 10:24 AM
To: John Linn; jwboyer@linux.vnet.ibm.com; grant.likely@secretlab.ca;
linuxppc-dev@ozlabs.org
Subject: RE: Question about DBCR0 initialization for 440

 

Some debuggers like BDI(Abatron) they setup the debug registers. If you
have different debugger which doesn't support configuring debug
registers I suggest you to program then in the head_44x.S file.

 

From: linuxppc-dev-bounces+tmarri=amcc.com@ozlabs.org
[mailto:linuxppc-dev-bounces+tmarri=amcc.com@ozlabs.org] On Behalf Of
John Linn
Sent: Tuesday, April 14, 2009 1:33 PM
To: jwboyer@linux.vnet.ibm.com; grant.likely@secretlab.ca;
linuxppc-dev@ozlabs.org
Subject: Question about DBCR0 initialization for 440

 

The kernel does not initialize the PPC440 DBCR0 register. This prevents
(among other things) the use of software breakpoints with GDB.  I
realize that boot loaders probably do initialize this but we run a lot
without a boot loader and so do our customers.

 

The file, head_fsl_booke.S, does initialize the register for the
freescale specific code (as shown at the end of the message).

 

We are needing this also for Xilinx.  What's the best method to
incorporate this, is it possible to add to head_44x.S?

 

Thanks,

John

 

#if !defined(CONFIG_BDI_SWITCH)

            /*

             * The Abatron BDI JTAG debugger does not tolerate others

             * mucking with the debug registers.

             */

            lis     r2,DBCR0_IDM@h

            mtspr   SPRN_DBCR0,r2

            isync

            /* clear any residual debug events */

            li      r2,-1

            mtspr   SPRN_DBSR,r2

#endif

 


This email and any attachments are intended for the sole use of the
named recipient(s) and contain(s) confidential information that may be
proprietary, privileged or copyrighted under applicable law. If you are
not the intended recipient, do not read, copy, or forward this email
message or any attachments. Delete this email message and any
attachments immediately. 



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.


[-- Attachment #2: Type: text/html, Size: 13645 bytes --]

Re: Question about DBCR0 initialization for 440

[Josh Boyer]

On Fri, Apr 17, 2009 at 11:46 AM, John Linn <John.Linn@xilinx.com> wrote:
> Josh, any thoughts on putting this into head_44x.S?

The code in the fsl file looks like the right solution.  I do have an
odd question though, in that it's hard for the
kernel to really know if something like a BDI is running.  Namely,
that config option doesn't cover RiscWatch in an obvious manner.

I also wonder if it's possible to have a host system be setting those
registers in a guest KVM system so the guest could be debugged with
gdb...  Hollis, any idea on that?

josh

Re: Question about DBCR0 initialization for 440

[Hollis Blanchard]

On Friday 17 April 2009 12:22:37 Josh Boyer wrote:
> On Fri, Apr 17, 2009 at 11:46 AM, John Linn <John.Linn@xilinx.com> wrote:
> > Josh, any thoughts on putting this into head_44x.S?
> 
> The code in the fsl file looks like the right solution.  I do have an
> odd question though, in that it's hard for the
> kernel to really know if something like a BDI is running.  Namely,
> that config option doesn't cover RiscWatch in an obvious manner.

Yeah, setting DBCR0 would interfere with all JTAG probes. The ifdef meands you 
can't support both a JTAG debugger and hardware breakpoints in the same 
binary? Now that's an annoying restriction.

> I also wonder if it's possible to have a host system be setting those
> registers in a guest KVM system so the guest could be debugged with
> gdb...  Hollis, any idea on that?

You mean is KVM currently doing that, and would this patch conflict with that 
behavior?

Right now KVM (on 440) context switches the necessary DB* registers for out-
of-band debugging. That is, qemu sends a "set breakpoint in guest" ioctl to 
KVM, and then when switching from host to guest mode, KVM will save the old 
DB* values, put in some new ones, and swap them back again when re-entering 
the host. So I *think* the answer to your question is "yes, KVM messes with 
these registers to enable software breakpoints when debugging a guest with 
gdb." That code path isn't heavily tested, but the values put into DB* by 
other host code shouldn't matter.

However, KVM doesn't support in-band breakpoints, i.e. it doesn't emulate the 
setting of those registers from within the guest. It's basically a no-op. So 
whether the kernel sets them or not, in-band debugging won't work with the 
current KVM code.

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: Question about DBCR0 initialization for 440

[Grant Likely]

Hey John

We just discussed this on IRC.  Go ahead and generate a patch to
unconditionally turn on DBCR0[IDM] in head_44x.S.  Don't even bother
wrapping it in an #ifdef CONFIG_somthing block.  It should be safe,
but we'll throw it into -next and see if anyone complains.  If it does
cause problems, then it can be reworked to something a wee bit more
conservative.

g.

On Fri, Apr 17, 2009 at 11:22 AM, Josh Boyer <jwboyer@linux.vnet.ibm.com> w=
rote:
> On Fri, Apr 17, 2009 at 11:46 AM, John Linn <John.Linn@xilinx.com> wrote:
>> Josh, any thoughts on putting this into head_44x.S?
>
> The code in the fsl file looks like the right solution. =A0I do have an
> odd question though, in that it's hard for the
> kernel to really know if something like a BDI is running. =A0Namely,
> that config option doesn't cover RiscWatch in an obvious manner.
>
> I also wonder if it's possible to have a host system be setting those
> registers in a guest KVM system so the guest could be debugged with
> gdb... =A0Hollis, any idea on that?
>
> josh
>



--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

RE: Question about DBCR0 initialization for 440

[John Linn]

Thanks everyone, will do.

> -----Original Message-----
> From: Grant Likely [mailto:grant.likely@secretlab.ca]
> Sent: Friday, April 17, 2009 12:58 PM
> To: Josh Boyer
> Cc: John Linn; Tirumala Reddy Marri; linuxppc-dev@ozlabs.org; hollisb@us.=
ibm.com
> Subject: Re: Question about DBCR0 initialization for 440
> =

> Hey John
> =

> We just discussed this on IRC.  Go ahead and generate a patch to
> unconditionally turn on DBCR0[IDM] in head_44x.S.  Don't even bother
> wrapping it in an #ifdef CONFIG_somthing block.  It should be safe,
> but we'll throw it into -next and see if anyone complains.  If it does
> cause problems, then it can be reworked to something a wee bit more
> conservative.
> =

> g.
> =

> On Fri, Apr 17, 2009 at 11:22 AM, Josh Boyer <jwboyer@linux.vnet.ibm.com>=
 wrote:
> > On Fri, Apr 17, 2009 at 11:46 AM, John Linn <John.Linn@xilinx.com> wrot=
e:
> >> Josh, any thoughts on putting this into head_44x.S?
> >
> > The code in the fsl file looks like the right solution. =A0I do have an=

> > odd question though, in that it's hard for the
> > kernel to really know if something like a BDI is running. =A0Namely,
> > that config option doesn't cover RiscWatch in an obvious manner.
> >
> > I also wonder if it's possible to have a host system be setting those
> > registers in a guest KVM system so the guest could be debugged with
> > gdb... =A0Hollis, any idea on that?
> >
> > josh
> >
> =

> =

> =

> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.


This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

Re: Question about DBCR0 initialization for 440

[Benjamin Herrenschmidt]

On Fri, 2009-04-17 at 13:07 -0500, Hollis Blanchard wrote:
> On Friday 17 April 2009 12:22:37 Josh Boyer wrote:
> > On Fri, Apr 17, 2009 at 11:46 AM, John Linn <John.Linn@xilinx.com> wrote:
> > > Josh, any thoughts on putting this into head_44x.S?
> > 
> > The code in the fsl file looks like the right solution.  I do have an
> > odd question though, in that it's hard for the
> > kernel to really know if something like a BDI is running.  Namely,
> > that config option doesn't cover RiscWatch in an obvious manner.
> 
> Yeah, setting DBCR0 would interfere with all JTAG probes. The ifdef meands you 
> can't support both a JTAG debugger and hardware breakpoints in the same 
> binary? Now that's an annoying restriction.

Might be worth checking if external debug is enabled, and override it
only if it's not.


Ben.

Re: Question about DBCR0 initialization for 440

[Grant Likely]

On Fri, Apr 17, 2009 at 1:04 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2009-04-17 at 13:07 -0500, Hollis Blanchard wrote:
>> On Friday 17 April 2009 12:22:37 Josh Boyer wrote:
>> > On Fri, Apr 17, 2009 at 11:46 AM, John Linn <John.Linn@xilinx.com> wro=
te:
>> > > Josh, any thoughts on putting this into head_44x.S?
>> >
>> > The code in the fsl file looks like the right solution. =A0I do have a=
n
>> > odd question though, in that it's hard for the
>> > kernel to really know if something like a BDI is running. =A0Namely,
>> > that config option doesn't cover RiscWatch in an obvious manner.
>>
>> Yeah, setting DBCR0 would interfere with all JTAG probes. The ifdef mean=
ds you
>> can't support both a JTAG debugger and hardware breakpoints in the same
>> binary? Now that's an annoying restriction.
>
> Might be worth checking if external debug is enabled, and override it
> only if it's not.

ppc440x5_um.pdf says that both can be enabled.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

RE: Question about DBCR0 initialization for 440

[John Linn]

> -----Original Message-----
> From: Grant Likely [mailto:grant.likely@secretlab.ca] =

> Sent: Friday, April 17, 2009 1:10 PM
> To: Benjamin Herrenschmidt
> Cc: Hollis Blanchard; linuxppc-dev@ozlabs.org; John Linn; =

> Tirumala Reddy Marri
> Subject: Re: Question about DBCR0 initialization for 440
> =

> On Fri, Apr 17, 2009 at 1:04 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Fri, 2009-04-17 at 13:07 -0500, Hollis Blanchard wrote:
> >> On Friday 17 April 2009 12:22:37 Josh Boyer wrote:
> >> > On Fri, Apr 17, 2009 at 11:46 AM, John Linn =

> <John.Linn@xilinx.com> wrote:
> >> > > Josh, any thoughts on putting this into head_44x.S?
> >> >
> >> > The code in the fsl file looks like the right solution. =A0
I do have an
> >> > odd question though, in that it's hard for the
> >> > kernel to really know if something like a BDI is =

> running. =A0Namely,
> >> > that config option doesn't cover RiscWatch in an obvious manner.
> >>
> >> Yeah, setting DBCR0 would interfere with all JTAG probes. =

> The ifdef meands you
> >> can't support both a JTAG debugger and hardware =

> breakpoints in the same
> >> binary? Now that's an annoying restriction.
> >
> > Might be worth checking if external debug is enabled, and =

> override it
> > only if it's not.
> =

> ppc440x5_um.pdf says that both can be enabled.
> =


The code that I started the thread with, from the fsl file, has conditional=
 for the BDI around it.

We think that we still need that conditional as the code is not Oring in th=
e enable such that it would
disable external debug mode for the BDI. But we need it this way for our Xi=
linx pod.

#if !defined(CONFIG_BDI_SWITCH)
            /*
             * The Abatron BDI JTAG debugger does not tolerate others
             * mucking with the debug registers.
             */
            lis     r2,DBCR0_IDM@h
            mtspr   SPRN_DBCR0,r2
            isync
            /* clear any residual debug events */
            li      r2,-1
            mtspr   SPRN_DBSR,r2
#endif =





> g.
> =

> -- =

> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> =

> =


This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

Re: Question about DBCR0 initialization for 440

[Josh Boyer]

On Fri, Apr 17, 2009 at 02:30:45PM -0600, John Linn wrote:
>> > Might be worth checking if external debug is enabled, and 
>> override it
>> > only if it's not.
>> 
>> ppc440x5_um.pdf says that both can be enabled.
>> 
>
>The code that I started the thread with, from the fsl file, has conditional for the BDI around it.
>
>We think that we still need that conditional as the code is not Oring in the enable such that it would
>disable external debug mode for the BDI. But we need it this way for our Xilinx pod.

EDM is a read-only bit according to the docs I have.  You can't set it (or
clear it) at all.  It's only set by external hardware.

josh

RE: Question about DBCR0 initialization for 440

[John Linn]

 =


> -----Original Message-----
> From: Josh Boyer [mailto:jwboyer@linux.vnet.ibm.com] =

> Sent: Friday, April 17, 2009 2:36 PM
> To: John Linn
> Cc: grant.likely@secretlab.ca; Benjamin Herrenschmidt; =

> linuxppc-dev@ozlabs.org; Hollis Blanchard; Tirumala Reddy Marri
> Subject: Re: Question about DBCR0 initialization for 440
> =

> On Fri, Apr 17, 2009 at 02:30:45PM -0600, John Linn wrote:
> >> > Might be worth checking if external debug is enabled, and =

> >> override it
> >> > only if it's not.
> >> =

> >> ppc440x5_um.pdf says that both can be enabled.
> >> =

> >
> >The code that I started the thread with, from the fsl file, =

> has conditional for the BDI around it.
> >
> >We think that we still need that conditional as the code is =

> not Oring in the enable such that it would
> >disable external debug mode for the BDI. But we need it this =

> way for our Xilinx pod.
> =

> EDM is a read-only bit according to the docs I have.  You =

> can't set it (or
> clear it) at all.  It's only set by external hardware.

That's strange, my 440x4_um.pdf does not say it's read-only unless it's
in some obscure place.

> =

> josh
> =

> =


This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

Re: Question about DBCR0 initialization for 440

[Hollis Blanchard]

On Friday 17 April 2009 15:30:45 John Linn wrote:
> We think that we still need that conditional as the code is not Oring in the 
enable such that it would
> disable external debug mode for the BDI. But we need it this way for our 
Xilinx pod.
> 
> #if !defined(CONFIG_BDI_SWITCH)
>             /*
>              * The Abatron BDI JTAG debugger does not tolerate others
>              * mucking with the debug registers.
>              */
>             lis     r2,DBCR0_IDM@h
>             mtspr   SPRN_DBCR0,r2
>             isync
>             /* clear any residual debug events */
>             li      r2,-1
>             mtspr   SPRN_DBSR,r2
> #endif

So change the code to OR in your bits. What's the problem?

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: Question about DBCR0 initialization for 440

[Josh Boyer]

On Fri, Apr 17, 2009 at 02:41:26PM -0600, John Linn wrote:
> 
>
>> -----Original Message-----
>> From: Josh Boyer [mailto:jwboyer@linux.vnet.ibm.com] 
>> Sent: Friday, April 17, 2009 2:36 PM
>> To: John Linn
>> Cc: grant.likely@secretlab.ca; Benjamin Herrenschmidt; 
>> linuxppc-dev@ozlabs.org; Hollis Blanchard; Tirumala Reddy Marri
>> Subject: Re: Question about DBCR0 initialization for 440
>> 
>> On Fri, Apr 17, 2009 at 02:30:45PM -0600, John Linn wrote:
>> >> > Might be worth checking if external debug is enabled, and 
>> >> override it
>> >> > only if it's not.
>> >> 
>> >> ppc440x5_um.pdf says that both can be enabled.
>> >> 
>> >
>> >The code that I started the thread with, from the fsl file, 
>> has conditional for the BDI around it.
>> >
>> >We think that we still need that conditional as the code is 
>> not Oring in the enable such that it would
>> >disable external debug mode for the BDI. But we need it this 
>> way for our Xilinx pod.
>> 
>> EDM is a read-only bit according to the docs I have.  You 
>> can't set it (or
>> clear it) at all.  It's only set by external hardware.
>
>That's strange, my 440x4_um.pdf does not say it's read-only unless it's
>in some obscure place.

Gah.  I think that was my mistake.  I don't see that in x4 or x5 manuals, but
it came up on IRC.

josh

RE: Question about DBCR0 initialization for 440

[John Linn]

> -----Original Message-----
> From: Hollis Blanchard [mailto:hollisb@us.ibm.com] =

> Sent: Friday, April 17, 2009 2:50 PM
> To: John Linn
> Cc: grant.likely@secretlab.ca; Benjamin Herrenschmidt; =

> linuxppc-dev@ozlabs.org; Tirumala Reddy Marri
> Subject: Re: Question about DBCR0 initialization for 440
> =

> On Friday 17 April 2009 15:30:45 John Linn wrote:
> > We think that we still need that conditional as the code is =

> not Oring in the =

> enable such that it would
> > disable external debug mode for the BDI. But we need it =

> this way for our =

> Xilinx pod.
> > =

> > #if !defined(CONFIG_BDI_SWITCH)
> >             /*
> >              * The Abatron BDI JTAG debugger does not =

> tolerate others
> >              * mucking with the debug registers.
> >              */
> >             lis     r2,DBCR0_IDM@h
> >             mtspr   SPRN_DBCR0,r2
> >             isync
> >             /* clear any residual debug events */
> >             li      r2,-1
> >             mtspr   SPRN_DBSR,r2
> > #endif
> =

> So change the code to OR in your bits. What's the problem?

The Xilinx pod uses external mode and we don't want it set when running
Linux on the board. It is targeted more to stand alone (non-OS)
applications with different debug requirements.

> =

> -- =

> Hollis Blanchard
> IBM Linux Technology Center
> =

> =


This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.