mkfs.jffs2 and mksum

[Timo Piiroinen]

Artem Bityutskiy kirjoitti:
> On Wed, 2007-09-19 at 17:24 +0300, Timo Piiroinen wrote:
>   
>> I use the redboot bootloader to flash image (using fis create), if I 
>> flash with lenght parameter same as image size it won't work, cause 
>> after that there is mtd/2 which is length of image and mtd/3 which 
>> contains rest of free flash (and I want mtd/2 to use all available flash).
>> I'll try to create image using legth of free flash and write rest of it 
>> after jffs2 image (unused part) with 0xFF.
>>     
>
> I never used redboot so I cannot help here, may be others.
>
> But what I just want to inform you about pitfalls you may hit.
>
> When you flash a padded image, you basically write 0xFFs to unused
> space. Writing 0xFFs may have side-effects - e.g., ECC of all 0xFF bytes
> may by 0x0 (I saw this in practice). It will be stored in OOB and the
> NAND page won't be re-writable. E.g., JFFS2 may think: "oh cool, I have
> empty flash space here (all 0xFF bytes), I'll write my data there". But
> it ends up with an error.
>
> You may argue that in your case ECC of 0xFFs is 0xFFFFFFFF, but anyway,
> data sheets usually say that you may do only one write per NAND page (or
> sub-page), and you've already done one when wrote 0xFFs, and it _might_
> cause some problems, side-effects, or heisenbugs.
>
> I'm not sure how mkfs.jffs2 pads - whether it writes clean markers to
> beginnings of padded eraseblocks or not. If yes, you may hit the
> problems described above. If not, it is fine, JFFS2 will re-erase them
> on the first mount.
>
> But there is the last eraseblock of the image which may be partially
> filled. JFFS2 interprets the 0xFFed part of it as empty space and this
> may cause problems described above.
>
> Just beware of this. Depending on the system, this might not be relevant
> for you, but you might want to play safe.
>
> So one thing to do is to flash exactly the amount of NAND pages the FS
> image contains, not more. And erase the flash beforehand.
>
> The other thing to do is to check/teach the program which flashes data
> (redboot?) and make sure it just skips NAND pages containing all 0xFFs
> if they span up to the end of the eraseblock.
>
> HTH.
>
>   
I think jffs2 writes cleanmarkers to padded space, but I'm not sure what 
happens in sumtool with padded space because the padded space is lost. 
It sounds that it's possible get in touble with padding, if writing 0xFF 
into empy space, if it may cause "unstable bits" or somethink like that. 
Well, I'm not sure if I want to use padding anymore :)