public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Bart Veer <bartv@ecoscentric.com>
To: laurie.gellatly@netic.com
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Multiple code images in flash
Date: Tue, 05 Sep 2006 07:37:00 -0000	[thread overview]
Message-ID: <pny7syhihx.fsf@delenn.bartv.net> (raw)
In-Reply-To: <OBEELMDOHGDFDEMJCJCJIENLKFAA.laurie.gellatly@netic.com>

>>>>> "Laurie" == Laurie Gellatly <laurie.gellatly@netic.com> writes:

    Laurie> Hi All,
    Laurie> I am developing an ARM based system that has room in flash
    Laurie> for maybe 3 copies of its code. There is insufficient room
    Laurie> in RAM for a copy of the code to run so the app must run
    Laurie> from flash. I'd like to provide a system that can support
    Laurie> downloadable firmware updates.

    Laurie> I believe that the app code is position dependant so
    Laurie> although I could have copies at different flash locations
    Laurie> it becomes messy to maintain.

    Laurie> I'm interested in hearing how others have solved this
    Laurie> problem.

You do not say whether or not the application is an eCos one. eCos
applications are not position-independent, they are linked to run at
specific addresses. That is fine if the application will end up
running from RAM, but not if it may run from one of three locations in
the flash. To complicate things further, if the code is in flash then
you cannot achieve position-indepence by having some relocation info
within the image and then going through the image at run-time to
adjust various addresses. So what you are describing is very hard. It
might be possible to do something with an MMU, but I do not think
anybody has solved this particular problem in the eCos world before.

    Laurie> Also, I gather that I'll need to run any flash programming
    Laurie> from RAM rather than from an unaffected section of flash.
    Laurie> I'm interested in hearing how this affects and is catered
    Laurie> for in the solution.

eCos flash drivers arrange for the critical low-level flash
manipulation functions to reside in RAM, even if the main application
runs from flash. Look at a typical flash driver and search for .2ram
sections. Care still has to be taken, e.g. you do not want an
interrupt to go off while the flash is in a funny state if the
interrupt handler resides in flash.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
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:[~2006-09-05  7:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-04 10:34 [ECOS] Re: Re: unable to execute linux kernel with Redboot Claudio Scordino
2006-09-04 11:14 ` [ECOS] " Amitesh Singh
     [not found]   ` <200609051509.40563.cloud.of.andor@gmail.com>
2006-09-05 13:51     ` Amitesh Singh
2006-09-05 13:58       ` Claudio Scordino
2006-09-06  6:58         ` [ECOS] little mistake in redboot.cdl? Wang Cui
2006-09-07  5:42           ` [ECOS] How to build a executed-in-flash application? Wang Cui
2006-09-07  7:38             ` Andrew Lunn
2006-09-07  9:35               ` wang cui
2006-09-07  9:43                 ` Andrew Lunn
2006-09-08  2:53                   ` wang cui
2006-09-07 13:38             ` Bart Veer
2006-09-08  1:22               ` wang cui
2006-09-04 15:08 ` [ECOS] Re: Re: unable to execute linux kernel with Redboot Mark Salter
2006-09-05  0:53   ` [ECOS] Multiple code images in flash Laurie Gellatly
2006-09-05  7:37     ` Bart Veer [this message]
2006-09-05  8:48       ` Ilija Koco
2006-09-05  9:31         ` Bart Veer
2006-09-05 11:25           ` Laurie Gellatly

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=pny7syhihx.fsf@delenn.bartv.net \
    --to=bartv@ecoscentric.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=laurie.gellatly@netic.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).