This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

> -----Ursprüngliche Nachricht-----
> Von: Andrew Lunn []
> Gesendet: Montag, 18. Oktober 2004 14:53
> An: Neundorf, Alexander
> Cc:
> Betreff: Re: contributing a failsafe update meachanism for FIS from
> within ecos applications
> On Mon, Oct 18, 2004 at 02:25:53PM +0200, Neundorf, Alexander wrote:
> > Any technical comments ?
> You need to make some of the code conditionally compiled on CDL. ie by
> default there is no valid marker, only one flash block is used etc. 

> You should have CDL to control where the second flash block is. Its
> bad to assume its the next block. 

Really ?
IMO it would be ok if the blocks are directly one after the other. One could think of it as a fis dir twice as big as before containing two copies of this fis dir.
> What happens when an old redboot reads the fis directory of a new
> redboot with these valid/invalid entry? 

If a new redboot reads an old fis dir everything should be ok. If not, then I've overlooked something.

If an old redboot reads a new fis dir there will be some problems.
The "valid marker" entry will be considered empty. 
So it won't show up on "fis list". Since it doesn't allocate space in the flash, the space allocation algorithm will work correctly. There will be a problem with "fis create" when an empty entry in the fis table is searched, the "valid marker" entry might be overwritten.
But how can this happen ? A new fis dir can only be created using a new redboot. Why should after a new fis dir has been created using a new redboot an old redboot run on this flash ?

> Does the entry show up on the fis list? 

No, it's hidden. Should it be visible ?

> Does it have a sensible name?

Since it's hidden it currently doesn't have a name. With my current approach a name is slightly complicated, since I use the first bytes of the name for the valid marker.
Maybe I could change the "magic number" from "0xff1234ff" to "$VALID0\0" and "$VALID1\0".
This would still leave room for 2 integers (valid_flag and version_count) and be even more compatible with the current redboot. It would be listed by fis list, not overwritten by an old redboot, and via the last digit you could even recognize which one is currently active. OTOH this would make it impossible to use "$VALID[01]" for "normal" fis images (which might exist right now, at least theoretically).

> Is there any way to see if its valid/invalid etc.

What do you suggest ?
This mean adding commands to fis. Until now I wanted to avoid this and stay completely compatible on the outside. 
> At the moment you seemed to of focused on the mechanics of how you
> boot/update reliably. Thats the easy part. 
> You now need to see how it fits into the rest of redboot and eCos. 
> Hopefully some of the
> questions i asked above with get you started in that direction.

Yes, that's why I asked. What I need is that we reach a consensus on the layout of the data on the flash.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]