From: tglx@linutronix.de (Thomas Gleixner)
To: linux-mtd@lists.infradead.org
Subject: NAND ECC and OOB usage
Date: Tue, 18 Feb 2003 17:45:16 +0100 [thread overview]
Message-ID: <200302181745.16506.tglx@linutronix.de> (raw)
In-Reply-To: <200302181517.04451.phil@river-bank.demon.co.uk>
On Tuesday 18 February 2003 16:17, Phil Thompson wrote:
> >
> > You don't need that, as the filesystem forces layout selection itself.
>
> So why hardcode it in autcpu12.c? If it's useful to be able to hardcode the
> selector then it must also be useful to parameterise it in mtdparts.
>
> But maybe it isn't useful to hardcode it either.
>
> As I understand it, the only point of including the selector in struct
> mtd_info is to provide an appropriate default when using user space tools
> that aren't aware of OOB data and ECC. In other words so that you can do...
> dd if=jffs2_image of=/dev/mtd1
You can use write and read from userspace, e.g. to burn an image on the
partition. You still have to deal with bad blocks, but you can use non NAND
specific functions for read and write.
> ...and have the OOB data initialised properly. However, because you have to
> deal with potential bad blocks, you shouldn't be using user space tools
> that aren't aware of OOB data. You should be using something like your
> enhanced nandwrite which is going to use the MEMSETOOBSEL ioctl to
> explicitly set the selector correctly anyway.
> In other words, I can't see the point in having the selector in struct
> mtd_partition at all.
1. It's the only way to set the dfault for a partition
2. It's a convenience function for ppl, which won't, forget,... to use the
MEMSETOOBSEL iotctl.
--
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de
next prev parent reply other threads:[~2003-02-18 16:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-18 13:09 NAND ECC and OOB usage Thomas Gleixner
2003-02-18 13:21 ` Phil Thompson
2003-02-18 15:19 ` Thomas Gleixner
2003-02-18 15:17 ` Phil Thompson
2003-02-18 16:45 ` Thomas Gleixner [this message]
2003-02-18 15:53 ` Phil Thompson
2003-02-18 17:20 ` 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=200302181745.16506.tglx@linutronix.de \
--to=tglx@linutronix.de \
--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