This is the mail archive of the
mailing list for the eCos project.
AW: AW: contributing a failsafe update meachanism for FIS from within ecos applications
- From: "Neundorf, Alexander" <Alexander dot Neundorf at jenoptik dot com>
- To: "Slawek" <sgp at telsatgp dot com dot pl>, "Andrew Lunn" <andrew at lunn dot ch>
- Cc: <ecos-devel at sources dot redhat dot com>
- Date: Mon, 25 Oct 2004 10:07:47 +0200
- Subject: AW: AW: contributing a failsafe update meachanism for FIS from within ecos applications
> Von: Slawek [mailto:firstname.lastname@example.org]
> In message to "Andrew Lunn" <email@example.com> sent Wed, 20 Oct
> 2004 18:11:18
> +0200 you wrote:
> NA> #define EFIS_VALID (0xa5a5)
> NA> #define EFIS_IN_PROGRESS (0xfdfd)
> NA> #define EFIS_EMPTY (0xffff)
> Some additional ideas from somebody who watches the conversation:
> 1) Why do we need EFIS_IN_PROGRESS? Isn't EFIS_EMPTY enough?
> Both can't be used to load the application anyway.
Hmmm, ok. With IN_PROGRESS differing from 0xffff it is possible to decide whether the writing process has already started. Ok, this doesn't help that much...
> 2) ".FisValid" suggest this is valid FIS entry while it
> doesn't need to be.
> Why don't use separate name for valid and for invalid (empty
> or in progress)
> fis tables? This could also save additional space used to mark
> "valid/invalid" as this could be decided be the name.
At the moment ".FisValid" is read from the fis table it is considered to be valid.
This can't be used to separate valid and invalid since the change from ".Invalid" to ".Valid" would need an extra erase operation in between, which would kill the purpose of this whole thing.
Andrew: in your patch you removed the magic_name field from the valid_info struct. While this works, it requires quite a lot more typing:
struct fis_image_desc* img0=(struct fis_image_desc*)buf0;
struct fis_image_desc* img1=(struct fis_image_desc*)buf1;
struct fis_valid_info* fvi0
struct fis_valid_info* fvi1
struct fis_valid_info* fvi0 =(struct fis_valid_info*)buf0;
struct fis_valid_info* fvi1 =(struct fis_valid_info*)buf1;
which IMHO makes it much easier to mix things up and introduce bugs, while it doesn't help against the padding/alignment problem (AFAIK).
This doesn't only apply to the redboot code, but even more to the fisfs implementation, there this has to be done more often.
So I'd like to modify this structure like this:
#define CYG_REDBOOT_VALID_MAGIC ".FisValid"
#define CYG_REDBOOT_VALID_MAGIC_LENGTH 10
#define CYG_REDBOOT_RFIS_VALID 0xa5
//maybe get rid of one of both:
#define CYG_REDBOOT_RFIS_IN_PROGRESS 0xfd
#define CYG_REDBOOT_RFIS_EMPTY 0xff
unsigned char valid_flag1;
unsigned char valid_flag2
unsigned long version_count:
Still the size can be checked with
CYG_ASSERT(sizeof(struct fis_valid_info) <=sizeof(struct fis_image_desc), "size mismatch");
What do you think ?