public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Claudio Lanconelli <lanconelli.claudio@eptar.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: FAT vs jFFS2 for NAND.
Date: Wed, 21 Jun 2006 20:19:00 +0200	[thread overview]
Message-ID: <1150913940.25491.16.camel@localhost.localdomain> (raw)
In-Reply-To: <44995486.6060000@eptar.com>

Claudio,

On Wed, 2006-06-21 at 16:15 +0200, Claudio Lanconelli wrote:
> 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."

ok

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

No, this was just from the top of my head.

> 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?

Well, if you use the device with SmartMedia FAT you probably want to
enable this switch and use the default configuration. I removed that
client supplied ECC scheme setting, as it turned out to be a complete
nightmare.

	tglx

      reply	other threads:[~2006-06-21 18:17 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
2006-06-21 18:19                       ` Thomas Gleixner [this message]

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=1150913940.25491.16.camel@localhost.localdomain \
    --to=tglx@linutronix.de \
    --cc=lanconelli.claudio@eptar.com \
    --cc=linux-mtd@lists.infradead.org \
    /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