This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Multiple code images in flash
- From: Bart Veer <bartv at ecoscentric dot com>
- To: laurie dot gellatly at netic dot com
- Cc: ecos-discuss at sources dot redhat dot com
- Date: 05 Sep 2006 08:36:58 +0100
- Subject: Re: [ECOS] Multiple code images in flash
- References: <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