RE: Question about DBCR0 initialization for 440
Josh, any thoughts on putting this into head_44x.S? Thanks, John From: linuxppc-dev-bounces+john.linn=xilinx@ozlabs.org [mailto:linuxppc-dev-bounces+john.linn=xilinx@ozlabs.org] On Behalf Of Tirumala Reddy Marri Sent: Wednesday, April 15, 2009 10:24 AM To: John Linn; jwbo...@linux.vnet.ibm.com; grant.lik...@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@ozlabs.org [mailto:linuxppc-dev-bounces+tmarri=amcc@ozlabs.org] On Behalf Of John Linn Sent: Tuesday, April 14, 2009 1:33 PM To: jwbo...@linux.vnet.ibm.com; grant.lik...@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_...@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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Question about DBCR0 initialization for 440
On Fri, Apr 17, 2009 at 11:46 AM, John Linn john.l...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Question about DBCR0 initialization for 440
On Friday 17 April 2009 12:22:37 Josh Boyer wrote: On Fri, Apr 17, 2009 at 11:46 AM, John Linn john.l...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
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 jwbo...@linux.vnet.ibm.com wrote: On Fri, Apr 17, 2009 at 11:46 AM, John Linn john.l...@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 -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Question about DBCR0 initialization for 440
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.l...@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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Question about DBCR0 initialization for 440
On Fri, Apr 17, 2009 at 1:04 PM, Benjamin Herrenschmidt b...@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.l...@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. ppc440x5_um.pdf says that both can be enabled. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Question about DBCR0 initialization for 440
Thanks everyone, will do. -Original Message- From: Grant Likely [mailto:grant.lik...@secretlab.ca] Sent: Friday, April 17, 2009 12:58 PM To: Josh Boyer Cc: John Linn; Tirumala Reddy Marri; linuxppc-dev@ozlabs.org; holl...@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 jwbo...@linux.vnet.ibm.com wrote: On Fri, Apr 17, 2009 at 11:46 AM, John Linn john.l...@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 -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Question about DBCR0 initialization for 440
-Original Message- From: Grant Likely [mailto:grant.lik...@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 b...@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.l...@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. 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. #if !defined(CONFIG_BDI_SWITCH) /* * The Abatron BDI JTAG debugger does not tolerate others * mucking with the debug registers. */ lis r2,dbcr0_...@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 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
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. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Question about DBCR0 initialization for 440
-Original Message- From: Josh Boyer [mailto:jwbo...@linux.vnet.ibm.com] Sent: Friday, April 17, 2009 2:36 PM To: John Linn Cc: grant.lik...@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 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
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_...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Question about DBCR0 initialization for 440
On Fri, Apr 17, 2009 at 02:41:26PM -0600, John Linn wrote: -Original Message- From: Josh Boyer [mailto:jwbo...@linux.vnet.ibm.com] Sent: Friday, April 17, 2009 2:36 PM To: John Linn Cc: grant.lik...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Question about DBCR0 initialization for 440
-Original Message- From: Hollis Blanchard [mailto:holl...@us.ibm.com] Sent: Friday, April 17, 2009 2:50 PM To: John Linn Cc: grant.lik...@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_...@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 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
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@ozlabs.org [mailto:linuxppc-dev-bounces+tmarri=amcc@ozlabs.org] On Behalf Of John Linn Sent: Tuesday, April 14, 2009 1:33 PM To: jwbo...@linux.vnet.ibm.com; grant.lik...@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_...@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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
