public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Grant Edwards <grante@visi.com>
To: Gary Thomas <gthomas@cygnus.co.uk>
Cc: ecos <ecos-discuss@sourceware.cygnus.com>
Subject: Re: [ECOS] ARM vectors.S question
Date: Tue, 26 Oct 1999 18:42:00 -0000	[thread overview]
Message-ID: <19991026204215.B27067@visi.com> (raw)
In-Reply-To: <XFMail.991026161225.gthomas@cygnus.co.uk>

On Tue, Oct 26, 1999 at 04:12:25PM -0600, Gary Thomas wrote:

> > For example, it assumes that there is RAM at address 0 so the
> > startup code initializes the exception vectors that are at address 0.
> > 
> > After reset, the SNDS board has ROM at address 0, as will any embedded
> > system (if I understand the processor startup sequence).  There are
> > two ways to deal with this:
> > 
> >  1) The SNDS ROM vectors interrupts via a table of addresses that is
> >     in RAM, so user code can install pointers to ISRs in RAM at a
> >     particular address (0x13fffd0, FWIW).
> > 
> >  2) The memory configuration can be altered after startup to re-map RAM
> >     to address 0 and ROM to somewhere else.
> > 
> > Either of these would require changes to "platform independent"
> > sections of eCOS. 
> > 
> > Am I missing something?
> 
> Not at all.  To date, we have assumed that the environment on ARM platforms
> will have RAM at zero.  This is the most flexible and easiest setup for us.

I can see that it would be easiest, but I don't see how you can build
a useful system with RAM at zero.  Since the reset vector is at 0,
that location has to be non-volatile memory or the system will start
up by jumping to a location dependant on the power-up state of the
RAM.  Some types of RAM ahve a pretty consistent state at power-up,
but I don't think anybody ever depends on that trait. ;)

> However, as you note, there are some platforms that are not laid out
> this way.

Perhaps my prejudices from doing 15 years of embedded systems are
showing, but I don't see how any system could be laid out this way.
Perhaps I don't understand how the power-up reset works in the CPU?

> For the ones of these that we have already encountered, we chose to
> implement solution (2) above.
>
> There certainly will be some situations where only (1) will do.
> If/when that becomes the case, we'll have to adopt a "vectored"
> approach.
>
> Does your hardware have a MMU or some other way to alter the memory
> layout?

Yes, there's programmable chip-select logic that can be modified by
software.

The third option is to run from ROM, in which case the vectors are there
at power up, and don't need to be initialized by the startup code.

In any case, I have to change the platform independent portion of the
ARM hal to suit my platform, right?  (he asked with a grin).  I've got
no problem with that,  I just wanted to make sure that I was headed in
the right direction before I started hacking on assembly language for
a processor I've only been playing with for a week.

I must say that the ARM load/store instructions are about the coolest
I've seen since the PDP-11.

-- 
Grant Edwards
grante@visi.com

  reply	other threads:[~1999-10-26 18:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-10-26 13:44 Grant Edwards
1999-10-26 15:05 ` Gary Thomas
1999-10-26 18:42   ` Grant Edwards [this message]
1999-10-27  4:00     ` Hugo Tyson
1999-10-27  5:14     ` Gary Thomas
1999-10-27  7:01       ` Grant Edwards
1999-10-27  7:09         ` Gary Thomas
1999-10-27  1:04 ` Dan Hovang
2013-10-12 14:54 [ECOS] ARM Vectors.S Question Michael Jones

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=19991026204215.B27067@visi.com \
    --to=grante@visi.com \
    --cc=ecos-discuss@sourceware.cygnus.com \
    --cc=gthomas@cygnus.co.uk \
    /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).