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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox