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

[Andrew Lunn <andrew at lunn dot ch>]

On Thu, Oct 28, 2004 at 11:05:23PM +0200, Alexander Neundorf wrote:
> 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 ?

OK. There are two different operations here. There is creat() and
there is open(path,flags) where flag != O_CREAT. You only need
something special when you actually need to create a FIS entry. Just
opening an existing file entry is not a problem.

Now creat() is tricky. You don't know enough in the application to
reliably create new entries. Using the filesystem metaphore you don't
know where files are stored on the storage medium. So how can you pick
the empty space? Maybe somebody has used the serial port and added a
new FIS entry which your application does not know about? You then
create the new one right in the middle? The only simple way around
this is to ask redboot to allocate the space. You set the data_length
field and then ask redboot to find an empty location big enough. This
might work, or it might not. And when it does not, you are in
trouble. So i think create is fundementaly unreliable unless its done
from the redboot prompt by a human.

Now having said that, if i were to implement create, which i would
not, i would implement the creation of a FIS entry using
cyg_io_set_config(). I suggest you read the source code and work out
how that works. (This is one place you can pass a structure, since its
internal to the application.)

> 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
> };
> 

No, no, no...

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

OK. How do you know when the applicaton and redboot are using the same
version of the structure? 

By having individual setters you don't have this problem. You have one
VV which does "create a new FIS entry which name XYZ, and set the
other parameters to default values". You then have a number of VV
functions that allow you to set the other parameters one by one. If
somebody were to add a new parameter, no problem, it uses the default
value if the application does not set it. Once the application has set
everything it wants to set, it then calls the commit VV which actuall
writes it to FLASH.

        Andrew

P.S.
        Im on Holiday for the next week.....