From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68345 invoked by alias); 26 Mar 2015 07:10:29 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 68327 invoked by uid 89); 26 Mar 2015 07:10:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: smtp.gentoo.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 26 Mar 2015 07:10:27 +0000 Received: from vapier (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id 61EA9340B03; Thu, 26 Mar 2015 07:10:25 +0000 (UTC) Date: Thu, 26 Mar 2015 07:10:00 -0000 From: Mike Frysinger To: James Bowman Cc: "gdb-patches@sourceware.org" Subject: Re: [PATCH, FT32] gdb and sim support Message-ID: <20150326071024.GB12423@vapier> Mail-Followup-To: James Bowman , "gdb-patches@sourceware.org" References: <20150224045154.GE13523@vapier> <20150316082548.GC12926@vapier> <20150319185217.GC4128@vapier> <20150320051809.GD11803@vapier> <20150320051909.GE11803@vapier> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="E/DnYTRukya0zdZ1" Content-Disposition: inline In-Reply-To: X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00840.txt.bz2 --E/DnYTRukya0zdZ1 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1608 On 23 Mar 2015 19:20, James Bowman wrote: > +/* > + * FT32 is a Harvard architecture: RAM and code occupy > + * different address spaces. > + * > + * sim and gdb model FT32 memory by adding 0x800000 to RAM > + * addresses. This means that sim/gdb can treat all addresses > + * similarly. > + *=20 > + * The address space looks like: > + * > + * 00000 start of code memory > + * 3ffff end of code memory > + * 800000 start of RAM > + * 80ffff end of RAM > + */ do they actually occupy different address spaces ? that is to say, if you = put=20 address 0 into a register and try to do a data load/store, does it throw an= =20 exception ? or is it transparently routed to 800000 ? Blackfin cpus are described as Harvard because it has on-chip memory that c= an=20 only be accessed either as insn or as data, but it's a unified memory map. = for=20 example, if you were to execute (jump to) 0xffa00000, it'd work, but if you= =20 tried to do a load/store with 0xffa00000, the hardware would throw an excep= tion.=20=20 if you were to execute (jump to) 0xff800000, the hardware would throw an=20 exception, but you could do a load/store just fine. i'm not sure gdb or the sim generally support processors with overlapping=20 memory. i.e. a $pc of 0 is completely different from a $r0 (data register)= with=20 the address of 0. i tried to grab some datasheets from ftdichip.com, but (1) couldn't seem to= find=20 anything on the architecture (just datasheets for specific parts which cove= red=20 more system devices than the ISA/core) and (2) it's crazy slow to download = from. -mike --E/DnYTRukya0zdZ1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVE7DgAAoJEEFjO5/oN/WB48oQAOT3k9vIV2GFMGCBKLzD3vu6 7ndS7wR8e/2n0zm/Qx6r9w3H/QIYCs3vXSQiU+ZWgUtdZYVJM3OeftL5hF0+MjZA foq/s3jfaz7U6isR0F1MXrcyYg2MumkFO73pJTev2I2//v4aqidoorzvpQInN6UM t6sJF9CgO3dXtVarbHeoeEDcpM8vNI/mtfRyhLa61gLYxEYLnzG9m/hUT0UffAEh eHjT45ke43OZtIE1IsiWaEM55DN9fWE5rxaBdrNyF+qUVqLW3rEClUPAerDJHov4 p6szSd8mRB7VC6UdkdIxvo5JXL/J+eahd5+ZdMx+jSq60Yzc2+TykgLz1/6ipIJp 4DEYkXR6DKnQJXrOZzPtSi7Sp67jdHZXoTy4OuYPaLSHCuO24baNY8bzYQIjb67W mqfQayxkXIj53FQYWSLIpOyBaAbmuc42BAUdJtNq2wnfItRoQc7a3SdoEeQzLuK3 WiSdECBbek6UsQNCtmdKbQPBljoIfMIviBbztyTWFOfNXhs0vQKy2vK29+AXdG9V QR0K3ctFC+2mGc6irJbhv1HEyGL0cTIrUK0ZDWn5qORey15kMe+QpDx6TmLKvl3a X/oOocOz7rcqYG0Uhdc0EQv1KYw+YgvZvi8nxaFqKelq+c4uNc6Hk//qCo/dRaF7 X458+CJXA+lrnkV6UxnE =CjOd -----END PGP SIGNATURE----- --E/DnYTRukya0zdZ1--