Re: [ECOS] RedBoot porting

[Andrew Lunn <andrew.lunn@ascom.ch>]

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

I assume this makes the assumption that an application is made of one
image? Mine is affectivly multiple images. I have a DSP and two FPGAs
on the board which have code downloaded to them at startup. To do a
field upgrade you may need to upgrade all these images at once. 

My opinion is that redboot is the wrong place to do upgrades
from. Redboot is designed to be dumb. It does not have a kernel, its
not easy to add new functionality based on standard application code
etc. Field upgrades need flexiability. Maybe the image comes from
removable media, maybe it comes over the network, maybe it uses some
other communication method which is what the eCos application
provides. This cannot be done in redboot. The application has to be in
control of software upgrades because thats where we the developers
have the flexibility to implement it how we want it to work for our
specific application, customer requirements and backward compatibility
etc.

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.

In my opinion redboot has to be made FLASH safe and upgradable in the
field. This should take priority over adding new commands etc.

What do other people on the list think?

        Andrew