public inbox for sid@sourceware.org
 help / color / mirror / Atom feed
From: "Robert Cragie" <rcc@jennic.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: <sid@sources.redhat.com>
Subject: RE: Trying to run on pid7t board
Date: Thu, 22 Aug 2002 04:48:00 -0000	[thread overview]
Message-ID: <NDBBLOIOMLKELOJBAPAGMEIBCOAA.rcc@jennic.com> (raw)
In-Reply-To: <20020821143141.C7180@redhat.com>

> Aha.  The remapper is indeed involved, as is the eCos startup sequence.
> It seems that after the access to 0xb000020, the 0x0-0xffff mapping window
> into 0x4000000 disappears.  In such circumstances, the code can only work
> if the running PC switches over to the ROM area (0x40008048).  In some
> versions of eCos, this is forced by the first few instructions, apparently
> not yours.

This would explain the slightly odd startup sequence of:

      ldr     r0,=10f
      mov     pc,r0
10:	ldr	r0,=MEM_RESET
	str	r0,[r0]

i.e. the second opcode just moves the pc to where it would have gone anyway.

> There are a couple of possible workarounds.  If you are positive that your
> eCos application will run correctly on a board of interest, then you could
> toggle sid's remapper setting (add "-normalmap" to the "--board" argument
> sublist as in "--board=pid7t-normalmap").  Other ways would involve tweak
ing
> the eCos startup sequence, or the executable, or sid loading/startup.

Adding the -normalmap argument worked - thanks. I will point this out on the
eCos mailing list, as the default sid flags for the RAM build won't work.
Next step is to try to work out why printf() doesn't work, however this
seems to be an eCos issue. However, while I'm here, can you tell me how the
serial ports work on the simulation (i.e. what happens when I write a
character), or point me at some appropriate docs.?

> Please be aware that in your given mode, sid is attempting to
> emulate a board just after powerup.  If your application assumes that it's
being loaded by
> an already-running monitor, such mismatches need to be corrected some way.

I think I misunderstood the way the gloss component works - I guess it's
more like an on-chip ICE than a debug monitor.

Thanks for your help

Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655



  reply	other threads:[~2002-08-22 11:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-21  9:24 Robert Cragie
2002-08-21  9:35 ` Frank Ch. Eigler
2002-08-21 11:15   ` Robert Cragie
2002-08-21 11:31     ` Frank Ch. Eigler
2002-08-22  4:48       ` Robert Cragie [this message]
2002-08-22  6:22         ` Frank Ch. Eigler
2002-08-22  7:11           ` Ben Elliston
2002-08-22 10:09           ` Robert Cragie

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=NDBBLOIOMLKELOJBAPAGMEIBCOAA.rcc@jennic.com \
    --to=rcc@jennic.com \
    --cc=fche@redhat.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).