All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthieu CASTET <matthieu.castet@parrot.com>
To: 曹荣荣 <caorr1980@gmail.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: question about write/read sub-page with BCH algorithm or disable sub-page operation when using ubifs
Date: Tue, 31 Jul 2012 09:37:57 +0200	[thread overview]
Message-ID: <50178B55.1020005@parrot.com> (raw)
In-Reply-To: <CAGHPBZooQbfpB3ASw51g7CD44Bq5bgXqceXd7q+NOrqgM0EoYw@mail.gmail.com>


Hi,
> Hello,
> I have a question about sub-page when using ubifs, so ask help from here.
> 
> Let me take a 2048-size page with 4 sub-page Nand as example.
> 
> The documentation said, "To write a sub-page, the driver may actually
> write whole NAND page, but put 0xFF bytes to the sub-pages which are
> not relevant to this operation."
> It's OK for some ECC algorithms such as Hamming algorithm, because the
> ECC codes generated by Hamming algorithm for the 0xFF data are still
> 0xFF'ed. However, if we use BCH algorithm, the generated ECC codes for
> 0xFF data will be not 0xFF'ed, and they will overwrite the previous
> OOB data, so error will be happened when reading next time.
It depends of your ecc algorithm. The software BCH algo in kernel take care of
generate code such as 0xFF data give 0xFF ecc.

This can be done by XORing the ecc before writing/after reading.

This may not possible on some controller that compute and send ecc without
software intervention.


> 
> I try to resolve this issue by disabling sub-page operation, so I add
> NAND_NO_SUBPAGE_WRITE into chip->options, but chip->options will be
> flushed in nand_get_flash_type() funtion (chip->options &=
> ~NAND_CHIPOPTIONS_MSK).

You may better define chip->ecc.steps == 1

Matthieu

  reply	other threads:[~2012-07-31  7:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-31  7:23 question about write/read sub-page with BCH algorithm or disable sub-page operation when using ubifs 曹荣荣
2012-07-31  7:37 ` Matthieu CASTET [this message]
2012-07-31  7:52   ` 曹荣荣
2012-08-01  5:20 ` Iwo Mergler

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=50178B55.1020005@parrot.com \
    --to=matthieu.castet@parrot.com \
    --cc=caorr1980@gmail.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 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.