This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: AW: contributing a failsafe update meachanism for FIS from within ecos applications
- From: Alexander Neundorf <alex at neundorf dot net>
- To: ecos-devel at ecos dot sourceware dot org
- Cc: Andrew Lunn <andrew at lunn dot ch>
- Date: Thu, 28 Oct 2004 23:05:23 +0200
- Subject: Re: AW: contributing a failsafe update meachanism for FIS from within ecos applications
- References: <200410281923.58620.neundorf@kde.org> <200410282010.04689.alex@neundorf.net> <20041028192945.GQ18923@lunn.ch>
- Reply-to: 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