public inbox for sid@sourceware.org
 help / color / mirror / Atom feed
From: Scott Dattalo <scott@dattalo.com>
Cc: sid@sources.redhat.com
Subject: Re: SID and eCos
Date: Tue, 18 Jun 2002 15:59:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.44.0206181526290.14647-100000@ruckus.brouhaha.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0206181340120.13146-100000@ruckus.brouhaha.com>

On Tue, 18 Jun 2002, Scott Dattalo wrote:

> 
> I'm trying to use SID to simulate an ARM processor. When I build a "hello 
> world" example and try to simulate it, I get this:
> 
> $ arm-elf-sid hello
> loader: write to data accessor failed at address 0x2020000, status 2
> loader: error loading hello

I think I answered my question.

The Makefile I used to create the executable is part of eCos. I 
specifically target Atmel's AT91EB40 evaluation board. The generic, out of 
the box, SID arm emulation knows nothing about an AT91EB40. The error 
reported above is telling me that the executable accesses RAM that doesn't 
exist (hey, I think I like that:).  So I added a few --memory-region's:

$ arm-elf-sid --cpu=arm --memory-region=0x2020000,0x20000 
--memory-region=0xfffe0000,0x1ffff --gdb=2000 -EL hello

And that worked! 

So now it looks like I have not one, but two (mostly) independent ways to 
simulate my source. I like the SID approach because of the added 
flexibility; specifically the ability to profile.

----

As an aside...

sid appears to be an extraordinarily powerful tool. Is there any reason 
why it's not more popular? Judgeing from the mailing list archives, it 
appears that not too many people are using it.

As another asided, I'm the primary author the GNUPIC Simulator, gpsim.  
This is a GPL'd simulator of Microchip PIC microcontrollers. The homepage
is: http://www.dattalo.com/gnupic/gpsim.html . The GNUPIC tool chain does
not use gcc/binutils - instead we emulate Microchip's tool chain and I'm
porting to SDCC (Small Device C Compiler). However, I'm going to
investigate to what extent it's possible to leverage our two projects.
Specifically, I'd like to incorporate the abstract hardware interface that
sid supports with gpsim.  And to reciprocate, I can add some of gpsim's
modules to sid!

Scott

  reply	other threads:[~2002-06-18 22:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-18 13:51 Scott Dattalo
2002-06-18 15:59 ` Scott Dattalo [this message]
2002-06-18 18:46   ` Ben Elliston
2002-06-18 22:06     ` Scott Dattalo
2002-06-19 14:19       ` Ben Elliston
2002-06-19 20:42         ` Scott Dattalo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0206181526290.14647-100000@ruckus.brouhaha.com \
    --to=scott@dattalo.com \
    --cc=sid@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).