This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: RedBoot porting
- To: Gary Thomas <gthomas at redhat dot com>,Andrew Lunn <andrew dot lunn at ascom dot ch>,eCos Disuss <ecos-discuss at sourceware dot cygnus dot com>
- Subject: Re: [ECOS] RedBoot porting
- From: Grant Edwards <grante at visi dot com>
- Date: Tue, 9 Jan 2001 11:00:44 -0600
- References: <20010108171508.U10158@biferten.ma.tech.ascom.ch> <XFMail.20010108095423.gthomas@redhat.com> <20010109095031.W10158@biferten.ma.tech.ascom.ch>
On Tue, Jan 09, 2001 at 09:50:31AM +0100, Andrew Lunn wrote:
> > I hadn't thought about this exactly. What I've been thinking
> > about is the framework withing RedBoot to allow for an update
> > in a single command, with backout magic to make it safe.
> At the moment the design of redboot stops the application doing
> the upgrade. Since it runs from FLASH and can be invoked at any
> time as soon as you start a write to the flash your application
> could die at any time. Its actually worse than that, you cannot
> use the FLASH for anything, eg local configuration information.
That's one of my concerns about running RedBoot from ROM: If I
run RedBoot from ROM, then I can't allow the application to use
any of the virtual vector stuff. The application needs to be
able to write to flash, and if RedBoot is running from flash
it's not going to be available during a flash burn.
> In my opinion redboot has to be made FLASH safe and upgradable
> in the field. This should take priority over adding new
> commands etc.
Running RedBoot from RAM solves these problems, doesn't it?
BTW, how big is RedBoot for a typical ARM implimentation? (I
haven't gotten to the point where I can build it yet.)
> What do other people on the list think?
I think I'm going to have to run RedBoot from RAM. ;)
--
Grant Edwards
grante@visi.com