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

["Neundorf, Alexander" <Alexander dot Neundorf at jenoptik dot com>]

Hi,

> Von: Andrew Lunn [mailto:andrew@lunn.ch]
> 
...
> Anything that deals with the layout of the FIS directory in flash
> should be handled by redboot.
...
 
> For opendir() and readdir() you need to add a way to enumerate the
> names of images in the FIS. Once you have the names the rest is easy.

For this I'd like to add a function which simply returns a pointer to the current valid fis table. Then this can be iterated (and modified) in "userspace".

In my current fisfs I have startUpdateDirectory(), which 
-for "old" fis: does nothing
-for "new" fis: writes the modified fis table to the flash but marked as in progress

and finishUpdateDirectory() which
-for "old" fis: writes the modified fis table to the flash
-for "new" fis: markes the already written fis table as valid


So the modification process would be as follows:

-application: modify the fis table in RAM (including addresses and crc)
-redboot: startUpdateDirectory()
-application: write/erase the image on flash
-redboot: finishUpdateDirectory()

> The CRC over the image is a bit tricky. You probably need to add VV
> calls to recalculate the CRC over an image, and to test the CRC over
> an image. When a file that which has been opened for writing is
> closed, you call the recalculate function followed by commit so that
> the CRC in FLASH in the FIS directory matches the image. When open is
> called, you first call the crc check function, and if the CRC fails
> you only allow the file to be open with O_TRUNC so effectively erasing
> the corrupt content.

I didn't plan to open files for writing. They can only be opened for reading, and additionally there is a set of functions (eraseImage(), createImage()) which can modify the contents of the fis. If any file is opened when one of these functions is called, it returns with an error. IMO the fisfs shouldn't try to act like a real RW file system, for this we have jffs2, but like an RO file system, accompanied by some utility functions to update the contents of this RO filesystem.
 
> creat is interesting. How do you control the size and location? The

The mentioned special createImage() call, same for erasing.

> standard filesystem API has no concept of the application specifing
> where a file should be placed on the storage medium and how big the
> maximum size of the file can be. Probably the easiest solution is to
> simply not allow creat. And if you don't have creat then erase is
> probably no use either. You have to create and erase the files using
> RedBoots CLI where you can specify all these parameters. The other
> option is to use cyg_set_config() on the filesystem to do a create,
> passing the maximum size of the image, entry point etc, and letting
> redboot find a space in the flash to put it. But there are all sorts
> of horrible fragmentation issues to worry about.

Yes, I really want to avoid this under all circumstances and that's why leave it to the user to give a start address and length to the createImage() function. This function then only checks that the given addresses don't overlap existing images.
 
> reading and writing can all be done outside of redboot. You need to
> think about how to handle flash blocks. You probably need a block
> cache where you cache your writes until you have a full flash block
> which you can then erase and write. seeking off the end of the
> allocated space will not be allowed.

Simply calling flash_write() on the complete image buffer works without problems for me so far. As I mentioned, there's no real write() function, only a createImage() function.
 
> mount is nearly a NOP. All you need to do is see if the redboot

Well, actually mount() is the point where the interesting things happen, i.e. deciding which fis table to use I'd say.

Bye
Alex