NAND ECC and OOB usage

Thomas Gleixner tglx at
Tue Feb 18 11:45:16 EST 2003

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 

linutronix - competence in embedded & realtime linux
mail: tglx at

More information about the linux-mtd mailing list