From: Jon Povey <Jon.Povey@racelogic.co.uk>
To: Mike Frysinger <vapier.adi@gmail.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: RE: linux equivalent of u-boot's "nand scrub" (erasing blocks even whenOOB says "bad")
Date: Tue, 14 Sep 2010 02:53:18 +0100 [thread overview]
Message-ID: <70E876B0EA86DD4BAF101844BC814DFE0903E3E5A5@Cloud.RL.local> (raw)
In-Reply-To: <AANLkTim=Fi_-kwaHSpF1OXMVv79xugnigMK7=bzQmE=s@mail.gmail.com>
Mike Frysinger wrote:
> i dont have any devices that have dedicated software BBTs. i'm
> concerned with just the forced erasing of blocks since the rest works
> for me already (forced reading and writing). the ability to change
> the definition of the OOB is apparently "deprecated" now, so i cant
> fix things on the fly there.
Not quite sure what you mean by the last part. I have used raw writes with OOB, software-generated ECC and altered layout of flash pages, to good effect.
I'm don't know what's deprecated, although the kind of hackery I am doing I wouldn't expect to be encouraged by the API. I do, however, appreciate when such things are possible. Especially on embedded, I don't want a kernel API thinking it knows best about, f.ex., allowing me to erase and rewrite the BBT. Stopping me doing it by accident is fine. Making it impossible is a pain.
--
Jon Povey
jon.povey@racelogic.co.uk
Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .
The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network
next prev parent reply other threads:[~2010-09-14 1:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-10 23:53 linux equivalent of u-boot's "nand scrub" (erasing blocks even when OOB says "bad") Mike Frysinger
2010-09-11 6:32 ` Artem Bityutskiy
2010-09-12 4:03 ` Mike Frysinger
2010-09-12 7:54 ` Artem Bityutskiy
2010-09-22 7:43 ` Mike Frysinger
2010-09-23 12:28 ` Artem Bityutskiy
2010-09-23 19:55 ` Mike Frysinger
2010-09-24 8:47 ` Artem Bityutskiy
2010-09-13 5:54 ` linux equivalent of u-boot's "nand scrub" (erasing blocks even whenOOB " Jon Povey
2010-09-13 6:25 ` Artem Bityutskiy
2010-09-14 1:16 ` Mike Frysinger
2010-09-14 1:53 ` Jon Povey [this message]
2010-09-14 1:59 ` Mike Frysinger
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=70E876B0EA86DD4BAF101844BC814DFE0903E3E5A5@Cloud.RL.local \
--to=jon.povey@racelogic.co.uk \
--cc=linux-mtd@lists.infradead.org \
--cc=vapier.adi@gmail.com \
/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.