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

[Alexander Neundorf <alex at neundorf dot net>]

On Thursday 28 October 2004 21:29, Andrew Lunn wrote:
> > createImage() does: create a new entry, writes the data, marks the new
> > entry as valid.
> >
> > It consists of the following steps:
> > startUpdate  (redboot) - modify the fis table contents in RAM and flash,
> > mark them in progress
> > writeData    (app) - either all at once, or in flash block sized chunks
> > finishUpdate (redboot) - mark the new fis table as valid in flash
>
> So the first step maps to open()
> The second step to write()
> and the third set to close().

Yes, I realized this too in the meantime.
(*) It seems the only remaining problem is how to give the additional 
paramters (flash_base, entry_point etc.) to the open call. I'd say a special 
function which takes all these parameters (i.e. not the standard open()), 
better ideas ?

For transferring the parameters from the application API to the redboot VV I'd 
suggest a struct like this which can easily be translated to fis_image_desc:

struct fis_image_desc_VV {
    unsigned char name[16];      // Null terminated name
    CYG_ADDRESS   flash_base;    // Address within FLASH of image
    CYG_ADDRESS   mem_base;      // Address in memory where it executes
    unsigned long size;          // Length of image
    CYG_ADDRESS   entry_point;   // Execution entry point
    unsigned long data_length;   // Length of actual data
//maybe:
    unsigned long file_cksum;    // Checksum over image data
};

which has to know all the fields required for creating a correct fis image, I 
don't see another way (except giving all parameter key-value based one by one 
to redboot, but I don't see a real difference: if a new redboot in the future 
should support additional informations, then an old application won't be able 
to supply these, no matter whether via key-value or this struct. Not being 
able to provide all parameters means not being able to provide then 
potentially essential new parameters and by this not being able to create 
correct images).

...
> > Without redundant fis:
> > startUpdate doesn't change the flash contents, the new fis table contents
> > are written in finishUpdate, so it will work too (except that power
> > failure.... well you know).
>
> The point is the user gets the choice. They can have a totaly safe
> system, or a system that works 99.9% of the time but needs one less
> flash block.

Yes. No problem there.

> > > You are again breaking the abstract. You are doing the CRC creation in
> > > the application where as it should be redboot doing it.
> >
> > My main reason for this: I'd like to have the new fis table already
> > completely correct on the flash except the valid_flag before the
> > actual writing process starts, so that the final step really only
> > has to set the valid_flag to valid.
>
> I cannot think of a reason why this is actually needed? But maybe im
> missing something.

By modifying the to-be-used flash block of the new fis table before the 
writing starts it is possible to detect whether an update process has been 
interrupted, without having to check all crc's. I.e. not only for the 
firmware image, where the crc is checked by load, but also for data images.

...
> > I would prefer an obviously different API for the updating process
> > since it is "dangerous" for the whole system.  With my createImage()
> > which writes a complete image at once there is also ensured that
> > there can be at most one corrupt image at a time. When splitting
> > open, write and close there can be more than one corrupt
> > image. open() for writing should check that there is no other file
> > open.
>
> That is not a problem. The filesystem can easily enforce this and
> return EAGAN when open() is called when another file has been open'd
> for writing.

Ok.

So it seems we have one issue left, how to transfer the parameters for a new 
image (*). Better ideas than my suggestion ?

Bye
Alex
-- 
Work: alexander.neundorf@jenoptik.com - http://www.jenoptik-los.de
Home: neundorf@kde.org                - http://www.kde.org
      alex@neundorf.net               - http://www.neundorf.net