public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: tglx@linutronix.de (Thomas Gleixner)
To: linux-mtd@lists.infradead.org
Subject: Initialising NAND OOB with Software ECC
Date: Fri, 14 Feb 2003 12:00:50 +0100	[thread overview]
Message-ID: <200302141200.50767.tglx@linutronix.de> (raw)
In-Reply-To: <200302140946.42284.phil@river-bank.demon.co.uk>

On Friday 14 February 2003 10:46, Phil Thompson wrote:
> How do you want it implemented?
> Just a new ioctl that sets the selector for subsequent MEMWRITEDATA and
> MEMREADDATA calls?
Not a good idea.

> IMHO it would be cleaner to replace the struct mtd_oob_buf argument to
> MEMWRITEDATA and MEMREADDATA with a structure that included the selector to
> use for that operation. But that would break binary compatibility. Is this
> an option at this stage?
Yep, as it's for NAND only and as there are no tools, which are usefull, I 
think we can do this and implement it in a clean way. Then we can overhaul 
nandtest utils in mtd/utils to give an example. This should include a 
"copyImageToNAND" utility with support for other filesystems too.

My suggestion:

struct nand_ctrl {
	int	oob_select;	// selector for OOB usage
	int	data_lenght;	// length of data
	int	oob_length;	// length of oob-buffer
};
oob_length can be 0. If its not zero it must be 8 * (data_length / 256) for 
write and 12 * (data_length / 256) for read, as nand_read_ecc appends the 
ecc_status result behind each 8 byte OOB.
struct nand_oob_read {
	char	oob_data[8];
	int	ecc_status;
}

JFFS2 needs no oob buffer for write, but YAFFS does.

data_length for write should be checked, if it is a multiple of page size 
(mtd->oobblock), which is either 256 or 512 at the moment. Deny writing parts 
of pages.

David: any complaints ?

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de

  reply	other threads:[~2003-02-14 11:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-13 20:20 Initialising NAND OOB with Software ECC Phil Thompson
2003-02-14  9:05 ` Thomas Gleixner
2003-02-14  9:46   ` Phil Thompson
2003-02-14 11:00     ` Thomas Gleixner [this message]
2003-02-14 11:36       ` Phil Thompson
2003-02-14 13:02         ` Thomas Gleixner
2003-02-14 13:14           ` David Woodhouse
2003-02-14 13:27             ` Thomas Gleixner
2003-02-14 13:36               ` David Woodhouse
2003-02-14 13:50                 ` Thomas Gleixner
2003-02-14 13:56                   ` David Woodhouse
2003-02-14 14:06                     ` Thomas Gleixner
2003-02-14 14:18                     ` Phil Thompson
2003-02-14 13:25           ` Phil Thompson

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=200302141200.50767.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