public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Bart Veer <bartv@ecoscentric.com>
To: ilijak@siva.com.mk
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Multiple code images in flash
Date: Tue, 05 Sep 2006 09:31:00 -0000	[thread overview]
Message-ID: <pnwt8ihdel.fsf@delenn.bartv.net> (raw)
In-Reply-To: <44FD39D4.3040008@siva.com.mk> (message from Ilija Koco on Tue, 	05 Sep 2006 10:48:20 +0200)

>>>>> "Ilija" == Ilija Koco <ilijak@siva.com.mk> writes:

    Ilija> Bart Veer wrote:
    >> 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.
    Ilija> Could it be possible with some compile/link options to
    Ilija> produce position independent code? I have experience with
    Ilija> other RTOS (Microware OS-9) that is completely position
    Ilija> independent, and I may say that it would bring a benefit.
    Ilija> It would provide simple method for dynamic loading of user
    Ilija> applications, remote (through net) updates, etc.

Position-independent code that resides in flash and with no MMU
mangling? Rather tricky. Consider the following:

    const CYG_FLASH_FUNS(cyg_mcf52xx_cfm_core_funs,
               &cyg_mcf52xx_cfm_init,
               &cyg_flash_devfn_query_nop,
               &cyg_mcf52xx_cfm_erase,
               &cyg_mcf52xx_cfm_program,
               (int (*)(struct cyg_flash_dev*, const cyg_flashaddr_t, void*, size_t))0,
               0,
               0
    );

i.e. define a data structure that contains a number of function
pointers like &cyg_mcf52xx_cfm_init(). That statically initialized
data structure needs to have the real function addresses, no amount of
PC-relative addressing in the instruction set is going to help with
that. Because the structure is const it is going to reside in flash
rather than RAM, so there is no opportunity at run-time to process
relocation information and update the data structure.

So either:

  1) ban this sort of construct. Sorry, but there may be any number of
     places within the existing source code that already uses such
     constructs.

  2) use an MMU to rearrange the memory map to match what the
     application expects. By design eCos does not play games with the
     MMU like that.

  3) perform some sort of relocation as you are programming the
     application into flash at one of the three addresses.

  4) forget about position-independent code and link for a fixed
     address, which is the way eCos is designed to work. In theory you
     could link your application three times, once for each of the
     valid addresses, and install the appropriate application image
     when you have decided which block of flash to overwrite.

    Ilija> I would like to have some comments from eCos architects.

Check my signature.

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  9:31 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
2006-09-05  8:48       ` Ilija Koco
2006-09-05  9:31         ` Bart Veer [this message]
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=pnwt8ihdel.fsf@delenn.bartv.net \
    --to=bartv@ecoscentric.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=ilijak@siva.com.mk \
    /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).