This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Multiple code images in flash


All,
Thanks for all the replies. Yes, this is an eCos application.
I was hoping that either someone would say you run this fancy load routine
and it does the reloaction for you
OR
We always run from the same flash location and this is how we manage the 3
copies we do xxx and copy
and erase and ... and then we are using the new version.

The first one sounds impossible to me now.
Sounds like the second approach is still possible.
Anyone done that?			...Laurie:{)


-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org]On Behalf Of Bart Veer
Sent: Tuesday, 5 September 2006 7:27 PM
To: ilijak@siva.com.mk
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Multiple code images in flash


>>>>> "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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]