From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx.dlasys.net (24.152.213.223.res-cmts.eph.ptd.net [24.152.213.223]) by ozlabs.org (Postfix) with ESMTP id C0F1467BAB for ; Fri, 24 Nov 2006 19:41:03 +1100 (EST) Received: from l-dhlii.dlasys.net ([206.223.20.247]:2898) by mx.dlasys.net with esmtpa (Exim 4.62 #1 (Debian)) id 1GnWJ0-0001Qt-Ra by authid with plain_server for ; Fri, 24 Nov 2006 03:21:06 -0500 Message-ID: <4566ACD4.3020606@dlasys.net> Date: Fri, 24 Nov 2006 03:27:00 -0500 From: "David H. Lynch Jr." MIME-Version: 1.0 To: linuxppc-embedded Subject: Hardware/Software Debugging - general PPC405 Q. Content-Type: multipart/alternative; boundary="------------040001080707010504010203" List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------040001080707010504010203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have been trying to add hardware/software breakpoints to the elf loader I am using for Linux on the Pico E12/E14 boards. I have had no trouble setting up an exception handler - I found several including the one inside the kernel to "borrow" from. Using the Xilinx/IBM PPC reference I have had no problem setting a breakpoint - either by replacing an instruction with a trap, or by setting the IAC registers. I have no problem catching the exception - exactly as I expected. But despite the fact that I have cleared the dbsr, dbcr0, esr, and the appropriate bits in the msr/ appropriate srr for the exception, I can not exit from the excretion handler (back through restoring registers (except for the above changes) , without having the exception re-occur again at exactly the same place. I have poured over the Xilinx/IBM docs looking for something I am missing, some bit I need to wiggle, ... but can't find anything. Is anyone aware of a clean example dealing with ppc405 software debugging (or something similar enough to be useful) that I could use as a reference ? Anyone have any ideas what I might be missing ? Or a mailing list that might be a more appropriate target this question ? I have pasted a trace of what I am seeing - the trace is my own code - part of the software debugger I am trying to build into the bootloader. The trace at each exception only shows the registers that have changed since the last display. MonitorK.elf is the debugging version of my boot loader. Anything prefixed with a "!" is a command to MonitorK. File MonitorK.elf updated from C:\Pico\MonitorK.elf. Loading MonitorK.elf. !boot -vvTS kernel.elf Entrypoint: 0x000064e0 Cmdline @ 0x0fff0200: <> lr=0x000064e0 r3=0x0fffb000 r6=0x0fff0200 r9=0x10000000 srr0=0x000064e0 dbcr0=0x08000000 iac1=0x000064f0 r1=0x0fff0000 DBCR0: IC Traps: 0x000064ec Program Exception 00000007 @ 000064ec bch=0x0fff010c blr=0x07000780 pc=0x000064ec cr=0x40000000 r11=0x0006fa3c srr0=0x000064ec esr=0x02000000 tsr=0xc4000000 dbsr=0x98100300 dbcr0=0x09000000 DBSR: IC TDE UDE IDE DBCR0: IC TDE ESR: PEU TSR: ENW WIS Traps: 0x000064ec 000064ec: 41820008 bc 12,2,0x8 !step Program Exception 00000007 @ 000064ec tsr=0x04000000 dbsr=0x90100000 DBSR: IC TDE IDE DBCR0: IC TDE ESR: PEU TSR: Traps: 0x000064f0 000064ec: 41820008 bc 12,2,0x8 !step Program Exception 00000007 @ 000064ec tsr=0xc4000000 DBSR: IC TDE IDE DBCR0: IC TDE ESR: PEU TSR: ENW WIS Traps: 0x000064f0 0x000064f0 000064ec: 41820008 bc 12,2,0x8 !step Program Exception 00000007 @ 000064ec tsr=0x04000000 DBSR: IC TDE IDE DBCR0: IC TDE ESR: PEU TSR: Traps: 0x000064f0 0x000064f0 0x000064f0 000064ec: 41820008 bc 12,2,0x8 I can get this to repeat pretty much infinitely with nothing changing except TSR_ENW and TSR_WIS -- Dave Lynch DLA Systems Software Development: Embedded Linux 717.627.3770 dhlii@dlasys.net http://www.dlasys.net fax: 1.253.369.9244 Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein --------------040001080707010504010203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit     I have been trying to add hardware/software breakpoints to the elf loader I am using for Linux on the Pico E12/E14 boards.
    I have had no trouble setting up an exception handler - I found several including the one inside the kernel to "borrow" from.
    Using the Xilinx/IBM PPC reference I have had no problem setting a breakpoint - either by replacing an instruction with a trap, or by setting  the IAC registers.
    I have no problem catching the exception  - exactly as I expected.
    But despite the fact that I have cleared the dbsr, dbcr0, esr, and the appropriate bits in the msr/ appropriate srr for the exception,
     I can not exit from the excretion handler (back through restoring registers (except for the above changes) , without having the exception re-occur again at exactly the same place.
    I have poured over the Xilinx/IBM docs looking for something I am missing, some bit I need to wiggle, ... but can't find anything.

    Is anyone aware of a clean example dealing with ppc405 software debugging (or something similar enough to be useful)  that I could use as a reference ?
    Anyone have any ideas what I might be missing ? Or a mailing list that might be a more appropriate target this question ?

    I have pasted a trace of what I am seeing - the trace is my own code - part of the software debugger I am trying to build into the bootloader.
    The trace at each exception only shows the registers that have changed since the last display.
   
    MonitorK.elf is the debugging version of my boot loader.
    Anything prefixed with a "!" is a command to MonitorK.
   

File MonitorK.elf updated from C:\Pico\MonitorK.elf.
Loading MonitorK.elf.
!boot -vvTS kernel.elf
Entrypoint: 0x000064e0 Cmdline @ 0x0fff0200: <>
    lr=0x000064e0     r3=0x0fffb000     r6=0x0fff0200     r9=0x10000000   srr0=0x000064e0  dbcr0=0x08000000
  iac1=0x000064f0     r1=0x0fff0000
DBCR0: IC
Traps:    0x000064ec

Program Exception 00000007 @ 000064ec
   bch=0x0fff010c    blr=0x07000780     pc=0x000064ec     cr=0x40000000    r11=0x0006fa3c   srr0=0x000064ec
   esr=0x02000000    tsr=0xc4000000   dbsr=0x98100300  dbcr0=0x09000000
DBSR: IC TDE UDE IDE
DBCR0: IC TDE
ESR: PEU
TSR: ENW WIS
Traps:    0x000064ec
000064ec: 41820008 bc      12,2,0x8

!step
Program Exception 00000007 @ 000064ec
   tsr=0x04000000   dbsr=0x90100000
DBSR: IC TDE IDE
DBCR0: IC TDE
ESR: PEU
TSR:
Traps:    0x000064f0
000064ec: 41820008 bc      12,2,0x8

!step
Program Exception 00000007 @ 000064ec
   tsr=0xc4000000
DBSR: IC TDE IDE
DBCR0: IC TDE
ESR: PEU
TSR: ENW WIS
Traps:    0x000064f0 0x000064f0
000064ec: 41820008 bc      12,2,0x8

!step
Program Exception 00000007 @ 000064ec
   tsr=0x04000000
DBSR: IC TDE IDE
DBCR0: IC TDE
ESR: PEU
TSR:
Traps:    0x000064f0 0x000064f0 0x000064f0
000064ec: 41820008 bc      12,2,0x8


I can get this to repeat pretty much infinitely with nothing changing except TSR_ENW and  TSR_WIS




-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
--------------040001080707010504010203--