DBCR0 reset?

DBCR0 reset?

[Hollis Blanchard]

Has anyone had problems with hardware breakpoints from external
debuggers? I'm using RISCWatch, which sets DBCR0 and IAC1 for me (yes
I've verified that). I'm then using 'echo > /proc/sys' to invoke my
code. However by the time I get to my sysctl proc handler, DBCR0 has
been reset from 0x80810000 to 0x00010000, hence IAC1 is ignored.

I don't see much use of DBCR0, other than initialization and then save
during exception prologs and then restore during task restore. Can
anyone point me to where it might be reset?

-Hollis

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: DBCR0 reset?

[Ralph Blach]

Hollis,

The OS does this.  I send you the info on how to disable it tommorrow.

Chip

Hollis Blanchard wrote:
> Has anyone had problems with hardware breakpoints from external
> debuggers? I'm using RISCWatch, which sets DBCR0 and IAC1 for me (yes
> I've verified that). I'm then using 'echo > /proc/sys' to invoke my
> code. However by the time I get to my sysctl proc handler, DBCR0 has
> been reset from 0x80810000 to 0x00010000, hence IAC1 is ignored.
>
> I don't see much use of DBCR0, other than initialization and then save
> during exception prologs and then restore during task restore. Can
> anyone point me to where it might be reset?
>
> -Hollis
>
>
>
> .
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: DBCR0 reset?

[David Gibson]

On Tue, Oct 29, 2002 at 05:10:44PM -0500, Ralph Blach wrote:
> Hollis,
>
> The OS does this.  I send you the info on how to disable it tommorrow.

Please send it to the list as well - I've encountered this problem as
well.  Although it usually doesn't happen quite this quickly.

> Hollis Blanchard wrote:
> >Has anyone had problems with hardware breakpoints from external
> >debuggers? I'm using RISCWatch, which sets DBCR0 and IAC1 for me (yes
> >I've verified that). I'm then using 'echo > /proc/sys' to invoke my
> >code. However by the time I get to my sysctl proc handler, DBCR0 has
> >been reset from 0x80810000 to 0x00010000, hence IAC1 is ignored.
> >
> >I don't see much use of DBCR0, other than initialization and then save
> >during exception prologs and then restore during task restore. Can
> >anyone point me to where it might be reset?
> >
> >-Hollis

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: DBCR0 reset?

[Matt Porter]

On Tue, Oct 29, 2002 at 01:18:19PM -0600, Hollis Blanchard wrote:
>
> Has anyone had problems with hardware breakpoints from external
> debuggers? I'm using RISCWatch, which sets DBCR0 and IAC1 for me (yes
> I've verified that). I'm then using 'echo > /proc/sys' to invoke my
> code. However by the time I get to my sysctl proc handler, DBCR0 has
> been reset from 0x80810000 to 0x00010000, hence IAC1 is ignored.
>
> I don't see much use of DBCR0, other than initialization and then save
> during exception prologs and then restore during task restore. Can
> anyone point me to where it might be reset?

As I mentioned on IRC (and just to document it for other interested
parties):

DBCR0 is modified during initialization in ppc4xx_setup.c/ebony.c if
!CONFIG_BDI_SWITCH

DBCR0 is modified during context switching as you noted but also
in Debug trap handling.

As of 02/09/02 in the _devel tree, the DBCR context switching is
broken since the move to keeping DBCRs in the thread struct is
incomplete.  This may result in the initial DBCR value being destroyed
by a null thread struct value though I haven't looked closely at
that code (otherwise it might be fixed)...2.5 is higher on my list.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/