This is the mail archive of the ecos-devel@sources.redhat.com 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]

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


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

But what about people who want to add this to an existing project and
there only free blocks in flash are somewhere else.

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

Not good. If its deleted how is it put back again? Do you have to fis
init so deleting all the existing entries? I hope not.

> 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 ?

It could happen very easily. Somebody might download the existing
redboot images from ecos.sourceware.org and use that. Somebody might
forget to enable this failsafe mode when they rebuild redboot and so
get an "old" image. There might be a redboot RAM image in FLASH which
does not understand the new entry...... If it can happen, it will
happen.

I would think about trying to use the existing format so that it
remains backward compatible. I think about add a dummy image to the
fis list. Dummy in that it start and length are 0. But the name would
be something like. "Fis Valid*" The sting is 16 charactors long. So
there are 5 unused charactors after the \0. You could put your magic
numbers there. This will probably be backward compatible with old
redboots. They will just see it as a normal entry with some junk after
the end of the string. Where i showed "*" in the sting, if you think
carefully about ASCII and the binary representation, you might be able
to come up with a set of charactors which differ by resetting 1's to
give some sort of meaningful mapping to the state of the FIS
directory.

        Andrew


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