From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7460 invoked by alias); 22 Jun 2004 16:08:37 -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 7435 invoked from network); 22 Jun 2004 16:08:35 -0000 Received: from unknown (HELO pine.epix.net) (199.224.64.53) by sourceware.org with SMTP; 22 Jun 2004 16:08:35 -0000 Received: from cecile.shideleff.com (hrbg-216-222-243-66-pppoe.dsl.hrbg.epix.net [216.222.243.66]) by pine.epix.net (8.12.10/2004012201/PL) with ESMTP id i5MG8SWT014096; Tue, 22 Jun 2004 12:08:31 -0400 (EDT) Received: from 192.168.2.2 (unknown [192.168.2.2]) by cecile.shideleff.com (Postfix) with ESMTP id 5FFFC48D6B; Tue, 22 Jun 2004 12:08:25 -0400 (EDT) From: Robert Shideleff To: "Frank Ch. Eigler" , sid@sources.redhat.com Subject: GDB/mapper cache problems Date: Tue, 22 Jun 2004 16:08:00 -0000 User-Agent: KMail/1.6.2 References: <200406162156.54577.bigbob@shideleff.com> <20040622024603.GB22793@redhat.com> <200406212319.30979.bigbob@shideleff.com> In-Reply-To: <200406212319.30979.bigbob@shideleff.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200406221208.25786.bigbob@shideleff.com> X-Scanned-By: MIMEDefang 2.41 X-SW-Source: 2004-q2/txt/msg00044.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alright, I figured the gdb problem. I hadn't connected the gdb yield pins t= o=20 the yield bus. gdb debugging now seems to work perfectly. I think the second part of my problem where data doesn't seem to reliably m= ake=20 its way into the dual port ram is due to mapper cache. How can I cause a=20 particular bus access to poke the yield net? I think that when a yield occu= rs=20 the mapper flushes its cache, hence the proper behavior when I set the=20 instruction counts to 1. (Is this correct?) Bob On Monday 21 June 2004 11:19 pm, Robert Shideleff wrote: > I'll try it tomorrow. >=20 > In the mean time, I have also found that in order for the simulation to r= un > sensibly and to use gdb properly, I have had to set the step count for bo= th > processors to 1. Does this make sense to you? >=20 > If I don't set the step count to 1, then I find the that gdb on the second > processor will jump some large number of instructions for every step > instruction command to gdb. The problems seem to extend to the hardware > interaction as well. I haven't characterized this very well yet, but it=20 seems > like interactions between the processors is not getting tracked/handled > correctly. Data going through the dual port RAM seems to get lost. Of cou= rse > the real pain in the a** here is that it is probably not just a sim bug, = but > an interaction between a sim bug and my specific code. (My code runs on > actual hardware correctly, so I am reasonably confident in it.) >=20 > As long as I keep both step sizes set at 1, everything seems to work more= or > less correctly up until it accesses a new AMD CFI flash component I have > written. It fails here, but even the failure is a 'good' failure in that = the > processors reacted correctly to bogus flash. This is well past the first = set > of Dual Port RAM interactions, which seem to go correctly. >=20 > (I'll provide patches for the flash device once I get it working right.) >=20 > Bob >=20 >=20 > On Monday 21 June 2004 10:46 pm, you wrote: > > Hi - > > > > > [...] > > > There is no core dump when it crashes. > > > (gdb) run > > > Starting program: /usr/local/bin/sid --board=3Dbasic --cpu=3Darm7t > --board=3Dbasic --cpu=3Darm7t > > > [...] > > > > You may have better luck with the crash diagnosis if you build > > sid statically linked (configure with "--disable-shared"). > > > > > > - FChE > > > > >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA2Fl48XjOGQDr37YRArNiAKCCgSktHx9hy2umxLZQpbeKsPr5eQCfTE6e JuzHoCglubfvZD0/qVkEE1U=3D =3DnFZ2 -----END PGP SIGNATURE-----