mkfs.jffs2 and mksum

mkfs.jffs2 and mksum

[Timo Piiroinen]

Hi,

I have done jffs2 image with --pad option to match my flash size and it 
works fine. However, if I want to use summary, the sumtool creates smaller 
image than original padded jffs2 image and the flash isn't fully used. 
I write the jffs2 image using bootloader, where I set the size of the 
flashing length match the filesize. Is there any way to pad summed 
image to larger so that i can fully occupy flash?
sumtool -p option doesn't allow to set filesize.

   Timo
   timo.piiroinen@tut.fi

Re: mkfs.jffs2 and mksum

[Artem Bityutskiy]

Hi,

On Wed, 2007-09-19 at 15:45 +0300, Timo Piiroinen wrote:
> I have done jffs2 image with --pad option to match my flash size and it 
> works fine. However, if I want to use summary, the sumtool creates smaller 
> image than original padded jffs2 image and the flash isn't fully used. 
> I write the jffs2 image using bootloader, where I set the size of the 
> flashing length match the filesize. Is there any way to pad summed 
> image to larger so that i can fully occupy flash?
> sumtool -p option doesn't allow to set filesize.

If your flash is NAND flash I do not recommend you to pad it because
writing FFs may have side-effects.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: mkfs.jffs2 and mksum

[Timo Piiroinen]

Artem Bityutskiy kirjoitti:
> Hi,
>
> On Wed, 2007-09-19 at 15:45 +0300, Timo Piiroinen wrote:
>   
>> I have done jffs2 image with --pad option to match my flash size and it 
>> works fine. However, if I want to use summary, the sumtool creates smaller 
>> image than original padded jffs2 image and the flash isn't fully used. 
>> I write the jffs2 image using bootloader, where I set the size of the 
>> flashing length match the filesize. Is there any way to pad summed 
>> image to larger so that i can fully occupy flash?
>> sumtool -p option doesn't allow to set filesize.
>>     
>
> If your flash is NAND flash I do not recommend you to pad it because
> writing FFs may have side-effects.
>
>   
Yes it is NAND flash. I tried to add dummy file to my filesystem to 
increase the size of image and after that remove that dummy file to free 
space, unfortunately I couldn't remove the file cause the filesystem was 
100% full,
and that's the real problem.

Re: mkfs.jffs2 and mksum

[Artem Bityutskiy]

On Wed, 2007-09-19 at 17:03 +0300, Timo Piiroinen wrote:
> Yes it is NAND flash. I tried to add dummy file to my filesystem to 
> increase the size of image and after that remove that dummy file to free 
> space, unfortunately I couldn't remove the file cause the filesystem was 
> 100% full,
> and that's the real problem.

Just do not pad FS image at all. You do not have to. Just leave the rest
of the flash to contain all 0xFF, i.e., erase it before flashing.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: mkfs.jffs2 and mksum

[Timo Piiroinen]

Artem Bityutskiy kirjoitti:
> On Wed, 2007-09-19 at 17:03 +0300, Timo Piiroinen wrote:
>   
>> Yes it is NAND flash. I tried to add dummy file to my filesystem to 
>> increase the size of image and after that remove that dummy file to free 
>> space, unfortunately I couldn't remove the file cause the filesystem was 
>> 100% full,
>> and that's the real problem.
>>     
>
> Just do not pad FS image at all. You do not have to. Just leave the rest
> of the flash to contain all 0xFF, i.e., erase it before flashing.
>
>   
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.

Re: mkfs.jffs2 and mksum

[Artem Bityutskiy]

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.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: 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 :)

Re: mkfs.jffs2 and mksum

[Ricard Wanderlof]

On Wed, 19 Sep 2007, Timo Piiroinen wrote:

> 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 :)

When creating an image for NAND flash, you normally don't want 
cleanmarkers in the image, as the cleanmarkers end up in the OOB anyway 
(which is not part of the image). Do this by specifying --no-cleanmarkers 
to mkfs.jffs2.

/Ricard
--
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: mkfs.jffs2 and mksum

[Artem Bityutskiy]

On Wed, 2007-09-19 at 23:12 +0200, Ricard Wanderlof wrote:
> When creating an image for NAND flash, you normally don't want 
> cleanmarkers in the image, as the cleanmarkers end up in the OOB anyway 
> (which is not part of the image). Do this by specifying --no-cleanmarkers 
> to mkfs.jffs2.

Oh my, right, I missed this, yeah.


-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

About MLC Nand Driver

[Yongsheng Liu]

 
Dear all,

I was planing to get kernel supporting MLC Nand Flash. Any one of you
guys has known something about this? Or is there anyone else planing
this as well? Please give me comments on this, any comments will be
appreciated.

Best Regards
YS Lau

Re: About MLC Nand Driver

[falls huang]

Hello ysliu !

   I have successfully run Samsung's MLC nand flash in my linux board
with yaffs2/mtd , but the performance is low because the nand flash
driver that I wrote didn't support  two-plane page program .   You can
search this mailing list ,I have asked the tow-plane page program
problem several months ago.

  Besides yaffs2/mtd ,  you can alse purchase the samsung's RFS(Robust
Nandflash filesystem) , RFS supports MLC  and its performance is
excellect ( I heard from the samsung's guy but I never use RFS) .
  At last, why do u need to support a bare MLC nand flash chip?  for
BOM price ? You can just use a SD card in your product, it's simple
but the BOM will raise.

On 9/20/07, Yongsheng Liu <ysliu@sirf.com> wrote:
>
> Dear all,
>
> I was planing to get kernel supporting MLC Nand Flash. Any one of you
> guys has known something about this? Or is there anyone else planing
> this as well? Please give me comments on this, any comments will be
> appreciated.
>
> Best Regards
> YS Lau
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>


-- 
Regards
Falls Huang