All of lore.kernel.org
 help / color / mirror / Atom feed
From: Claudio Lanconelli <lanconelli.claudio@eptar.com>
To: tglx@linutronix.de
Cc: linux-mtd@lists.infradead.org
Subject: Re: FAT vs jFFS2 for NAND.
Date: Wed, 21 Jun 2006 16:15:34 +0200	[thread overview]
Message-ID: <44995486.6060000@eptar.com> (raw)
In-Reply-To: <1150825284.6780.270.camel@localhost.localdomain>

Hi Thomas,

Thomas Gleixner wrote:
> This looks up the bad block table which is created in ram after the NAND
> chip has been detected in nand_scan() and helps you to avoid reading bad
> blocks. Just skip the block, when the function returns 1.
>
> The only exception I think is block 0, which contains the SSFDC header
> and is marked bad for protection.
>
>   
Are you sure about block 0 marked bad for protection? I read in
smartmedia specification by Toshiba that SSFDC header called CIS/IDI is
located on the first good block. Here the sentence:

"The CIS/IDI Field is placed in physical block 0.
If physical block 0 is found to be a defective block, the area is placed 
in the
first normal block that is found after physical block 0.
Irrespective of the page size, only one block is assigned."
[...]
"The indication of a defective block and logical block arrangement in 
the data
area will be set in the redundancy area.
In the case of the 512+16 bytes/page models, the 6th byte (byte address 
517th)
in all pages in the redundant section contains two or more “0” bits to 
indicate
a defective block."

My code follow these instructions on the SSFDC header location, is it 
correct?
Anyone who knows it for sure?


Another question about the ECC placement. I think the MTD default ECC 
bytes placement
in the redundant area is not suitable for SSFDC. I found the 
CONFIG_MTD_NAND_ECC_SMC
in mtd configuration, but it's not used anywhere in the code. How can 
the ssfdc_ro layer tell
to use smartmedia ECC bytes placement?

Thanks,
Claudio

  reply	other threads:[~2006-06-21 14:23 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-28  2:58 FAT vs jFFS2 for NAND Han Chang
2006-05-28  5:54 ` Charles Manning
2006-06-15  0:34   ` Han Chang
2006-06-15  7:53     ` Thomas Gleixner
2006-06-19 18:31       ` Han Chang
2006-06-19 18:38         ` Thomas Gleixner
2006-06-19 20:23         ` David Woodhouse
2006-06-19 21:10           ` Charles Manning
2006-06-20 11:31         ` Claudio Lanconelli
2006-06-20 12:30           ` David Woodhouse
2006-06-20 13:25             ` Claudio Lanconelli
2006-06-20 13:52               ` Thomas Gleixner
2006-06-20 17:26                 ` Claudio Lanconelli
2006-06-20 17:41                   ` Thomas Gleixner
2006-06-21 14:15                     ` Claudio Lanconelli [this message]
2006-06-21 18:19                       ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44995486.6060000@eptar.com \
    --to=lanconelli.claudio@eptar.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.