From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12339 invoked by alias); 21 Aug 2002 18:15:29 -0000 Mailing-List: contact sid-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sources.redhat.com Received: (qmail 12331 invoked from network); 21 Aug 2002 18:15:27 -0000 Received: from unknown (HELO www.jennic.com) (213.143.5.74) by sources.redhat.com with SMTP; 21 Aug 2002 18:15:27 -0000 Received: from jensun01.jennic.com (jensun01.jennic.com [99.99.98.151]) by www.jennic.com (8.9.3/8.9.3) with ESMTP id SAA16872; Wed, 21 Aug 2002 18:40:18 +0100 Received: from jenpc60 (jenpc60 [99.99.98.60]) by jensun01.jennic.com (8.9.3/8.9.3) with SMTP id TAA28244; Wed, 21 Aug 2002 19:15:27 +0100 (BST) From: "Robert Cragie" To: "Frank Ch. Eigler" Cc: Subject: RE: Trying to run on pid7t board Date: Wed, 21 Aug 2002 11:15:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal In-Reply-To: <20020821123523.B7180@redhat.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal X-SW-Source: 2002-q3/txt/msg00019.txt.bz2 > On Wed, Aug 21, 2002 at 05:24:50PM +0100, Robert Cragie wrote: > > [...] > > I then connect to it using gdb (insight 5.0), and connect > successfully to > > the target. I then download the test, and inspect memory at 0x8000, no > > problem, it's there. However, when I start to run, it hits the > breakpoint I > > have set, but I notice all the code has vanished at 0x8000, and it's > > executing 0x00000000 each time. Any idea what's going on? > > Yes, that is odd. Can you tell me why you think it's executing 0x0? > You could show gdb's side of the conversation, either a console script, > or maybe even include packet traces as per `(gdb) set remote debug 3'. If I specify --trace-semantics in the sid command line I get the following: 0x8040: LDR_PRE_INC_IMM_OFFSET gr[0]:=0x8048 0x8044: MOV_REG_IMM_SHIFT pc:=0x8048 0x8048: LDR_PRE_INC_IMM_OFFSET gr[0]:=0xb000020 0x804c: STR_PRE_INC_IMM_OFFSET memory[0xb000020]:=0xb000020 0x8050: AND_REG_IMM_SHIFT 0x8054: AND_REG_IMM_SHIFT 0x8058: AND_REG_IMM_SHIFT 0x805c: AND_REG_IMM_SHIFT ...AND_REG_IMM_SHIFT looks like andeq r0,r0,r0 to me (i.e. NOP). I stepped through the code and sure enough what happens is that indeed the first three opcodes run OK, but when the fourth opcode is run, it screws up thereafter - all the memory gets set to 0. On the PID board, 'str r0,[r0]', where r0 is 0xb000020, changes the mapping of the PID board mapping RAM to 0x0000000 instead of ROM - if the REMAP board link (LK18) is in place. So it looks like the simulation of this is doing something odd causing it to go wrong - I would expect it to just carry on, as I would guess the software component of the simulation would have already remapped (as a debug monitor on a real board would have), and once this is done, it's done until the next reset. Robert Cragie, Design Engineer _______________________________________________________________ Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK http://www.jennic.com Tel: +44 (0) 114 281 2655