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

[Andrew Lunn <andrew at lunn dot ch>]

> Ok, I'll have a look.
> What would you say needs to be transferred to redboot ?
> For implementing an ecos fisfs I need a bunch of functions.
> open(), read(), close(), opendir(), readdir() are more or less trivial I'd say and transferring these functions to redboot wouldn't make much sense.
> 
> I guess what would make sense would be at least the mount() (i.e. finding the valid fis table and returning a pointer to it) call, and probably the eraseImage() and createImage() functions.
> What do you think ?

Anything that deals with the layout of the FIS directory in flash
should be handled by redboot.

The current VV functions take a name of a image in the directory. You
can then get the base, size, memory base, entry point and the data
length. You will probably need to add a rename VV function so you can
change the name of a file. This just changes the im memory copy of the
FIS directory. You then need a commit function which writes the in
memory image to flash, ie calls fis_update_directory(). For systems
without the redundant block the current functionality of
fis_update_directory() is probably all that is needed. For systems
with the redundant block you need to add all the inteligence into
fis_update_directory(), but you can do that later, once you have the
basic filesystem working.

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.

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.

creat is interesting. How do you control the size and location? The
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.

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.

mount is nearly a NOP. All you need to do is see if the redboot
actually supports what you need. umount is probably also a NOP.

        Andrew