This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
RE: Multiple code images in flash
- From: "Laurie Gellatly" <laurie dot gellatly at netic dot com>
- To: "Bart Veer" <bartv at ecoscentric dot com>, <ilijak at siva dot com dot mk>
- Cc: <ecos-discuss at sources dot redhat dot com>
- Date: Tue, 5 Sep 2006 21:26:25 +1000
- Subject: RE: [ECOS] Multiple code images in flash
- Reply-to: <laurie dot gellatly at netic dot com>
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