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
next prev parent 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.