Re: AW: contributing a failsafe update meachanism for FIS from within ecos applications

[Andrew Lunn <andrew at lunn dot ch>]

On Fri, Oct 29, 2004 at 12:43:55PM +0200, Neundorf, Alexander wrote:
> 
> ...
> > > IMO this is the same what we are doing here. I really would want to
> > > make sure that the application which wants to write a new firmware
> > > image knows with which "interface version" of redboot it is working,
> > > and uses this interface correctly instead of relying on unknown
> > > default parameters.
> > 
> > Well, add a version VV. If the application finds reboot is running a
> > different version of the interface than what the application supports
> > it can then decide if it wants to accept the defaults, or simply abort
> > the upgrade.
> > 
> >         Andrew
> 
> Ok, how about something like this:
> 
> struct item
> {
>    int key;
>    void* value;
> };

Why do you need the key? Surely you know what is being passed to each
VV call. 

> int do_something_VV(int operation, int item_count, struct item* list_of_items); ?

O, I C. You want to do complex list manipulation rather than simply do
lots of calls. KISS.

> One VV for: 
> -version
> -number of images
> -erase entry
> -create
> -create with backup, maybe also just as a parameter to the one above

I still don't see why you need this. Its just added complexity. 

> -changesDone  (close)
> -get all fields for image i  (stat)

Stat only needs one field, the length. There is already a VV call to
return this. Might as well use it rather than add something new.

You seem to be missing

set length
set entry point
set flash_base

which you need to call after doing a create. Plus

check crc
calculate crc

        Andrew