NAND ECC and OOB usage

NAND ECC and OOB usage

[Thomas Gleixner]

I have changed the oob-selection for NAND as follows:

1. A default oob selector is added to the mtd structure. It can be initialized 
on compile time or modified on runtime. For partitioned devices a default 
selector is included in the partition description structure. This can be set
on compile time (see autcpu12.c) or on runtime.

The runtime setting is done via ioctl (fd, MEMSETOOBSEL, &newsel), where
newsel is an integer containing your chosen select type.

Not that MEMREADDATA and MEMWRITEDATA are not longer available,
as they are obsolete now.

2. If read or write access occur from userspace the default obb-selector for 
the partition / chip is used. You can still set it to NAND_OOB_NONE, if you 
do not want to do ECC from userspace. This makes only sense if you copy a
fs-image with full oob-data including ECC to the chip.

3. Filesystem layers do not longer give the constants NAND_FS_OOB to the
read/write functions. They have to provide a pointer to an integer variable,
which conains the constant. JFFS2 is changed already. A YAFFS-patch is on the 
way.
__________________________________________________________________
I have added formatting capability to mtd-utils "eraseall". eraseall -j 
/dev/mtdx will erase the chip / partition and write the cleanmarkers to it. 
This works for NOR too.
__________________________________________________________________
In mtd-utils is a overhauled nandwrite, which lets you copy a fs-image bad 
block aware to your formatted partition.
nandwrite -j /dev/mtdX image
The -j option sets the default oob-selector of this partition to 
NAND_JFFS2_OOB. Bad blocks are skipped.

There is also an option for YAFFS layout. The commandline should be
nandwrite -y -o /dev/mtdx image
This will write oob data too and place the ECC into the yaffs places.
Your image should have the ECC-Data set to 0xff for this purpose.

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

NAND ECC and OOB usage

[Phil Thompson]

On Tuesday 18 February 2003 1:09 pm, Thomas Gleixner wrote:
> I have changed the oob-selection for NAND as follows:
>
> 1. A default oob selector is added to the mtd structure. It can be
> initialized on compile time or modified on runtime. For partitioned devices
> a default selector is included in the partition description structure. This
> can be set on compile time (see autcpu12.c) or on runtime.

This means we really need to be able to specify the selector on the command 
line as part of mtdparts as well.

Anybody got any recommendations on the syntax? The current syntax isn't 
obviously extensible without introducing another delimiter.

How about...

<partdef> := <size>[@offset][<name>][<option-list>]
<option-list> := <option>['+' <option-list>]
<option> := [ro | oobnone | oobjffs2 | oobyaffs]

Phil

NAND ECC and OOB usage

[Phil Thompson]

On Tuesday 18 February 2003 3:19 pm, Thomas Gleixner wrote:
> On Tuesday 18 February 2003 14:21, Phil Thompson wrote:
> > On Tuesday 18 February 2003 1:09 pm, Thomas Gleixner wrote:
> > > I have changed the oob-selection for NAND as follows:
> > >
> > > 1. A default oob selector is added to the mtd structure. It can be
> > > initialized on compile time or modified on runtime. For partitioned
> > > devices a default selector is included in the partition description
> > > structure. This can be set on compile time (see autcpu12.c) or on
> > > runtime.
> >
> > This means we really need to be able to specify the selector on the
> > command line as part of mtdparts as well.
>
> 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

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

Phil

NAND ECC and OOB usage

[Thomas Gleixner]

On Tuesday 18 February 2003 14:21, Phil Thompson wrote:
> On Tuesday 18 February 2003 1:09 pm, Thomas Gleixner wrote:
> > I have changed the oob-selection for NAND as follows:
> >
> > 1. A default oob selector is added to the mtd structure. It can be
> > initialized on compile time or modified on runtime. For partitioned
> > devices a default selector is included in the partition description
> > structure. This can be set on compile time (see autcpu12.c) or on
> > runtime.
> This means we really need to be able to specify the selector on the command
> line as part of mtdparts as well.
You don't need that, as the filesystem forces layout selection itself.

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

NAND ECC and OOB usage

[Phil Thompson]

On Tuesday 18 February 2003 4:45 pm, Thomas Gleixner wrote:
> 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.

Understood.

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

In which case my original point is valid - you should also be able to set the 
default through mtdparts.

Phil

NAND ECC and OOB usage

[Thomas Gleixner]

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

NAND ECC and OOB usage

[Thomas Gleixner]

On Tuesday 18 February 2003 16:53, Phil Thompson wrote:
> > 1. It's the only way to set the dfault for a partition

> In which case my original point is valid - you should also be able to set
> the default through mtdparts.
Good point. 
But please stop before implementing. I'm going to change the whole thing 
again, as I was slightly brain-damaged when I implemented it this way.
I will go back to the original path and make a pointer, which let's 
filesystems do what they need, without changing NAND code anymore.

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