| Message ID | 6213bc560905190608j73f4191fxbd94158a2b1740c0@mail.gmail.com (mailing list archive) |
|---|---|
| State | Rejected, archived |
| Delegated to: | Josh Boyer |
| Headers | show |
On Tue, May 19, 2009 at 06:38:53PM +0530, srikanth krishnakar wrote: > Hi, > > kernel- 2.6.29 > Debug technique: KGDB > > The PowerPC kernel does not initialize the PPC440 DBCR0 register. This > prevents the use of software breakpoints in case of internal debug > mode. Looking into head_fsl_booke.S for initialization of DBCR0 is > used by boot-loaders. > It seems head_44x.S lacks this step of DBCR0 register initialization. > So fixing this with initializing the DBCR0 register as shown below : > > Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not having > bootloader > > The kernel does not initialize the PPC440 DBCR0 register. > This prevents (among other things) the use of software > breakpoints with GDB. The boot loaders probably do initialize > this but few targets run without a boot loader Um.. how does this prevent the use of software breakpoints with gdb? The trap instructions still work with IDM==0.
Hi David, I am not sure how the IDM behaves on few of PPC440 targets which don't have boot loaders. I have a reference for your question: http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html Without this fix (given patch) I am facing problems with GDB, and further target hangs while running gdbserver ! Thanks, Srikanth On Wed, May 20, 2009 at 5:23 AM, David Gibson <david@gibson.dropbear.id.au> wrote: > On Tue, May 19, 2009 at 06:38:53PM +0530, srikanth krishnakar wrote: >> Hi, >> >> kernel- 2.6.29 >> Debug technique: KGDB >> >> The PowerPC kernel does not initialize the PPC440 DBCR0 register. This >> prevents the use of software breakpoints in case of internal debug >> mode. Looking into head_fsl_booke.S for initialization of DBCR0 is >> used by boot-loaders. >> It seems head_44x.S lacks this step of DBCR0 register initialization. >> So fixing this with initializing the DBCR0 register as shown below : >> >> Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not having >> bootloader >> >> The kernel does not initialize the PPC440 DBCR0 register. >> This prevents (among other things) the use of software >> breakpoints with GDB. The boot loaders probably do initialize >> this but few targets run without a boot loader > > Um.. how does this prevent the use of software breakpoints with gdb? > The trap instructions still work with IDM==0. > > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson >
On Wed, May 20, 2009 at 11:20:46AM +0530, srikanth krishnakar wrote: > Hi David, > > I am not sure how the IDM behaves on few of PPC440 targets which don't > have boot loaders. I have a reference for your question: > > http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html > > Without this fix (given patch) I am facing problems with GDB, and > further target hangs while running gdbserver ! That doesn't answer my question. It's not enough to say "this fixes a problem" you need to explain *how* it fixes the problem. And I don't see why IDM would have any effect on *software* breakpoints. > On Wed, May 20, 2009 at 5:23 AM, David Gibson > <david@gibson.dropbear.id.au> wrote: > > On Tue, May 19, 2009 at 06:38:53PM +0530, srikanth krishnakar wrote: > >> Hi, > >> > >> kernel- 2.6.29 > >> Debug technique: KGDB > >> > >> The PowerPC kernel does not initialize the PPC440 DBCR0 register. This > >> prevents the use of software breakpoints in case of internal debug > >> mode. Looking into head_fsl_booke.S for initialization of DBCR0 is > >> used by boot-loaders. > >> It seems head_44x.S lacks this step of DBCR0 register initialization. > >> So fixing this with initializing the DBCR0 register as shown below : > >> > >> Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not having > >> bootloader > >> > >> The kernel does not initialize the PPC440 DBCR0 register. > >> This prevents (among other things) the use of software > >> breakpoints with GDB. The boot loaders probably do initialize > >> this but few targets run without a boot loader > > > > Um.. how does this prevent the use of software breakpoints with gdb? > > The trap instructions still work with IDM==0.
Hi David, Just to correct the statements : How the DBCR0 is initialized on targets that don't use boot loaders ? -Srikant On Wed, May 20, 2009 at 11:30 AM, David Gibson <david@gibson.dropbear.id.au> wrote: > On Wed, May 20, 2009 at 11:20:46AM +0530, srikanth krishnakar wrote: >> Hi David, >> >> I am not sure how the IDM behaves on few of PPC440 targets which don't >> have boot loaders. I have a reference for your question: >> >> http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html >> >> Without this fix (given patch) I am facing problems with GDB, and >> further target hangs while running gdbserver ! > > That doesn't answer my question. It's not enough to say "this fixes a > problem" you need to explain *how* it fixes the problem. > > And I don't see why IDM would have any effect on *software* > breakpoints. > >> On Wed, May 20, 2009 at 5:23 AM, David Gibson >> <david@gibson.dropbear.id.au> wrote: >> > On Tue, May 19, 2009 at 06:38:53PM +0530, srikanth krishnakar wrote: >> >> Hi, >> >> >> >> kernel- 2.6.29 >> >> Debug technique: KGDB >> >> >> >> The PowerPC kernel does not initialize the PPC440 DBCR0 register. This >> >> prevents the use of software breakpoints in case of internal debug >> >> mode. Looking into head_fsl_booke.S for initialization of DBCR0 is >> >> used by boot-loaders. >> >> It seems head_44x.S lacks this step of DBCR0 register initialization. >> >> So fixing this with initializing the DBCR0 register as shown below : >> >> >> >> Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not having >> >> bootloader >> >> >> >> The kernel does not initialize the PPC440 DBCR0 register. >> >> This prevents (among other things) the use of software >> >> breakpoints with GDB. The boot loaders probably do initialize >> >> this but few targets run without a boot loader >> > >> > Um.. how does this prevent the use of software breakpoints with gdb? >> > The trap instructions still work with IDM==0. > > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson >
Hello Grant, Is there any conclusion of the below discussion: http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html Xilinx target (virtex5) hangs (while running GDBServer & KGDB) without the DBCR0 initialization. Can you please comment on this ? Thanks, -Srikanth On Wed, May 20, 2009 at 11:20 AM, srikanth krishnakar <skrishnakar@gmail.com> wrote: > Hi David, > > I am not sure how the IDM behaves on few of PPC440 targets which don't > have boot loaders. I have a reference for your question: > > http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html > > Without this fix (given patch) I am facing problems with GDB, and > further target hangs while running gdbserver ! > > Thanks, > Srikanth > > On Wed, May 20, 2009 at 5:23 AM, David Gibson > <david@gibson.dropbear.id.au> wrote: >> On Tue, May 19, 2009 at 06:38:53PM +0530, srikanth krishnakar wrote: >>> Hi, >>> >>> kernel- 2.6.29 >>> Debug technique: KGDB >>> >>> The PowerPC kernel does not initialize the PPC440 DBCR0 register. This >>> prevents the use of software breakpoints in case of internal debug >>> mode. Looking into head_fsl_booke.S for initialization of DBCR0 is >>> used by boot-loaders. >>> It seems head_44x.S lacks this step of DBCR0 register initialization. >>> So fixing this with initializing the DBCR0 register as shown below : >>> >>> Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not having >>> bootloader >>> >>> The kernel does not initialize the PPC440 DBCR0 register. >>> This prevents (among other things) the use of software >>> breakpoints with GDB. The boot loaders probably do initialize >>> this but few targets run without a boot loader >> >> Um.. how does this prevent the use of software breakpoints with gdb? >> The trap instructions still work with IDM==0. >> >> -- >> David Gibson | I'll have my music baroque, and my code >> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ >> | _way_ _around_! >> http://www.ozlabs.org/~dgibson >> > > > > -- > "The Good You Do, The Best You GET" > > Regards > Srikanth Krishnakar > ********************** >
On Mon, May 25, 2009 at 12:30 AM, srikanth krishnakar <skrishnakar@gmail.com> wrote: > Hello Grant, > > Is there any conclusion of the below discussion: > > http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html > > Xilinx target (virtex5) hangs (while running GDBServer & KGDB) without > the DBCR0 initialization. > > Can you please comment on this ? IIRC, John Linn was hacking on a patch. Search the mailing list archives for DBCR0. g.
Hi John, I am not finding any conclusion of the plan to add DBCR0 initialization code to head_44x.S after this discussion : http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html#a23049044 Can you please comment ? Thanks, -Srikanth Krishnakar On Mon, May 25, 2009 at 12:09 PM, Grant Likely <grant.likely@secretlab.ca> wrote: > On Mon, May 25, 2009 at 12:30 AM, srikanth krishnakar > <skrishnakar@gmail.com> wrote: >> Hello Grant, >> >> Is there any conclusion of the below discussion: >> >> http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html >> >> Xilinx target (virtex5) hangs (while running GDBServer & KGDB) without >> the DBCR0 initialization. >> >> Can you please comment on this ? > > IIRC, John Linn was hacking on a patch. Search the mailing list > archives for DBCR0. > > g. > > -- > Grant Likely, B.Sc., P.Eng. > Secret Lab Technologies Ltd. >
On Wed, 2009-05-20 at 16:00 +1000, David Gibson wrote: > On Wed, May 20, 2009 at 11:20:46AM +0530, srikanth krishnakar wrote: > > Hi David, > > > > I am not sure how the IDM behaves on few of PPC440 targets which don't > > have boot loaders. I have a reference for your question: > > > > http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html > > > > Without this fix (given patch) I am facing problems with GDB, and > > further target hangs while running gdbserver ! > > That doesn't answer my question. It's not enough to say "this fixes a > problem" you need to explain *how* it fixes the problem. > > And I don't see why IDM would have any effect on *software* > breakpoints. No but gdb can use the DABR emulation and single step would be busted too. GDB internally heavily uses single step in places you wouldn't expect it to :-) Like I think when breaking on main, it sometimes single step the whole init process of the executable until it hits it. At least I've seen it do that when I was debugging the debug support for 64-bit Book3E. Cheers, Ben. > > On Wed, May 20, 2009 at 5:23 AM, David Gibson > > <david@gibson.dropbear.id.au> wrote: > > > On Tue, May 19, 2009 at 06:38:53PM +0530, srikanth krishnakar wrote: > > >> Hi, > > >> > > >> kernel- 2.6.29 > > >> Debug technique: KGDB > > >> > > >> The PowerPC kernel does not initialize the PPC440 DBCR0 register. This > > >> prevents the use of software breakpoints in case of internal debug > > >> mode. Looking into head_fsl_booke.S for initialization of DBCR0 is > > >> used by boot-loaders. > > >> It seems head_44x.S lacks this step of DBCR0 register initialization. > > >> So fixing this with initializing the DBCR0 register as shown below : > > >> > > >> Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not having > > >> bootloader > > >> > > >> The kernel does not initialize the PPC440 DBCR0 register. > > >> This prevents (among other things) the use of software > > >> breakpoints with GDB. The boot loaders probably do initialize > > >> this but few targets run without a boot loader > > > > > > Um.. how does this prevent the use of software breakpoints with gdb? > > > The trap instructions still work with IDM==0. >
On Mon, May 25, 2009 at 05:04:35PM +1000, Benjamin Herrenschmidt wrote: > On Wed, 2009-05-20 at 16:00 +1000, David Gibson wrote: > > On Wed, May 20, 2009 at 11:20:46AM +0530, srikanth krishnakar wrote: > > > Hi David, > > > > > > I am not sure how the IDM behaves on few of PPC440 targets which don't > > > have boot loaders. I have a reference for your question: > > > > > > http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html > > > > > > Without this fix (given patch) I am facing problems with GDB, and > > > further target hangs while running gdbserver ! > > > > That doesn't answer my question. It's not enough to say "this fixes a > > problem" you need to explain *how* it fixes the problem. > > > > And I don't see why IDM would have any effect on *software* > > breakpoints. > > No but gdb can use the DABR emulation and single step would be busted > too. GDB internally heavily uses single step in places you wouldn't > expect it to :-) Like I think when breaking on main, it sometimes single > step the whole init process of the executable until it hits it. At least > I've seen it do that when I was debugging the debug support for 64-bit > Book3E. Right, but I believe the kernel does turn on IDM when it turns on single step, or the DAC event bit.
> -----Original Message----- > From: srikanth krishnakar [mailto:skrishnakar@gmail.com] > Sent: Monday, May 25, 2009 12:51 AM > To: John Linn > Cc: Linuxppc-dev@ozlabs.org > Subject: Re: Initialize DBCR0 for PPC440 targets > > Hi John, > > I am not finding any conclusion of the plan to add DBCR0 > initialization code to head_44x.S after this discussion : There was no conclusion and I haven't had time yet to chase it further. > > http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html#a23049044 > > Can you please comment ? > > Thanks, > -Srikanth Krishnakar > > On Mon, May 25, 2009 at 12:09 PM, Grant Likely > <grant.likely@secretlab.ca> wrote: > > On Mon, May 25, 2009 at 12:30 AM, srikanth krishnakar > > <skrishnakar@gmail.com> wrote: > >> Hello Grant, > >> > >> Is there any conclusion of the below discussion: > >> > >> http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html > >> > >> Xilinx target (virtex5) hangs (while running GDBServer & KGDB) without > >> the DBCR0 initialization. > >> > >> Can you please comment on this ? > > > > IIRC, John Linn was hacking on a patch. Search the mailing list > > archives for DBCR0. > > > > g. > > > > -- > > Grant Likely, B.Sc., P.Eng. > > Secret Lab Technologies Ltd. > > > > > > -- > "The Good You Do, The Best You GET" > > Regards > Srikanth Krishnakar > ********************** 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.
diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S index a4a890a..b413bc4 100644 --- a/arch/powerpc/kernel/head_44x.S +++ b/arch/powerpc/kernel/head_44x.S @@ -240,6 +240,18 @@ skpinv: addi r4,r4,1 /* Increment */ lis r4,interrupt_base@h /* IVPR only uses the high 16-bits */ mtspr SPRN_IVPR,r4 +#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 is where the main kernel code starts. */