* change in how ubiformat works
@ 2010-11-12 18:47 twebb
2010-11-26 15:56 ` Artem Bityutskiy
2010-11-26 16:03 ` Artem Bityutskiy
0 siblings, 2 replies; 3+ messages in thread
From: twebb @ 2010-11-12 18:47 UTC (permalink / raw)
To: linux-mtd
I use a sequence as follows: " flash_erase - ubiformat - nanddump -
verify " to confirm that a UBI image was properly stored in NAND
flash. I realize that flash_erase is not recommended because it
destroys erase counters, but this is only done on virgin flash so
should not be an issue.
However, I recently upgraded the mtd-utils, and particularly ubiformat
from 1.4 to 1.5, and now I see that what I read back (via nanddump)
does not match the original UBI image. Can anyone confirm whether
ubiformat.c changes sometime between 1.4 and 1.5 would result in this
behavior? I have looked at ubiformat.c changes and am wondering if it
has to do with image sequence number support.
Thanks,
twebb
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: change in how ubiformat works
2010-11-12 18:47 change in how ubiformat works twebb
@ 2010-11-26 15:56 ` Artem Bityutskiy
2010-11-26 16:03 ` Artem Bityutskiy
1 sibling, 0 replies; 3+ messages in thread
From: Artem Bityutskiy @ 2010-11-26 15:56 UTC (permalink / raw)
To: twebb; +Cc: linux-mtd
On Fri, 2010-11-12 at 13:47 -0500, twebb wrote:
> I use a sequence as follows: " flash_erase - ubiformat - nanddump -
> verify " to confirm that a UBI image was properly stored in NAND
> flash. I realize that flash_erase is not recommended because it
> destroys erase counters, but this is only done on virgin flash so
> should not be an issue.
>
> However, I recently upgraded the mtd-utils, and particularly ubiformat
> from 1.4 to 1.5, and now I see that what I read back (via nanddump)
> does not match the original UBI image. Can anyone confirm whether
> ubiformat.c changes sometime between 1.4 and 1.5 would result in this
> behavior? I have looked at ubiformat.c changes and am wondering if it
> has to do with image sequence number support.
Try to bisect it and find the commit id which changed the behavior.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: change in how ubiformat works
2010-11-12 18:47 change in how ubiformat works twebb
2010-11-26 15:56 ` Artem Bityutskiy
@ 2010-11-26 16:03 ` Artem Bityutskiy
1 sibling, 0 replies; 3+ messages in thread
From: Artem Bityutskiy @ 2010-11-26 16:03 UTC (permalink / raw)
To: twebb; +Cc: linux-mtd
On Fri, 2010-11-12 at 13:47 -0500, twebb wrote:
> I use a sequence as follows: " flash_erase - ubiformat - nanddump -
> verify " to confirm that a UBI image was properly stored in NAND
> flash. I realize that flash_erase is not recommended because it
> destroys erase counters, but this is only done on virgin flash so
> should not be an issue.
>
> However, I recently upgraded the mtd-utils, and particularly ubiformat
> from 1.4 to 1.5, and now I see that what I read back (via nanddump)
> does not match the original UBI image. Can anyone confirm whether
> ubiformat.c changes sometime between 1.4 and 1.5 would result in this
> behavior? I have looked at ubiformat.c changes and am wondering if it
> has to do with image sequence number support.
Ok, just define your own sequence number. Use, say, --image-seq=100 both
with ubinize and ubiformat.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-11-26 16:04 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-11-12 18:47 change in how ubiformat works twebb
2010-11-26 15:56 ` Artem Bityutskiy
2010-11-26 16:03 ` Artem Bityutskiy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).