From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24532 invoked by alias); 19 Jun 2002 01:46:31 -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 24409 invoked from network); 19 Jun 2002 01:46:23 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 19 Jun 2002 01:46:23 -0000 Received: from tooth.toronto.redhat.com (unknown [172.16.14.29]) by touchme.toronto.redhat.com (Postfix) with ESMTP id DADFFB8004; Tue, 18 Jun 2002 21:46:22 -0400 (EDT) Received: (from bje@localhost) by tooth.toronto.redhat.com (8.11.6/8.11.6) id g5J1kMf02579; Tue, 18 Jun 2002 21:46:22 -0400 From: Ben Elliston MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15631.57966.122255.2563@tooth.toronto.redhat.com> Date: Tue, 18 Jun 2002 18:46:00 -0000 To: Scott Dattalo Cc: sid@sources.redhat.com Subject: Re: SID and eCos In-Reply-To: References: X-SW-Source: 2002-q2/txt/msg00031.txt.bz2 Hi Scott, >>>>> "Scott" == Scott Dattalo writes: Scott> The Makefile I used to create the executable is part of eCos. I Scott> specifically target Atmel's AT91EB40 evaluation board. The generic, out of Scott> the box, SID arm emulation knows nothing about an AT91EB40. The error Scott> reported above is telling me that the executable accesses RAM that doesn't Scott> exist (hey, I think I like that:). So I added a few --memory-region's: Scott> $ arm-elf-sid --cpu=arm --memory-region=0x2020000,0x20000 Scott> --memory-region=0xfffe0000,0x1ffff --gdb=2000 -EL hello Scott> And that worked! You're right. The problem is that the default ARM configuration does not include as expansive memory regions as the GDB simulator, so your program was writing into unmapped regions. Scott> So now it looks like I have not one, but two (mostly) independent ways to Scott> simulate my source. I like the SID approach because of the added Scott> flexibility; specifically the ability to profile. Great! I'm pleased that you've seen SID for what it is. Scott> sid appears to be an extraordinarily powerful tool. Is there any reason Scott> why it's not more popular? Judgeing from the mailing list archives, it Scott> appears that not too many people are using it. I believe there are at least a couple of factors: * it has only been out on the net for a year or so; and * I don't think it is very widely known about. Scott> investigate to what extent it's possible to leverage our two projects. Scott> Specifically, I'd like to incorporate the abstract hardware interface that Scott> sid supports with gpsim. And to reciprocate, I can add some of gpsim's Scott> modules to sid! That'd be terrific! Can you summarise what gpsim modules you have? Regards, Ben