From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45383 invoked by alias); 26 Mar 2015 19:05:39 -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 45335 invoked by uid 89); 26 Mar 2015 19:05:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: smtp-out4.electric.net Received: from smtp-out4.electric.net (HELO smtp-out4.electric.net) (192.162.216.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 26 Mar 2015 19:05:37 +0000 Received: from 1YbD5w-0007mw-Tw by out4a.electric.net with emc1-ok (Exim 4.84) (envelope-from ) id 1YbD5w-0007o9-VL; Thu, 26 Mar 2015 12:05:32 -0700 Received: by emcmailer; Thu, 26 Mar 2015 12:05:32 -0700 Received: from [82.0.240.193] (helo=GLAEXCH3.ftdi.local) by out4a.electric.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YbD5w-0007mw-Tw; Thu, 26 Mar 2015 12:05:32 -0700 Received: from GLAEXCH1.ftdi.local ([172.16.0.121]) by glaexch3 ([172.16.0.161]) with mapi id 14.01.0438.000; Thu, 26 Mar 2015 19:05:31 +0000 From: James Bowman To: Mike Frysinger CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH, FT32] gdb and sim support Date: Thu, 26 Mar 2015 19:05:00 -0000 Message-ID: References: <20150224045154.GE13523@vapier> <20150316082548.GC12926@vapier> <20150319185217.GC4128@vapier> <20150320051809.GD11803@vapier> <20150320051909.GE11803@vapier> ,<20150326071024.GB12423@vapier> In-Reply-To: <20150326071024.GB12423@vapier> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-IP: 82.0.240.193 X-Env-From: james.bowman@ftdichip.com X-PolicySMART: 3094660 X-SW-Source: 2015-03/txt/msg00868.txt.bz2 > > +/* > > + * 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. > > + * > > + * 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 yo= u put > address 0 into a register and try to do a data load/store, does it throw = an > exception ? or is it transparently routed to 800000 ? At the hardware level, there are two things that have address 0: a piece of RAM and an instruction. The CPU uses different instructions to read RAM and instruction memory. > Blackfin cpus are described as Harvard because it has on-chip memory that= can > only be accessed either as insn or as data, but it's a unified memory map= . for > example, if you were to execute (jump to) 0xffa00000, it'd work, but if y= ou > tried to do a load/store with 0xffa00000, the hardware would throw an exc= eption. > if you were to execute (jump to) 0xff800000, the hardware would throw an > exception, but you could do a load/store just fine. FT32 is closer to the AVR. Both memory spaces start at address zero. > i'm not sure gdb or the sim generally support processors with overlapping > memory. i.e. a $pc of 0 is completely different from a $r0 (data registe= r) with > the address of 0. I believe that offsetting RAM at 800000 is the same way the AVR gdb port wo= rks. The FT32 gdb uses the same approach. We generate a link map that declares=20 the RAM at address 800000. Then GDB can use a single pointer to represent either an instruction or a RAM address. FT32's gdb interface understands that bit 23 of an address distinguishes betweeen instruction and RAM. This all seems to work quite well, and of course following the same=20 model in the simulator has made the gdb-sim interface quite straightforward. > i tried to grab some datasheets from ftdichip.com, but (1) couldn't seem = to find > anything on the architecture (just datasheets for specific parts which co= vered > more system devices than the ISA/core) and (2) it's crazy slow to downloa= d from. I will mention this to the people at FTDI. The FT900 (which contains the FT32 is still new). -- James Bowman FTDI Open Source Liaison