public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Sergei Gavrikov <w3sg@SoftHome.net>
To: "Meiring, H, Mnr <meiring@sun.ac.za>" <meiring@sun.ac.za>
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Memory layout recommendation
Date: Mon, 03 Sep 2007 19:30:00 -0000	[thread overview]
Message-ID: <20070903192829.GA10336@ubuntu> (raw)
In-Reply-To: <FC829C66C7DA824A96A893C28F1B7AD969E892@STBEVS01.stb.sun.ac.za>

Meiring, H, Mnr <meiring@sun.ac.za> writes:

> I have succesfully got ecos(or the hello world app using eCos) running
> on the Atmel at91sam7a2 ev kit(out of RAM). 
> 
> At the moment the port is integrated into the at91sam7 family, but it
> is a bit messy. I think I will later change the at91sam7a2 to a
> separate platform port due to the lack of similarity between the sam7s
> and x platforms. 
> 
> What to do for a board with 16k internal RAM and 1 external SRAM chips
> of 512 KB each. Do I ignore the internal RAM? And if not what sections
> would you recommend be put there?

It's hardy to suggest how to organize plf. memory layout files outside
the eCos road, because that closely depends on .S sources :-) But, I
think that you will get the message observing the results:

find ${ECOS_REPOSITORY}/hal/arm/at91 -name \*ldi | xargs grep -A1 sram

I did find: there are a few templates what you wanted there.

If CPU supports the vectors remapping (from internal Flash to internal
RAM), you would place the '.fixed_vectors' section there. Certainly, you
have to support this feature in a platform setup (hal_platform_setup.h).

Also, you can use that region as some fast storage, for example, if you
describe some additional section(s) in the memory layout files. You can
even run code there, but that isn't a standard usage.

16K is small slice, but that is the gold slice if you need to test any
parts on an amateur board. For example, I use a special memory layout
(external memory less) to run 'GNU memtester' using same 16K region to
hold even .data and .bss sections (NXP LPC2294 has 16K of IRAM too). I
use eCos 'minimal' template (kernel less) to build such H/W tests.

Note: It's needed to know how CPU use that 16K region in all modes. For
example, some CPUs use (LPCs do) a part of internal RAM for firmware IAP
(IAP calls use part of IRAM for own buffers). So, you haven't to
overwrite such regions in your .ldi file.


	Sergei


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

      reply	other threads:[~2007-09-03 19:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-02 21:55 Meiring, H, Mnr <meiring@sun.ac.za>
2007-09-03 19:30 ` Sergei Gavrikov [this message]

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=20070903192829.GA10336@ubuntu \
    --to=w3sg@softhome.net \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=meiring@sun.ac.za \
    /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).